Lineage-Recorded Provenance for Every Actuation
by Nick Clark | Published April 25, 2026
This disclosure (claiming priority to U.S. Provisional Application No. 64/049,409) describes a method and system in which every governed actuation event records a complete provenance chain — who authorized the action, what evidence supported it, where and when it occurred, why it was admitted, and with what credentialed witness — as a tamper-evident lineage artifact that is itself the auditable record. The lineage replaces server-side operational logs as the primary forensic substrate. Reconstruction of any incident, audit, or regulatory inquiry walks the lineage rather than triangulating across heterogeneous engineering logs, configuration databases, and bespoke telemetry archives. Because the lineage is generated synchronously with the admissibility computation that gates the actuation, the recorded provenance is structurally coupled to the action itself: an actuation that occurred without a corresponding lineage entry is architecturally invalid, and a lineage entry whose chain integrity fails verification cannot be admitted as evidence. The disclosed substrate eliminates the gap between operational behavior and authority record that conventional architectures bridge through human reconciliation, and supplies a uniform forensic surface across deployments that span vendor boundaries, jurisdictional boundaries, and operational eras.
Mechanism
Each actuation event — defined as any commit by a governed actuator that produces a physical effect or an information-state change with operational consequence — emits a lineage entry on commit. The entry is a structured record comprising five field families. The "who" family records the credentialed identity of the platform performing the actuation, the credentialed identity of the operator (if any) that authorized the platform's autonomy budget for the action, and the credentialed identity of any third-party authority whose admission was a precondition. The "what" family records the contemplated action's structured descriptor (mode, target, magnitude, duration, reversibility class) and the actual committed action (which may differ if the actuator's physical realization deviated from the contemplated descriptor). The "where" family records the spatial and platform-state context at commit (position, orientation, velocity, ambient state vector). The "why" family records the composite admissibility computation that gated the commit: the input observations that contributed, each observation's credentialing chain, the policy bundle in force, the harm-minimization deviation (if any) and the policy clause under which the deviation was admitted, and the post-evaluation that confirmed admission. The "with-what-evidence" family records the cryptographic witness binding: the platform's commit signature, the actuator's physical-confirmation signature (if separately credentialed), and the witnessing observers' counter-signatures (if the action was witnessed by peer platforms or authority infrastructure).
The five field families are bound together by a tamper-evident hash chain. Each entry's hash incorporates the prior entry's hash, the present entry's content, and the present entry's signature. Modification of any entry — or insertion of any entry between two existing entries — invalidates the chain at the modification point and at every subsequent point. Verification walks the chain forward from a credentialed anchor to detect any break. The anchor itself is a periodically refreshed external commitment whose authenticity does not depend on the platform's continued operation; even if the platform is destroyed or its keys are compromised after the anchor's emission, prior entries up to the anchor remain verifiable against the external commitment.
The lineage is not an after-the-fact reconstruction. It is generated synchronously with the actuation: the admissibility computation that gates the commit produces, as its byproduct, the "why" field family that the lineage records. The platform cannot commit without producing the entry, and cannot produce the entry without exposing the inputs the admissibility computation actually consumed. The architectural coupling is what makes the lineage reconstruction-grade rather than reconstruction-approximate. A tampering attempt that modifies the recorded inputs to make a refused commit appear admissible would either fail signature verification on the inputs themselves (because each input observation carries its own originating credential) or would expose the modified inputs to subsequent contradiction by peer platforms whose lineage records a different value for the same observation at the same instant.
Lineage entries are emitted to two storage targets concurrently: a platform-local store that admits append at the speed of the platform's commit cadence, and a substrate-broadcast emission that propagates the entry's hash and an authenticated digest onto the spatial mesh. The substrate emission ensures that even if the platform-local store is subsequently destroyed or tampered, the entry's hash is observed and stored by peer platforms within propagation range, providing an external corroboration surface that does not depend on operator-managed archival infrastructure. Authorities querying the substrate for a particular platform's recent activity can confirm the existence and ordering of the platform's lineage entries without holding the entries' contents, then request the contents through a credentialed retrieval if and when an inquiry warrants.
Each lineage entry references the immediately prior entry by its hash, but also references the prior entry of the same actuator subsystem and the prior entry under the same policy bundle, producing a multi-axis chain structure. The multi-axis structure allows audit to walk the lineage along the temporal axis (what happened next), the actuator axis (what did this subsystem do prior), or the policy axis (what other actuations occurred under this same policy authority), without requiring the auditor to reconstruct cross-references from an external index.
Operating Parameters
Lineage entry size is bounded by the size of the credentialing references (typically thirty-two to sixty-four bytes per credential), the size of the structured action descriptor (typically two hundred fifty-six bytes to two kilobytes), and the size of the admissibility-input reference list (typically five to fifty references). Practical entry sizes range from approximately one kilobyte for a simple actuation under stable governance to approximately sixteen kilobytes for a complex actuation drawing on many observations. Entries are stored uncompressed at emission to preserve byte-exact verifiability, with optional dictionary compression applied at archival to reduce long-term storage cost without altering the hash-chain semantics.
Entry generation latency is bounded below by the cryptographic signing cost (microseconds on contemporary embedded hardware) and bounded above by the inherent latency of the admissibility computation that the entry transcribes. Lineage emission contributes negligible overhead beyond the admissibility decision itself. Platforms operating at high commit cadence (kilohertz-class actuator subsystems) employ a batched-commit emission strategy in which multiple actuator commits within a single admissibility cycle share a common "why" field family and emit individual "what" and "where" descriptors against the shared family, reducing per-commit overhead while preserving per-commit identifiability.
Lineage retention is configurable per deployment class. Aviation deployments default to retaining lineage for the airframe lifetime plus regulatory residual; medical deployments default to retaining lineage for the patient-record retention applicable in the jurisdiction; vehicular deployments default to a five-to-ten-year retention; defense deployments default to retention governed by the operating coalition's records policy. Retention is enforced architecturally rather than by storage management policy: the credentialing chain in the lineage references the retention obligation, and any retention-management agent attempting to delete an entry before the obligation expires must itself produce a credentialed authorization that the lineage records as a deletion entry preserving the deleted entry's hash.
Cross-recognition between issuing platforms and auditing authorities is governed by a credential-recognition matrix. An auditing authority that recognizes the issuing platform's credentialing root admits the lineage as evidence; an authority that does not recognize the root may still admit the lineage through a recognized intermediate. The recognition matrix is itself a credentialed observation distributed through the substrate, allowing recognition to evolve over operational time as new auditing authorities are credentialed or existing roots are rotated.
Audit-query interfaces expose the lineage to credentialed inspectors through a structured query surface that supports walks along the temporal, actuator, and policy axes; aggregations across action classes; and selective disclosure of fields that the inspector's credential class permits. Query results carry their own credentialing chain, allowing the inspector to subsequently present the result as evidence in a downstream proceeding without requiring the issuing platform to be online at the time of presentation.
Alternative Embodiments
In a first alternative embodiment, the lineage hash chain is anchored periodically into a public commitment substrate (notarization service, public ledger, broadcast time-stamping authority), producing external corroboration for the chain's existence at the anchor time. External anchoring defeats post-hoc rewriting of the chain by an actor in possession of the platform's signing keys, because rewriting would require the rewritten chain's anchors to coincide with the externally observed anchors, which the public substrate's immutability prevents.
In a second alternative embodiment, the "why" field family is supplemented with an executable replay artifact — a serialized snapshot of the admissibility computation sufficient to re-execute the decision deterministically given the original input observations. Replay allows audit to verify not only that the recorded admission was issued but that the admission would issue again under the same inputs. Replay artifacts are stored separately from the entry's primary content and are referenced by hash, allowing the auditor to demand replay only when the inquiry warrants the additional retrieval cost.
In a third alternative embodiment, the witnessing field family includes counter-signatures from peer platforms in the spatial mesh, producing a multi-witness lineage that survives compromise of any single platform's signing keys. Multi-witness lineage is configured for actuations whose evidentiary stakes exceed the single-witness threshold. The witness population is determined at commit time by the platform's then-current admissibility framework rather than enumerated in advance, allowing the witness set to reflect actual peer presence rather than an idealized topology.
In a fourth alternative embodiment, the lineage is selectively redacted before audit disclosure, with the redaction itself being credentialed and verifiable. The auditor confirms that the redacted entries existed and were of the declared class, without having access to the entry contents that the redacting authority withheld. Selective redaction supports audit under regimes where some content is privileged (medical confidentiality, defense classification, trade secret) while preserving the integrity of the unredacted record. The redaction authority's credential is itself recorded in the lineage, allowing subsequent inquiry to challenge whether the redaction was authorized.
In a fifth alternative embodiment, the lineage is sharded across the platform's local storage, an operator-managed archive, and a regulatory escrow, with each shard independently verifiable and the full lineage reconstructible from any two shards. The sharding embodiment defeats single-point loss while preserving privacy and operator-control properties that no single party should hold the complete record. Shard reconstitution is itself a credentialed operation; an attempt to reconstitute by a party not holding the requisite credentials fails cryptographically.
In a sixth alternative embodiment, the lineage entry's "what" field family is augmented with a counterfactual descriptor — a record of the action that would have been committed had the admissibility computation rejected the contemplated action. The counterfactual descriptor enables audit to evaluate not only what happened but what the platform would have done in the alternative, supporting analysis of the admissibility framework's behavior at decision boundaries.
Composition with Other Primitives
Lineage-recorded provenance composes with the credentialed-observation primitive: every observation referenced in the "why" family is itself a credentialed lineage entry on the issuing platform, allowing audit to walk from an actuation back through the originating observations and from each observation back to the platform that emitted it. The transitive walk is what makes incident reconstruction structurally complete. An auditor investigating a downstream actuation can establish, without ambiguity, the full upstream evidentiary chain that contributed to the commit, including peer-platform observations, sensor readings, and authority broadcasts.
Composition with the staged-commitment primitive produces nested lineage: each stage of a multi-stage commit emits its own entry, with the executed-stage entry referencing the witnessed-stage entry referencing the tentative-stage entry. Audit reconstructs not only that the actuation occurred but that it advanced through the stages in order, with admissibility re-evaluated at each boundary. Abort outcomes at any pre-executed boundary produce their own lineage entries with equal evidentiary weight, allowing audit to confirm not only what was committed but what was contemplated and rejected.
Composition with the harm-minimization deviation primitive records, on the same lineage entry, both the policy-conformant action that admissibility gated and the deviation the platform actually committed, together with the credential under which the deviation was authorized. The dual record allows audit to assess not only whether the deviation was authorized but whether the authorization itself was admissible. The deviation credential's chain is recorded inline, allowing the auditor to evaluate the credential's own validity at the time of commit without requiring an external lookup.
Composition with the policy-distribution primitive produces a closed audit loop: the policy bundle in force at the time of an actuation is referenced in the actuation's lineage by its bundle identifier; the bundle's admission lineage on the platform is itself a lineage entry; the bundle's issuance is a lineage entry on the issuing authority. Audit walking the loop confirms that the policy actually in force at commit time was the policy the issuing authority intended to be in force, eliminating the configuration-drift gap that plagues conventional governance audit.
Distinction over Prior Art
Conventional autonomous-system logging architectures emit operational telemetry — sensor readings, planner outputs, actuator commands, fault codes — into vendor-specific log streams that are subsequently archived for engineering analysis. The streams capture what the system did but do not capture the architectural authority under which it did so. Reconstruction of authority requires triangulation across configuration management records, OTA update histories, regulatory correspondence, and engineering documentation, none of which are bound cryptographically to the operational telemetry. The disclosed lineage subsumes both telemetry and authority within a single tamper-evident record, eliminating the triangulation requirement.
Conventional black-box recorders (aviation FDR/CVR, EDR in vehicular contexts) record a fixed inventory of physical-state parameters with strong tamper resistance but no architectural-authority field. The recorders answer the engineer's question (what did the platform do) but not the regulator's question (under what authority). The disclosed mechanism preserves the engineering-grade physical-state record while extending it with the authority record that regulatory and judicial inquiry actually requires.
Conventional governance audit trails in IT systems (SIEM, configuration audit, change management logs) record authority but in a substrate disjoint from the operational substrate, requiring human reconciliation to establish that a recorded change actually took effect operationally. The disclosed lineage is structurally one substrate, eliminating the reconciliation gap. A change recorded in lineage is by construction a change that took effect; a change that purports to have occurred without a lineage entry did not occur.
Conventional provenance frameworks in scientific data management (W3C PROV and similar) describe provenance as an annotation layer over data artifacts, applied retrospectively for documentation. The disclosed mechanism applies provenance synchronously at the point of action and binds the provenance cryptographically to the action's commit, producing a record whose integrity does not depend on the curator's continued availability or the annotation system's operational state.
Disclosure Scope
The disclosure encompasses the lineage entry structure across the five field families; the tamper-evident hash chaining; the synchronous emission coupled to the admissibility computation; the alternative embodiments described above; the cross-recognition matrix governing audit admission; and the composition with the credentialed-observation, staged-commitment, harm-minimization-deviation, and policy-distribution primitives. The scope extends to lineage emission by platforms operating in vehicular, aviation, maritime, surgical, industrial-process-control, and defense deployment classes, and to consumption of the lineage by regulatory authorities, judicial proceedings, fleet-operator audit, and insurer subrogation analysis. The scope further extends to lineage retention regimes ranging from short-window operational retention to long-window regulatory retention, and to hybrid embodiments in which platforms emit lineage through the disclosed substrate while continuing to emit conventional engineering telemetry through legacy channels for backward compatibility with existing analysis tooling.