The Topology.
How a declaration becomes proof that cannot be questioned.
Every economic event a partner declares travels a fixed chain. A verdict, a seal, an independent copy that proves itself, a time boundary, and finally the document itself. Nothing in that chain can be altered after the fact. Not by the partner, not by a regulator, not by CTinFold. This paper describes the spine on which every other CTinFold paper rests.
A record states that something happened. A proof demonstrates that it happened, exactly so, and has not changed since. CTinFold is built to produce the second. The topology is the route a declaration follows from the moment it is submitted to the moment its document is exported. A deterministic verdict, a cryptographic seal, an independent verifier that recomputes the very same result without trust, a time window that binds the seal to a moment, and an export hash that carries the proof onto the page. Two independent holders, one hash. If they ever disagree, the system knows, and no one has to look.
A record can be edited. A proof cannot.
Every accounting system in use today does the same thing. It records. It writes that a transaction occurred, assigns it a number, and stores it. This is useful, and it is not proof. A spreadsheet can be edited. A database row can be rewritten. The date on a file can be changed. A record says we wrote this down. It does not say this happened, exactly so, and has not been touched since.
The distinction is invisible until the moment it matters. An audit, a dispute, a regulatory inquiry. At that moment it is the whole difference between a claim and evidence. CTinFold exists to close that gap. When a declaration is accepted, it is sealed with a mathematical function. The same declaration always yields the same seal, and changing a single character breaks it completely.
The chain: declare, decide, seal.
A partner submits what happened. The amount, the relation, the counterparty, the currency. The decision engine reads the economic event behind the declaration, checks it against the relation registry, and returns one of three verdicts. Accept, Reject, or Pending. A reject is not silence, it is a sealed verdict in its own right. On accept, the event is written into the partner's permanent record under a cryptographic seal. That seal is what makes it proof and not merely a record.
Three independent locations. One hash they must share.
When a declaration is accepted and written to the ledger, the sealed file is carried to three independent locations. Two of them hold the working record. The third is a byte for byte copy placed inside an independent verifier's own space. That copy is checked at the instant it is written. The system computes the hash of the source and the hash of the copy, and unless the two are identical the chain stops and a failure is recorded. The accepted declaration is complete only when all three locations hold exactly the same content.
The ledger holds a reference hash, computed from the declaration at the moment of acceptance. The independent verifier never reads the ledger. It reads only its own copy, and computes its own hash. If the two values match, the declaration that was accepted is provably the same declaration the verifier holds. Neither side was told what to write. Both arrived at the same value because both read from the same source, verified identical at the moment of writing.
If anyone altered the file after it was sealed, the verifier's hash would no longer match the reference hash in the ledger, and the divergence would surface on its own. No one has to look. The mathematics catches it. The third location is what makes that independence real. Without a copy held in the verifier's own space, there would be nothing to compare against, and nothing to catch.
The sealed record of every declaration that passed the decision engine, written once and never changed.
A separate copy in its own space, hashed independently. It never reads the ledger, yet must arrive at the same hash.
Time is part of the proof.
In most systems, time is metadata. It tells you when something was recorded, and enforces nothing. CTinFold treats time as a constraint. When a tax component enters the locking process, a window of 120 seconds opens. Both independent locations must confirm the seal inside that window. If the window closes first, the component becomes a failure artifact, itself a sealed, auditable record of what was attempted and why it did not complete.
The rule exists for one reason. So no one can attach a declaration to a past event after the fact. The time of the proof is part of the proof. A failure is not a gap in the record. It is a record of the failure.
The proof reaches the page. The export hash.
The topology hash proves the declaration was sealed. But a partner does not hand an auditor a declaration, they hand over a document. So the proof chain extends one step further. Every sealed document CTinFold exports carries an export hash in its footer, a SHA-256 computed from the document content at the moment of export. Anyone holding the file can recompute it and confirm the document is the same one the system produced, untouched.
Two proofs, neither replacing the other. The topology hash proves the event. The export hash proves the document. This paper carries one too, printed below, as every CTinFold paper does.
SHA-256
Recompute to verify
this document is untouched.