What authoritative means

When a user profile in a social app shows yesterday’s photograph, nothing turns on the error. When a corporation’s twin shows the wrong director list, and a contract is executed on the signature of a director removed the week before, something does. The company may be bound regardless, because it let the appearance of authority stand and the counterparty relied on it; or the counterparty may face avoidance of the contract. Which way it resolves varies by jurisdiction and by facts. That one side carries validity risk it did not price does not vary. When the twin shows a revoked license as active and the corporation trades in reliance on it, the corporation is operating unlawfully. A wrong record does not merely misinform. It allocates legal risk.

Authoritative means that downstream consumers (compliance evaluators, governance engines, regulators, courts) can treat the twin’s state as the record of legal fact. That standing is an assumption of this paper, not a consequence of its construction. The twin is the legal record where a jurisdiction designates the system maintaining it as its register of companies, or recognizes its records as evidence; where neither holds, it is a private record of high evidentiary quality. Everything below is about making the record worthy of the designation. The designation is law’s to give.

Standing as a record imposes a structural requirement: the twin must be derivable from its event history. If someone challenges the current state (“you say director X was appointed; prove it”), the system must produce the chain of events that led to that state, replay it, and arrive at the same answer. A replay that produces a different state proves damage somewhere: in the stored state, in the chain, or in the replay machinery. Every determination made from the record is then suspect until the damage is located.

This is the difference between a cache and an authoritative record, and it has to be drawn on the right facts. A cache is derived from a source of truth elsewhere; when the two disagree, the source wins. The twin holds two kinds of fact. The facts it constitutes, the appointments, issuances, bindings, and lifecycle events recorded through it, have no source but the record: a challenge to one of them is resolved by producing the evidence chain, never by deferring to another system. The facts it mirrors are constituted elsewhere and carried as a digest or a recorded status: the version of a rule bundle fixed by a regulator (a pack, defined below), a license status fixed by the authority that issues the license, a compliance verdict fixed in the entity’s ledger of compliance evaluations (its passport, defined below). On those the source wins, exactly as for a cache, and what the twin owes is an honest mirror: it carries the value it holds, detects when the source has moved, and marks the drift on the record instead of serving the stale value as current. In the example above the director list is constituted and the license status is mirrored; the construction below is built for both.

The event-sourced construction

The twin is a materialized projection of an event history.

Every change to the twin’s state is recorded as a typed event: a director was appointed, a share class was created, a license was bound, an obligation was attached, an uncertainty was recorded, a corridor was activated (a corridor is a negotiated, machine-verifiable link between two jurisdictions’ systems of record, over which an entity’s state and proofs travel). Events carry a per-entity sequence number, and each event carries the SHA-256 digest of its predecessor, forming a hash-linked chain. The linking is the same as in the receipt chain that records corridor crossings, constructed in the companion paper The Chain of Evidence; the receipt chain additionally carries an accumulator for efficient inclusion proofs and external witnesses against operator equivocation, and the twin chain does not.

What the chain proves must be scoped before it is used. Every link lives in the operator’s store, and every signature over the record verifies against the operator’s own key. Walking the chain therefore establishes integrity against every party except the operator: a third party who alters a stored record breaks a hash link it cannot recompute, while the operator can rewrite any prefix and recompute every link and signature after it. Integrity against the operator requires evidence held outside the operator’s reach: a chain head obtained independently and retained, periodic anchoring of the head into an external log, or witnesses who attest to the heads they observe. The Chain of Evidence starts its verifier from an authenticated head, one the operator signed and a watcher quorum attested, and constructs the third as a bonded watcher set whose attestations expose an operator that serves conflicting heads; anchoring into an external log is a further option that neither paper constructs. The twin chain and the lawchain (below) carry the same obligation. In this paper, tamper-evident means evident to a verifier who holds an earlier head through a channel the operator does not control.

The twin’s current state is the result of replaying every event in order from genesis. A twin can be rebuilt from its history, for verification (does the stored state match the replay?) or for recovery (the stored state is lost or suspect). The verification reading rests on one property, stated here because the rest of the paper leans on it.

Proposition (replay identity). Assume: (i) the state-transition function is deterministic, a pure function of state and event that reads no clock and draws no randomness, with every timestamp taken from the event itself and every collection traversed in a canonical order; (ii) events are totally ordered by their per-entity sequence numbers; (iii) the events committed for each mutation, applied in order to the state before the mutation, produce exactly the state after it (the mutation pipeline below is constructed to provide this); (iv) the transition function applied at replay is, for every event, the function under which (iii) held when that event was committed. Then replay from genesis reproduces the stored twin, and a replay mismatch implies corruption of the stored twin, of the event chain, or of the replay machinery.

Proof sketch. Induction over committed mutations. The genesis state is fixed. For the step, (iii) says the committed events carry the mutation’s successor state, and (i), (ii) and (iv) say replay applies the same events, in the same order, under the same function, to the same predecessor, computing the same successor. The mismatch claim is the contrapositive.

The excluded sources of non-determinism are the ones that break real systems: clock reads during replay, iteration over unordered collections, dependence on anything outside the event. Any one of them lets replay produce a legitimately different state, and the mismatch signal stops meaning corruption. Condition (iv) names the largest member of the same class. The mutation pipeline discharges (iii) for the function that ran at commit time and for nothing else, while a replay performed years later, or by a counterparty, runs whatever function it holds; a transition function changed since the events were committed produces a legitimately different state from the same history, and the signal is destroyed as surely as by a clock read. Condition (iv) is discharged in one of two ways: the transition function is held fixed for the life of the chain, or every event carries the version of the semantics under which it was committed and replay applies that version, carrying a retired version forward only through a map that preserves (iii). A deployment that changes the function without either has broken replay identity for every earlier event, whether or not a replay has yet noticed.

The construction solves three problems.

First, auditability. The chain answers what the corporation’s current state is and how it arrived. Every director appointment, share issuance, license change, and uncertainty is recorded with its position in the order, a causal link to its predecessor, and a digest commitment. An auditor who holds an independently obtained head can verify the complete history mechanically.

Second, temporal queries, where a record claiming legal standing must keep two times apart. Replaying events up to a past point reproduces the state as recorded at that point, so “what did the record show on March 15th?” is answered exactly. “Who were the directors on March 15th?” is a different question, because corporate facts take effect on dates other than the dates they are recorded: an appointment recorded on March 20th may be effective March 10th, and an erroneous event is corrected by appending a compensating event, which changes nothing about what earlier replays show. Events therefore carry two times: the recording time, fixed by position in the chain, and the effective date of the fact recorded. The pair is the transaction time and valid time of the temporal-database literature (Snodgrass and Ahn 1985). Replay in recorded order answers the record-time question; the effective-time answer is computed from the same chain by honoring effective dates and compensating corrections. A court or regulator can be given both views, and they answer different questions: what the record asserted on the day, and what the legal position on the day was. Both times are frozen coordinates of the record, and the effective-time view is derived from them; the rule that derived views never rewrite the frozen record, the stratification of frozen time from derived time, is the subject of the companion paper Time in Institutional Computing.

Third, dispute resolution. When two parties disagree about the corporation’s state (“the license was active when we signed” against “the license had been revoked”), the chain is the evidence, under three conditions this section has already forced. The parties must run the same transition function, the one the events were committed under, since condition (iv) of replay identity is discharged for a counterparty by nothing else; they must hold, or obtain through a channel the operator does not control, a chain head at least as recent as the disputed period; and the question must be posed in the right time, since license validity on a date is an effective-time question. Under those conditions the dispute reduces to a replay either party can perform.

What the twin contains

The twin carries digest heads rather than embedded copies of subordinate state.

A corporation’s full state includes its compliance passport (the hash-chained history of its compliance evaluations), its governance artifacts (board resolutions, consent records), its evidence ledger (filed documents, attestations), and its lawchain (the sequence of completed operations, described below). Embedding all of this in the twin would make it enormous and would make it a consistency bottleneck: every passport advance and every new governance artifact would require rewriting the twin.

Instead, the twin carries digest references: the SHA-256 digest of the compliance passport’s current head, the digest of the governance state, the digest of the evidence ledger’s head. Each is 32 bytes and cryptographically binding. The twin says “the compliance passport is in state X”, and anyone holding the passport can check that its head hashes to X. The check is the detection mechanism, and it runs only when both sides are in hand: a digest reference makes staleness detectable whenever the subordinate head is available for comparison, and detected only when the comparison is performed.

Compliance evaluations are therefore not twin events. They are recorded in the passport, and they reach the twin as a single event kind: the passport’s digest head advanced.

The result is a twin small enough to materialize and fast enough to query that remains cryptographically bound to the full depth of every subordinate system. It duplicates none of them. It commits to all of them.

Typed bindings

The twin carries vectors of typed bindings: pack bindings, license bindings, obligation bindings, evidence bindings, corridor bindings, actuator bindings, and member bindings. These are distinct institutional relationships that must remain distinct for downstream reasoning.

A pack binding connects the entity to a pack, a versioned bundle of rules that governs its behavior in one domain. Packs come in kinds, and two are named below: the legal pack carries the governing law and its citations, and the regulatory pack carries the predicates and thresholds a regulator applies. A license binding connects the entity to a license and its current status. An obligation binding connects the entity to a regulatory obligation and tracks its satisfaction. An evidence binding connects the entity, by digest, to a piece of evidence an operation produced: a filed document, an attestation. A corridor binding connects the entity to a corridor and carries an embedded state machine for the corridor’s operational phase. An actuator binding connects the entity to an external system that acts on its behalf: a bank rail, a registry interface, a signing service. A member binding connects the entity to a person who holds a role in it (director, officer, shareholder of record), together with the role and the state of the member’s identity verification.

The typed distinction matters because the operations valid on each binding type differ. You can suspend a corridor binding. You cannot suspend a pack binding (a pack can be updated; the binding has no suspended state). You can satisfy an obligation binding. You cannot satisfy a license binding (licenses are renewed or revoked, not satisfied).

A system that represented all of these as a generic relationship between an entity and a thing would lose the type information that determines which operations are valid. The typed vectors preserve it.

Mutation through projection

The twin does not expose a general-purpose save. A caller cannot fetch the twin, modify arbitrary fields, and write it back. Every mutation enters through a projection pipeline.

Callers invoke typed binding methods: bind a pack, bind a license, bind an obligation, attach a smart asset (a digitally represented instrument that carries its own compliance rules; the subject of the companion paper The Asset Virtual Machine), record an uncertainty, record a lifecycle event. A mutation accumulates such changes and commits them as one batch. At commit, the event derivation function compares the state before the batch with the state after it and emits an ordered sequence of typed events recording the difference. This provides condition (iii) of the replay-identity proposition by construction: the emitted events, applied to the predecessor state, reproduce the successor.

The batch is the unit of atomicity, of ordering, and of commitment, and the completeness claim is exactly batch-grained: every net change to a binding across a committed mutation produces an event; a change made and reverted within the same mutation produces none; the order of events inside a batch is derived from the comparison, not observed from the calls. The chain is a complete record of committed differences, not a log of keystrokes.

The pipeline narrows the space of invalid updates. A caller cannot set the twin’s jurisdiction to null, because no method sets the jurisdiction to null. A caller cannot remove an event from the chain, because the only write on the chain is append. A caller cannot commit a change to a binding without producing an event that records it.

An entity object that any service may modify through a general-purpose save reflects the last write from whichever service touched it most recently, with no record of what changed or why. The projection pipeline makes every committed change named (a typed event), ordered (the sequence), and committed (the hash chain).

Divergence as first-class state

On the facts the twin mirrors, the source wins, as for a cache, and the one property that separates the twin from a cache on those facts is the explicit representation of uncertainty.

Institutional state diverges. A regulator updates a pack, and the twin still carries the old pack digest. A compliance evaluation is pending, and the twin still reflects the previous result. An external service reports a license status that conflicts with the recorded one.

A record that shows whatever was last written handles divergence by ignoring it: the state is stale, and nothing marks it stale until something downstream fails. That is tolerable in an analytics dashboard. It is intolerable in a record whose outputs drive governance decisions, compliance evaluations, and financial operations.

The twin represents divergence as data. When the system detects that a pack binding’s digest no longer matches the pack’s current version, it records an uncertainty of type source drift on that binding. Detection is comparison: drift is found when a recorded digest is checked against the live source, at synchronization points or on demand, so the uncertainty set covers the divergence the system has looked for and found, not all divergence that exists. What the mechanism removes is silence about known staleness, and it removes it completely. An active uncertainty is visible to every downstream consumer. An evaluation that runs against a twin with active uncertainties knows which of its inputs may be stale, and can proceed with a caveat, block until the uncertainty is resolved, or mark its own result provisional.

Uncertainty records are first-class events in the event chain. Recording one produces an UncertaintyRecorded event; resolving one produces an UncertaintyCleared event. The history of divergence and resolution is part of the permanent record, available for audit.

The lawchain

The event chain records every committed change: every binding change, every uncertainty, every lifecycle event. That granularity is what replay and audit need, and it is too fine for other uses. A regulator asking what operations a corporation has undergone does not want thousands of field changes. They want the completed operations: the incorporation, the share issuances, the foreign registrations, the annual reports.

The lawchain provides this view. It is a second hash-linked chain in which the unit of history is the completed operation. Each block carries the operation’s identifier and its proof, the jurisdiction, the digests of the legal and regulatory packs that governed the operation, a compliance tensor root (a commitment to the entity’s per-domain compliance verdicts at completion), a state root, and the digest of the previous block, and each block is signed by the operator.

The state root is what binds the coarse chronology to the fine one: it commits to the twin’s event-chain head as of the operation’s completion. By replay identity, that head determines the twin’s state, so each lawchain block commits to the exact fine-grained history that produced the state it reports, and the two chains cannot disagree silently. A verifier walks the lawchain checking digests, links, and signatures, then checks that each block’s committed head lies on the twin’s event chain and that replay to that head reproduces what the block asserts.

The twin and the lawchain answer different questions. The twin answers what the corporation’s current operational state is. The lawchain answers through which verified sequence of completed operations the institution arrived there. One is the present projection; the other is the legal-operational chronology.

Verification of either chain is a mechanical walk from the latest block backward, recomputing digests and checking links, and its meaning is fixed by the threat model above. A verifier who holds the head through an independent channel and finds every link intact knows the records have not been altered since that head was obtained, without any testimony from the operator. A verifier who took the head from the operator has checked internal consistency and nothing more. A broken link proves the chain is not intact. It does not say whether the cause is fault or tampering. It says that no record at or before the break is verified by the held head, and every determination resting on those records is suspect until the cause is found.

Snapshots and recovery

Replaying an entire event history from genesis is correct and slow. An entity that has operated for years accumulates tens of thousands of events, and replaying all of them to answer a current-state query is waste.

Snapshots bound the cost. Periodically, the system serializes the twin’s state, computes the serialization’s SHA-256 digest, and stores snapshot and digest with the event sequence number they correspond to. Recovery from a snapshot replays only the events after it. The rebuilt state is a function of the snapshot and of the events after it, and by replay identity it equals the full replay whenever the snapshot equals the state that full replay reaches at the snapshot’s sequence number. Recovery is therefore sound only if the snapshot was correct when it was taken, and the construction grounds that in one of two ways. Either the snapshot is serialized from replay’s own output, at a verification pass that has just replayed to its sequence number, so that by replay identity it is the state at that point; or its digest is committed into the event chain as an event naming the sequence number it covers, so that its correctness becomes a claim of the record that any later replay to that number checks by recomputing the state and comparing digests, and a snapshot taken from a stored twin that was already damaged is exposed by the first replay from genesis that reaches it. A snapshot serialized from the stored twin without either grounding inherits whatever damage the stored twin carried, and passes every digest check while doing so.

The digest is the second check, and it certifies less: that the snapshot is intact since it was taken. A snapshot without a digest is an unverifiable blob. A snapshot with a digest is checked before use: deserialize it, recompute its canonical digest, compare. On a match the bytes are the bytes the digest was computed over; on a mismatch the snapshot is corrupt and recovery falls back to full replay. The party scoping of the chain applies here as everywhere. A digest stored beside its snapshot detects alteration of the stored bytes by every party except the operator, who can rewrite both; a digest committed into the event chain is covered by any head obtained after it through an independent channel, and the snapshot then stands or falls with the chain.

Snapshot frequency follows activity: entities with more events are snapshotted more often. Old snapshots are pruned once newer recovery points exist; retaining a fixed number of recent snapshots per entity bounds storage without giving up recovery from any recent point.

Why the twin must exist

The alternative to the twin is the status quo: institutional state scattered across services, reconciled by hand, and relied on without any means of verification.

That posture holds while an institution operates in one jurisdiction, under one regulatory regime, with few and simple operations. It fails across jurisdictions, because a cross-jurisdictional operation needs one place where the institution’s complete state can be evaluated: whether a corporation is eligible to foreign-qualify in jurisdiction B cannot be evaluated by querying three services in jurisdiction A and hoping the answers describe the same moment.

It fails under delegated programmatic operation. A delegated program (software authorized to operate the institution within a bounded, revocable scope) executes at machine speed against a representation of the institution, and cannot query six services, reconcile their responses, and adjudicate their inconsistencies on every decision. It needs a single authoritative object, with explicit uncertainty markers on anything that may be stale.

And it fails under audit, because an auditor reconstructing the history of an institution’s state cannot do it from scattered, unlinked records. The auditor needs the hash-linked chain with replay semantics: history tamper-evident to the holder of an earlier head, and current state derivable from it.

The corporation twin is what it means for an institution’s state to be authoritative, auditable, replayable, and honest about its own uncertainty. The event chain carries the audit and the replay. The digest references bind the subordinate systems. The typed bindings and the projection pipeline constrain change to what can be named and recorded. The uncertainty records carry the honesty. The guarantee is exact: the twin is verifiably consistent with its complete recorded history; its staleness against any subordinate ledger is detectable whenever that ledger’s head is available for comparison; every divergence it has detected stands on the record, visible to every consumer, until cleared. Three limits bound it. Divergence never checked is outside the guarantee. Integrity against the operator is obtained only by holding heads outside the operator’s reach. And the record certifies its own history, not the world’s: a change made outside the system and never recorded, a director removed on paper alone, produces no event and no head to compare, and the record is then wrong in the sense of the opening section while every clause above holds. Within those limits the guarantee is what the construction proves: the record cannot be inconsistent with its history silently, cannot be silently stale at a comparison it has made, and cannot hide a divergence it has found.

References

Fowler, M. (2005). “Event Sourcing.” martinfowler.com.

Grieves, M. and Vickers, J. (2017). “Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems.” In Transdisciplinary Perspectives on Complex Systems. Springer.

Haber, S. and Stornetta, W. S. (1991). “How to Time-Stamp a Digital Document.” Journal of Cryptology, 3(2), 99-111.

Laurie, B., Langley, A. and Kasper, E. (2013). Certificate Transparency. RFC 6962.

Lorgat, R. The Chain of Evidence. Companion paper in this series.

Lorgat, R. Time in Institutional Computing. Companion paper in this series.

Lorgat, R. The Asset Virtual Machine. Companion paper in this series.

Snodgrass, R. and Ahn, I. (1985). “A Taxonomy of Time in Databases.” Proceedings of the 1985 ACM SIGMOD International Conference on Management of Data, 236-246.

Torvalds, L. (2005). Git: a distributed version-control system.