The Ledger.
One line, written once, never touched again.
The ledger is the single place where CTinFold declares, once and permanently, that something real happened. Every other component in this system exists downstream of this one file. Nothing in CTinFold is considered true until it has a line in the ledger.
The ledger is not a database. It is not editable. It is a plain, append only file, one line, one declaration, written once, and never touched again for the rest of its existence. Exactly one function in the entire system is permitted to write to it. That function only ever writes when a declaration has already been fully accepted. A duplicate write is never silently allowed, and a correction never rewrites the past, it is filed as new, separate truth. Two independent readers confirm what the ledger already proved, never by reading the ledger itself, but from their own independently sealed copies.
One writer. And only one.
CTinFold has exactly one function, in the entire system, on either surface, permitted to write to the ledger. This is not a convention. It is an enforced, verified fact, confirmed by exhaustively searching every file in the codebase for any other place that opens the ledger file for writing. None exists. If a declaration's data never passed through this one function, it is not in the ledger, and it never happened as far as CTinFold is concerned.
This function only ever writes when a declaration has already been fully accepted, verdict ACCEPT. A declaration that was rejected, or left pending, never receives a ledger line. Rejection and pending status are recorded elsewhere, as their own honest artifacts, but they are never confused with acceptance by being allowed anywhere near this file.
What every line contains.
Each ledger entry is a single JSON object. Nothing in it is ever removed, and nothing in it is ever rewritten. A line, once written, is permanent.
verdict always ACCEPT, by construction
timestamp_utc when this entry was written
reference_hash a cryptographic hash computed at acceptance
relation, actors, amount, currency, partner_id the substance declared
corrects_declaration_id, correction_reason, original_amount populated only on a correction, empty otherwise
The reference hash. A different proof than the topology's.
reference_hash is computed by taking the full declaration, sorting its fields into a fixed order, and hashing the result. This is deliberately a different kind of proof than the hashes used elsewhere in CTinFold's topology, which instead compare raw file bytes, copy for copy. These two hash systems will never match each other, and that is correct, not an inconsistency.
Computed from the declaration's own sorted fields at the moment of acceptance. It answers one question, was this exact declaration accepted, exactly as written.
Computed by comparing raw file bytes, copy for copy. It answers a different question, did this file survive its journey through the system completely unchanged.
Two different claims, proven two different ways, deliberately kept separate.
The guard. No declaration is ever silently written twice.
Before writing any new entry, append_ledger() reads the entire existing ledger and checks whether this exact declaration_id has already been recorded. If it has, the new write is refused outright, not silently skipped, and not silently allowed to create a second, conflicting entry.
The ledger itself never carries two lines for the same declaration, and there is always a written record of every attempt that was correctly turned away.
Never edited, never deleted. Corrections are new truth.
If a declared amount was wrong, the ledger does not change to fix it. A correction is its own new, separate entry, relation correction, carrying an explicit reference back to the original declaration it corrects. The original stays exactly as it was written, forever. Anyone reading the ledger later can see both, what was first declared, and what was later corrected, in the order it actually happened. Nothing about the past is ever quietly rewritten to make the present look cleaner.
Who is allowed to read the ledger, and who deliberately is not.
The component that builds every financial statement CTinFold produces never reads the ledger directly. The component that watches for year-end sweep conditions never reads it either. Both work exclusively from their own independently sealed copies of what the ledger already confirmed, never from the ledger's own file.
CTinFold's statements are never just a report generated from the ledger. They are a second, independent confirmation of what the ledger already proved, computed by different code, reading from a different place.
If the two ever disagreed, that disagreement itself would be the proof that something needs investigating. Independence is what gives a match its meaning.
What the ledger proves.
The ledger proves that a declaration was accepted, exactly once, and exactly as written, and that nothing about it has been silently altered since.
Closing.
The ledger is small, plain, and deliberately unglamorous, a single growing file, one line at a time, never touched once written. Every other proof in CTinFold exists to make that one file trustworthy, and to make sure that once something is written into it, there is never any question of whether it was ever there at all.
SHA-256
Blank this value and recompute
SHA-256 of this page to verify it is untouched.