The Category Registry.
One name, forced, until it is replaced.
A category is not a label a partner types and forgets. In CTinFold it is a registration, a fact written to disk, hashed, and forced back onto every future declaration for that supplier until the partner deliberately replaces it. The category is also the tax component in full, bound to it rather than looked up beside it.
A category is a registration, not a convenience field. Taxable, tax percentage, and tax included in total are bound to the category, not to the declaration. Change the category and the entire tax obligation that comes with it changes too. This paper describes the mechanism that makes a category a component of proof.
The problem this closes.
A partner declares against the same supplier many times. Ask them to type the category, and the tax percentage, and whether tax is included, every single time, and two things happen. First, they eventually mistype it, and a single supplier ends up scattered across several near-identical categories that should have been one. Second, and worse, nothing stops two declarations against the same supplier from silently disagreeing on what tax applies, because nothing ever asked whether they should agree.
CTinFold's answer is not validation. It is registration. The first time a category is declared for a supplier, it becomes the current fact for that supplier, sealed, hashed, and forced onto every declaration that follows, without the partner re-typing anything.
What is registered.
Per partner, per supplier, one entry is kept:
history: ["hardware"]
current_since_utc: "2026-07-21T22:07:51Z"
current_hash: sha256("energy")
current is what gets forced. history is every category this supplier has ever carried, preserved, never deleted, per the standing rule that deletion requires a written reason and a registry entry is not one. current_hash is what travels forward into the declaration's own sealed record, so a declaration proves, independently and forever, which category was active when it was accepted, not merely what the registry says today.
The category is the tax component.
The category is not looked up separately from tax. It is the key the tax component resolves against.
Every tax fact, taxable, tax percentage, tax included in total, is stored against this exact slot. Force the category, and the correct tax obligation is derived with it, atomically, in the same lookup. A partner does not declare a category and then separately confirm tax. There is one bound unit, and the system resolves it as one.
The three declaration paths.
A declared category, checked against what is registered for that supplier, resolves one of three ways.
The ordinary, overwhelming case. The same supplier, the same category, day after day. Nothing changes.
The declaration proceeds without disturbing current. The partner reaches deliberately for an older category still on record. The forced default is untouched.
Declared as new, the category becomes current and the old current moves to history, remaining reachable forever. Silently different, with no signal, is not accepted at all. This gate never bends.
A worked example.
- A supplier is declared for the first time under category hardware. No history exists yet. Hardware is written directly as current.
- The same supplier is later declared again, under software, with the new-category signal explicitly given. Software becomes current. Hardware moves to history. Nothing about the first declaration is touched, edited, or erased.
- A third declaration is submitted under hardware again, the old one, now sitting in history. It proceeds. Current remains software. The partner reached for an alternate, deliberately.
- A fourth declaration arrives under SOFTWARE, same category, different case. It matches current exactly. No new entry, no history growth. The registry is case-normalized by design.
What travels into the sealed record.
This is what makes the category a component of the topology rather than a setting consulted once and set aside. The resolved category and its hash are written directly into the declaration's own sealed payload at the moment of sealing, not read from the registry and discarded after intake.
A sealed declaration, read back independently at any later time, proves exactly which category was forced at the moment it was accepted. If the registry's current has since moved on, a later append, a later supersession, the old declaration's own proof does not move with it. It states what was true when it was sealed, permanently.
What is not touched.
The ledger, the topology chain, and the independent verifier's own derivation logic hold no dependency on this registry beyond the fields already threaded into the sealed record. The registry is read at declaration time. Nothing downstream consults it again. The independent verifier's statements draw only on what a declaration already carries, never on the registry's present state.
A category is either registered, on disk, or it does not exist as a fact the system can force.
What is forced is never held in a session, a variable, or a cache. It is read, fresh, from the registry itself, every time.
Selecting an alternate declares against it. It does not silently rewrite what is registered as current.
History is not overwritten. It accumulates, permanently, alongside whatever is current now.
SHA-256
Blank this value and recompute
SHA-256 of this page to verify it is untouched.