Epistemic Temporal Integrity Protocol (ETIP) v1.1

1. Positioning & Intent

ETIP exists to solve a simple, stubborn problem: data can be quietly rewritten.

In systems like ESG reporting, numbers do not just exist — they evolve. What is often lost is not the latest value, but the history of how that value came to be.

"What did you say before — and did you change it later?"

ETIP is designed so that this question always has an answer. It does not try to prove truth, judge correctness, or enforce honesty. Instead, it does something narrower, but more reliable:

It makes it impossible to rewrite the past without leaving evidence.

2. Design Positioning

ETIP is a post-blockchain system, and also post-heavy infrastructure. It keeps what mattered — chaining, fingerprinting, external witnessing — and removes what did not: consensus overhead, global coordination, and energy-intensive operation.

ETIP takes what worked, and removes what didn’t.

It is not designed for consensus, markets, or scale at any cost. It is designed for one thing only: preserving the temporal integrity of records.

3. Historical Lineage

ETIP stands on existing ideas rather than replacing them:

• Hash chaining — linking records so the past cannot be changed silently
• Merkle aggregation — compressing many records into a single proof
• Public witnessing — anchoring data outside the control of its creator
• SHA-256 — collision-resistant fingerprinting standard
• Ed25519 — efficient, verifiable digital signatures
• JSON Canonicalization (RFC 8785) — deterministic data representation

4. What ETIP Guarantees

• History is append-only
• Changes are visible
• Past records cannot be silently altered
• A record existed no later than when it was witnessed externally

ETIP does not guarantee:

• That the data is correct
• That all data was disclosed
• That measurements were accurate

5. Core Mechanism

Each record is first converted into canonical form using JSON Canonicalization (RFC 8785). This ensures the same data always produces the same byte representation. Each record is then reduced to a fingerprint using SHA-256. Each fingerprint links to the previous one, creating a chain. If any past record is changed, the chain breaks. The chain is periodically signed using Ed25519 and published to independent witnesses.

6. Levels of Use

ETIP-Compatible

Records are chained internally. This provides integrity of sequence. Changes can be detected. No time claims are made at this level.

ETIP-Conformant

The chain is signed and published to independent witnesses. This enables external verification and audit.

A record existed no later than when it was witnessed.

7. Time

ETIP does not prove exact time. It proves that something existed no later than when it was witnessed.

8. Witnessing

A record is only meaningful if it is seen outside its own system. At least one Root Hash MUST be published within every 24-hour window to be considered forensically sealed.

Witness Classes

• Class A — Public Service: Independent, publicly accessible, no direct stake in the data
• Class B — Conforming Participants: Companies, associations, NGOs, institutions
• Class C — Timestamp Authorities: Certified time-stamping services

Recommended Witness Class Usage

To ensure high epistemic weight, the following combinations are recommended:

• Class A + B: Standard corporate accountability; bridges public transparency with industry peer-review.
• Class B + B: Distributed industry trust; suitable for consortium-based audit trails.
• Class A + C: High legal assurance; combines public visibility with certified temporal authority.
• Class A + B + C: Maximum integrity; provides the highest forensic threshold for mission-critical audit timelines.

9. Infrastructure Philosophy

ETIP is designed to run in constrained environments. It does not require large data centers or continuous high compute. It can operate on edge workers, small devices, and low-power systems.

Integrity should not depend on heavy infrastructure.

A system meant to improve accountability should not increase environmental cost.

10. Data Model

{
  "type": "commit",
  "prev": "sha256",
  "artifact": "sha256",
  "record_fp": "sha256"
}

{
  "type": "checkpoint",
  "signature": "ed25519",
  "witness": [...]
}

{ "supersedes": "previous" }

All fingerprints are SHA-256 over canonicalized data. Signatures use Ed25519.

11. Threat Model

• Prevents silent rewriting of history
• Prevents unnoticed deletion
• Does not prevent false input
• Does not prevent omission

12. ESG Context

ETIP does not stop companies from changing numbers; it makes those changes visible. Auditors evaluate timelines, not snapshots.

13. Mandatory Non-Claims

ETIP does not verify truth, certify correctness, enforce compliance, or ensure completeness. It does not issue assets or tokens. ETIP only preserves history.

Changelog

• Clarified "no later than" time guarantee
• Added explicit guarantees vs non-guarantees
• Strengthened witness definition and added Recommended Witness Class Usage
• Added threat model explanation
• Introduced optional revision linking
• Refocused language on ESG audit use-case
• Clarified post-blockchain and post-infrastructure positioning
• Simplified language for broader accessibility