What authoritative means

A stale photograph in a social-app profile may have no consequence. A stale director list can support a contract signed by a director removed the week before. The company may remain bound because it allowed the appearance of authority and the counterparty relied on it. Alternatively, the counterparty may face avoidance of the contract. The outcome depends on the jurisdiction and facts, but either way one side bears unpriced validity risk. If the twin shows a revoked license as active and the corporation trades in reliance on it, the corporation operates unlawfully. Record errors therefore allocate legal risk.

Authoritative means that compliance evaluators, governance engines, regulators, and courts can treat the twin’s state as the record of legal fact. This paper assumes that standing. The construction cannot confer it. The twin is the legal record where a jurisdiction designates its system as the register of companies or recognizes its records as evidence. Otherwise, it is a private record of high evidentiary quality. The construction below supplies the record’s technical basis for legal designation.

The twin must therefore be derivable from its event history. To answer a challenge (“you say director X was appointed; prove it”), the system must produce and replay the events leading to the current state. Replay must produce the same answer. A mismatch proves damage in the stored state, the chain, or the replay machinery, subject to the replay conditions below. Until the damage is located, every determination based on the record is suspect.

A cache derives from an external source of truth, which governs when the two disagree. The twin holds two kinds of fact, with different rules for resolving disagreement. Appointments, issuances, bindings, and lifecycle events recorded through the twin are facts it constitutes. Their source is the record itself, so a challenge requires the evidence chain rather than reference to another system.

Mirrored facts are constituted elsewhere and carried as a digest or recorded status. Examples include a regulator’s rule bundle (a pack, defined below), a license status fixed by its issuer, and a verdict in the entity’s compliance-evaluation ledger (its passport). For these facts, the external source governs. The twin carries its recorded value, detects changes at the source, and marks detected drift instead of presenting a stale value as current. The director list in the example is constituted, while the license status is mirrored. The construction supports both.

The event-sourced construction

The twin materializes its current state by projecting an event history.

Every change to the twin’s state produces a typed event: director appointed, share class created, license bound, obligation attached, uncertainty recorded, or corridor activated. A corridor is a negotiated, machine-verifiable link between two jurisdictions’ systems of record that carries an entity’s state and proofs. Each event carries a per-entity sequence number and its predecessor’s SHA-256 digest, forming a hash-linked chain. The companion paper The Chain of Evidence uses the same linking for receipts of corridor crossings. Its receipt chain also has an accumulator for efficient inclusion proofs and external witnesses against operator equivocation. The twin chain has neither.

The integrity claim depends on the verifier’s evidence. Every link lives in the operator’s store, and every record signature verifies against the operator’s own key. Walking the chain therefore establishes integrity against every party except the operator. A third party altering a stored record breaks a hash link it cannot recompute. The operator can rewrite any prefix and recompute every subsequent link and signature.

Integrity against the operator requires evidence outside its reach: a retained independent chain head, periodic anchoring in an external log, or witnesses to observed heads. The Chain of Evidence starts verification from a head signed by the operator and attested by a watcher quorum. It constructs a bonded watcher set whose attestations expose conflicting heads. External-log anchoring remains an option that neither paper constructs. The twin chain and the lawchain below have the same requirement. Here, tamper-evident means evident to a verifier holding an earlier head through a channel the operator does not control.

Replaying every event in order from genesis rebuilds the twin’s current state. Replay supports verification of stored state and recovery when that state is lost or suspect. Verification depends on the following property.

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.

Clock reads, unordered collection traversal, or other inputs outside the event can produce a legitimately different replay state. A mismatch would then cease to imply corruption. Condition (iv) excludes the same failure from changed transition semantics. The mutation pipeline establishes (iii) only for the function used at commit time. A later replay, including one performed by a counterparty, can produce a different state if it uses a changed function.

There are two ways to satisfy (iv). Keep the transition function fixed for the chain’s lifetime, or record each event’s semantic version and apply that version during replay. A map carrying a retired version forward must preserve (iii). Changing the function without either provision breaks replay identity for every earlier event, even before anyone runs a replay.

Under these conditions, the construction supports audit, temporal queries, and dispute resolution.

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 require two distinct times. Replaying to a past point answers “what did the record show on March 15th?” exactly. “Who were the directors on March 15th?” asks about legal effect. An appointment recorded on March 20th may be effective March 10th. Correcting an erroneous event requires an appended compensating event, which leaves earlier replays unchanged.

Each event therefore carries its recording time, fixed by position in the chain, and the effective date of the recorded fact. These are transaction time and valid time in the temporal-database literature (Snodgrass and Ahn 1985). Recorded-order replay answers the record-time question. An effective-time computation uses the same chain, honoring effective dates and compensating corrections. A court or regulator can obtain both views: what the record asserted on the day and what the legal position on that day was. Both times remain frozen coordinates of the record. The effective-time view derives from them without rewriting them, following the frozen/derived stratification developed in Time in Institutional Computing.

Third, replay supports dispute resolution. Consider the claims “the license was active when we signed” and “the license had been revoked”. Using the chain as evidence requires three conditions. Both parties must apply the transition function under which the events were committed, as condition (iv) requires. They must hold a head at least as recent as the disputed period, obtained through a channel the operator does not control. They must also ask the right temporal question: license validity on a date concerns effective time. Under these conditions, either party can perform the replay that resolves the dispute.

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.

The twin therefore carries digest references: the SHA-256 digests of the compliance passport’s current head, the governance state, and 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. Staleness is detectable when the subordinate head is available, and detected only when someone performs the comparison.

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.

Digest references keep the twin small enough to materialize and fast enough to query while committing to the complete subordinate state without duplicating it.

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.

Each binding type permits different operations. A corridor binding can be suspended, while a pack binding has no suspended state, although its pack can be updated. An obligation binding can be satisfied. A license binding supports renewal or revocation, not satisfaction.

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

Every mutation enters through a projection pipeline. The twin exposes no general-purpose save through which callers could modify arbitrary fields and write them back.

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, ordering, and commitment. Completeness applies at that granularity: every net binding change across a committed mutation produces an event. A change made and reverted within the same mutation produces none. Comparing the before and after states determines event order within the batch, independently of call order. The chain therefore records every committed difference.

The pipeline narrows the space of invalid updates. It provides no method to set the jurisdiction to null, permits only appends to the chain, and requires an event for every committed binding change.

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

For mirrored facts, the external source remains authoritative. The twin adds an explicit record of uncertainty when it detects disagreement with that source.

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 last-written-value record leaves divergence unmarked until a downstream operation fails. Although an analytics dashboard may tolerate that behavior, governance decisions, compliance evaluations, and financial operations need to identify stale inputs.

When a pack binding’s digest differs from the current pack, the system records a source-drift uncertainty on that binding. It detects drift by comparing the recorded digest with the live source, at synchronization points or on demand. The uncertainty set therefore covers only divergence the system has checked for and found. Every downstream consumer sees each active uncertainty. An evaluation can identify its potentially stale inputs and proceed with a caveat, wait for resolution, or mark its 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 binding change, uncertainty, and lifecycle event, at the granularity required for replay and audit. A regulator may instead need a history of completed operations: incorporation, share issuances, foreign registrations, and annual reports. Thousands of field changes obscure that view.

The lawchain provides this view as a second hash-linked chain whose unit of history is the completed operation. Each block carries the operation identifier and proof, jurisdiction, and digests of the governing legal and regulatory packs. It also carries a compliance tensor root, state root, and previous-block digest. The compliance tensor root commits to the entity’s per-domain verdicts at completion. The operator signs every block.

The state root binds the two chronologies by committing to the twin’s event-chain head when the operation completed. By replay identity, that head determines the twin’s state. Each lawchain block therefore commits to the exact history behind its reported state, making disagreement between the chains detectable. A verifier checks the lawchain’s digests, links, and signatures, then finds each committed head on the twin’s event chain. Replay to that head must reproduce the block’s asserted state.

The twin gives the corporation’s current operational state. The lawchain gives the verified sequence of completed legal operations that produced it.

Verification walks either chain backward from its latest block, recomputing digests and checking links under the stated threat model. With an independently obtained head and intact links, a verifier can establish that the records have remained unchanged since obtaining that head. No operator testimony is needed. A head obtained from the operator establishes only internal consistency. A broken link leaves records at or before the break unverified by the held head, whether the cause is fault or tampering. Determinations based on those records remain suspect until the cause is found.

Snapshots and recovery

Full replay becomes costly as an entity accumulates tens of thousands of events over years of operation. A current-state query need not repeat that work.

Snapshots bound replay cost. Periodically, the system serializes the twin’s state and computes its SHA-256 digest, then stores both with the corresponding event sequence number. Recovery replays only subsequent events. By replay identity, this produces the full-replay result whenever the snapshot equals the state reached by full replay at its sequence number. Sound recovery therefore requires the snapshot to have been correct when taken.

The construction grounds that correctness in one of two ways. First, serialize replay’s own output immediately after a verification pass reaches the snapshot’s sequence number. Replay identity then supplies the state at that point. Second, commit the snapshot digest into the event chain, naming the sequence number it covers. The snapshot’s correctness becomes a claim of the record, checkable by later replay to that number and comparison of the recomputed digest. The first replay from genesis that reaches it exposes a snapshot taken from an already damaged twin. Without either grounding, a snapshot inherits damage in the stored twin while passing every digest check.

The digest checks a separate property: whether the snapshot has remained intact since it was taken. Without a digest, the snapshot cannot be verified. Before use, the system deserializes it, recomputes its canonical digest, and compares. A match identifies the bytes over which the digest was computed. A mismatch marks corruption and triggers full replay.

This check has the same party limits as the chain. A digest stored beside a snapshot detects alteration by every party except the operator, who can rewrite both. A digest committed into the event chain is covered by an independently obtained head taken after that commitment. The snapshot’s integrity then depends on the chain’s integrity.

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

Scattered institutional state requires manual reconciliation and leaves consumers without a means to verify the combined record.

An institution with few, simple operations under one jurisdiction’s regulatory regime can work this way. Cross-jurisdictional operations require a consistent view of its complete state. To assess eligibility for foreign qualification in jurisdiction B, three services in jurisdiction A must supply more than answers that might describe different moments.

A delegated program operates the institution within a bounded, revocable authorization. It needs one authoritative object against which to make decisions at machine speed, with explicit uncertainty markers on potentially stale inputs. Querying six services and adjudicating their inconsistencies for each decision cannot supply that object.

An auditor likewise needs linked records to reconstruct the institution’s history. The event chain supplies replay semantics and makes alteration detectable to the holder of an earlier head.

Together, these mechanisms give the twin a precise guarantee. The event chain makes consistency with its complete recorded history verifiable. Digest references make staleness against a subordinate ledger detectable whenever that ledger’s head is available for comparison. Typed bindings and projection constrain committed changes to named, recorded events. Every detected divergence remains on the record, visible to every consumer, until cleared.

Three limits remain. Unchecked divergence lies outside the guarantee. Integrity against the operator requires heads held outside its reach. Changes made outside the system and never recorded produce neither events nor heads to compare. A director removed on paper alone can therefore leave the twin wrong in the opening section’s legal sense while every stated guarantee holds. Within these limits, the construction exposes inconsistency with recorded history, staleness at comparisons it performs, and every divergence it detects.

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.