Modern AI systems are hard to reconstruct after the fact because many materially relevant choices are resolved only at runtime and are not durably recorded. The article frames this as a distinction between reproducibility (whether a result can be produced again under equivalent conditions) and historical reconstructability (whether the conditions and dependencies of a past execution can still be identified). The central claim is that reconstructability is a system property that must be established during execution, not inferred later from surviving artifacts.
The core problem
Imagine an AI-assisted decision that must be examined six months after it was made. Rerunning the system may yield a different answer, yet an investigator often needs to know which model endpoint, which input transformation, which retrieved context, which tool contract, and which runtime configuration were used at the time. The industry is good at measuring capability — benchmarks, task success, latency, cost — but much less good at preserving the runtime knowledge required to understand past executions.
Reconstructability asks whether the original execution's conditions can still be identified even when repeating the execution would not produce an identical result.
Why current records fall short
AI runtimes commonly assemble part of the dependency graph only during execution. A deployment records the declared configuration before a run, but at inference time additional decisions are made: model aliases may resolve, preprocessing steps may apply, data and feature states may be retrieved, safety controls and policy versions may be evaluated, and agentic components can introduce memory, tools, delegation, or external effects. These execution-specific selections are runtime bindings: the facts about what the execution actually used.
The article illustrates this with a hypothetical execution E891. The deployment might declare application revision 8f31c2 and model v17, yet the execution can bind prompt h31, retrieval index r42, documents d182@17 and d761@4, tool contract h42, policy v8, and effect e3. Because some of these dependencies were chosen only as the run proceeded, later inspection of the deployment or current state does not reliably reconstruct what E891 actually used.
Current-state records are a lossy projection
Version control, transaction logs, and distributed tracing each preserve different views of a run, but none by itself guarantees the materially relevant execution-specific configuration. As dependencies mutate, different historical executions may leave the same observable evidence in the current state. An identifier that still exists does not prove it was used, nor that the historical state it referred to remains resolvable. Therefore reconstructability requires durable binding relations and continued access to the historical states they identify.
Existence is not usage
Concurrent versions, caches, retries and asynchronous changes make it unreliable to infer usage from mere existence. W3C PROV already provides the semantic distinction (an activity can use an entity), so the missing piece is not a new provenance vocabulary but a runtime obligation to record which dependency a particular execution used and to preserve an identity that can be resolved later.
OpenTelemetry can carry dependency identifiers through attributes, links, or context, but encoding an identifier in traces does not preserve its historical meaning. Instrumentation can annotate preservation metadata, but it cannot guarantee durable storage or later resolution of the referenced states.
Two required properties: binding and resolution integrity
For a defined class of executions and a given retention period, the system must preserve:
- Binding integrity: a reliable record of which dependency versions and states an execution actually used.
- Resolution integrity: continued ability to resolve those recorded identities to the historical states they denote.
Without both properties, the preserved artifacts do not enable faithful reconstruction.
Preservation requires failure semantics
If an execution commits an external effect (for example, a tool performs an action) but the usage record that links that effect to its authorizing policy, contract and execution context fails to reach durable storage, the system's historical record diverges from the external world. This is not ordinary telemetry loss: the architecture must define what happens when preservation records cannot be stored. Options include requiring a durable usage record before committing effects, atomically persisting effect intent and preservation record (for example via a transactional outbox), quarantining the execution for reconciliation, or initiating compensating actions. Absent explicit semantics, reconstructability cannot be guaranteed.
A preservation plane and Orrery
Existing building blocks — provenance and lineage models, tracing, registries and content-addressed stores — help, but none by itself enforces a runtime obligation to preserve an execution-scoped dependency closure. The author defines a preservation plane: the contract and machinery that record what to capture, how records become durable, and how referenced historical states remain resolvable as surrounding systems evolve.
Orrery is presented as a reference architecture that applies this principle: materially relevant runtime bindings are captured when they occur and retained together with resolvable identities for the historical states they reference.
AIGov Core: testing reconstructability
AIGov Core is cited as a limited implementation of the principle. Its evidence ledger stores hash-chained events and its replay engine can reconstruct a governance verdict from a stored export without querying live state. A companion check labels exports Ready, Partial, or NotReady depending on unresolved lineage, missing policy artifacts, version drift, or replay failure. This demonstrates that reconstructability can be tested, but it cannot recover bindings that were never recorded.
Conclusion: design, test and enforce reconstructability during execution
The preservation gap is the mismatch between what an execution depends on and what the system persists. Closing that gap requires a runtime obligation: whenever an execution binds materially relevant state, the system must record the binding, preserve a durable identity for the dependency, and retain access to the historical state it denotes for the required retention period. Reconstructability is therefore not a by-product of capability or observability; it is an architectural property that must be designed, tested and enforced at execution time.
