P14 — AIEP — Deterministic Evidence Lifecycle Without Retention
Publication Date: 2026-02-26 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1
Field of the Invention
[0001] The disclosure relates to deterministic processing and lifecycle control of digital evidence within computing systems.
[0002] More particularly, the disclosure concerns a deterministic evidence lifecycle mechanism that enables cryptographically verifiable use of evidence without retaining the evidence payload, by storing only canonical commitments and lifecycle control records.
Framework Context
[0003] This invention operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, the entire contents of which are incorporated herein by reference.
[0004] The present invention extends deterministic canonicalisation, governance, and execution integrity mechanisms defined in the AIEP environment while remaining independently implementable as described herein.
Background
[0005] Computing systems frequently ingest, process, and evaluate digital evidence objects including documents, structured datasets, logs, telemetry records, multimedia artefacts, and externally sourced data.
[0006] Conventional architectures persist full evidence payloads to preserve auditability and allow reprocessing. Such retention may conflict with privacy regulations, contractual constraints, storage limitations, or data minimisation requirements.
[0007] Where payloads are deleted without prior cryptographic commitment, systems lose the ability to verify that a particular version of evidence was used in downstream processing.
[0008] Partial redaction techniques may alter evidence content in ways that break reproducibility or invalidate prior cryptographic identifiers.
[0009] Existing systems do not provide:
(a) verifiable proof of evidence use without retaining the payload; (b) cryptographic commitment to canonicalised evidence bound to lifecycle constraints; (c) deterministic eligibility gating based solely on stored commitment records; (d) fail-closed suppression of processing when lifecycle integrity conditions are not satisfied; or (e) deterministic replay of eligibility determinations independent of current system time.
[0010] There exists a need for a deterministic lifecycle mechanism that enables verifiable evidence usage, enforces permitted-use constraints, and gates downstream execution based on deterministic lifecycle state without requiring payload retention.
Summary of the Disclosure
[0011] A computer-implemented deterministic evidence lifecycle method is executed by one or more processors.
[0012] An evidence payload is received together with provenance metadata including source identifier, collection timestamp recorded as data, and schema version identifier.
[0013] The evidence payload is canonicalised under a version-bound schema to produce CanonicalEvidence.
[0014] An EvidenceCommitment is computed as:
EvidenceCommitment = H(CanonicalEvidence || ProvenanceMetadata || SchemaVersionId)
[0015] A LifecycleRecord is generated comprising EvidenceCommitment, SchemaVersionId, provenance commitments, PermittedUseScope identifier, RetentionPolicy identifier, ExpiryTime recorded as data, and CreationTimestamp recorded as data.
[0016] The LifecycleRecord is appended to an immutable store.
[0017] The evidence payload is deleted or not retained beyond commitment generation.
[0018] Subsequent processing operations reference evidence solely by EvidenceCommitment and PermittedUseScope.
[0019] Prior to execution of any operation referencing the EvidenceCommitment, processors verify lifecycle eligibility conditions.
[0020] If eligibility cannot be established, execution is suppressed in a fail-closed manner.
[0021] The technical effect is modification of processor execution behaviour by enforcing cryptographically verifiable evidence usage without payload retention and by gating downstream computation based on deterministic lifecycle constraints.
Brief Description of the Drawings
[0022] Figure 1 illustrates the evidence commitment and payload deletion flow from receipt through canonicalisation, commitment computation, LifecycleRecord storage, and payload deletion.
[0023] Figure 2 illustrates the LifecycleRecord structure and its constituent bound fields.
[0024] Figure 3 illustrates the deterministic eligibility verification gate applied prior to any processing operation referencing the EvidenceCommitment.
[0025] Figure 4 illustrates deterministic replay equivalence across distributed nodes operating with identical LifecycleRecord entries and schema identifiers.
ASCII Drawings
Figure 1 — Evidence Commitment and Payload Deletion Flow
+---------------------------+
| Evidence Payload |
+------------+--------------+
|
v
+------------+--------------+
| Canonicalisation |
| (Version-Bound Schema) |
+------------+--------------+
|
v
+------------+--------------+
| EvidenceCommitment |
| H(CanonicalEvidence || |
| ProvenanceMetadata || |
| SchemaVersionId) |
+------------+--------------+
|
v
+------------+--------------+
| LifecycleRecord |
| (Append-Only Store) |
+------------+--------------+
|
v
+------------+--------------+
| Delete Payload |
| (non-retention enforced) |
+---------------------------+
Figure 2 — LifecycleRecord Structure
+--------------------------------------------+
| LifecycleRecord |
|--------------------------------------------|
| EvidenceCommitment |
| SchemaVersionId |
| ProvenanceCommitment |
| PermittedUseScope identifier |
| RetentionPolicy identifier |
| ExpiryTime (recorded as data) |
| CreationTimestamp (recorded as data) |
+--------------------------------------------+
|
v
+--------------------------------------------+
| Append-Only Immutable Store |
+--------------------------------------------+
Figure 3 — Deterministic Eligibility Verification Gate
+---------------------------+
| Processing Request |
| (ref: EvidenceCommitment)|
+------------+--------------+
|
v
+------------+--------------+
| Lifecycle Verification |
| (a) Commitment exists? |
| (b) Scope valid? |
| (c) Not expired? |
| (d) Policy compliant? |
+------------+--------------+
|
+------+------+
No Yes
| |
v v
+-----------+ +--------------+
| SUPPRESS | | Execute |
| Execution | | Operation |
| Fail- | +--------------+
| Closed |
| |
| Append |
| Rejection |
| Record |
+-----------+
Figure 4 — Deterministic Replay Across Distributed Nodes
Node A Node B
+--------------------+ +--------------------+
| LifecycleRecord | | LifecycleRecord |
| (identical) | | (identical) |
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| SchemaVersionId | | SchemaVersionId |
| (identical) | | (identical) |
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| Eligibility | | Eligibility |
| Determination | | Determination |
+---------+----------+ +---------+----------+
| |
+------------------+----------------+
|
v
+------------------------+
| Equivalence Verified |
| (stored timestamps |
| used — does not |
| depend on current |
| system time) |
+------------------------+
Detailed Description
1. Canonicalisation and Commitment Generation
[0026] Upon receipt of an evidence payload, processors canonicalise the payload under a version-bound schema defining serialisation format, encoding rules, stable ordering, and required metadata fields.
[0027] Canonicalisation removes non-semantic variation while preserving all semantically relevant content.
[0028] EvidenceCommitment is computed as a cryptographic hash over CanonicalEvidence, ProvenanceMetadata, and SchemaVersionId.
[0029] Inclusion of SchemaVersionId ensures that modification of canonicalisation rules produces distinct commitments, preventing cross-version commitment collisions.
2. LifecycleRecord Creation
[0030] The LifecycleRecord binds EvidenceCommitment to lifecycle governance constraints.
[0031] Provenance metadata may include digital signatures, source identifiers, collection method identifiers, and chain-of-custody commitments, each bound within the LifecycleRecord.
[0032] The LifecycleRecord is appended to an immutable store such that modification or deletion is not permitted.
[0033] The immutable store may be implemented as a ledger, append-only database, or cryptographically verifiable repository.
3. Payload Deletion
[0034] After commitment generation and LifecycleRecord storage, the evidence payload is removed from persistent storage unless an explicit retention exception rule applies under the RetentionPolicy.
[0035] Deletion may include overwriting temporary buffers and clearing caches to enforce non-retention.
[0036] Subsequent operations rely solely on EvidenceCommitment and LifecycleRecord data.
4. Deterministic Eligibility Verification
[0037] A processing request references an evidence object by EvidenceCommitment.
[0038] Processors verify:
(a) existence of the EvidenceCommitment in the immutable store; (b) validity of PermittedUseScope relative to the requested operation; (c) non-expiry under ExpiryTime; and (d) compliance with RetentionPolicy constraints.
[0039] Verification is performed using stored LifecycleRecord data only and does not require access to the original payload.
5. Fail-Closed Execution Control
[0040] If any eligibility condition fails, processors suppress execution of the requested operation in a fail-closed manner.
[0041] Suppression includes preventing allocation of processor cycles and memory associated with the operation.
[0042] A deterministic rejection record is appended to the immutable store identifying the violated lifecycle constraint and the EvidenceCommitment reference.
6. Re-Presentation and Verification
[0043] Where an authorised party re-presents the original evidence payload, processors may recompute EvidenceCommitment under the same SchemaVersionId.
[0044] If the recomputed EvidenceCommitment matches the stored commitment, equivalence is verified.
[0045] Replay uses timestamps recorded as data within the LifecycleRecord and does not depend on current system time.
7. Distributed Determinism
[0046] Distributed nodes possessing identical LifecycleRecord entries and schema identifiers produce identical eligibility determinations.
[0047] Deterministic lifecycle gating therefore yields identical and reproducible execution outcomes across distributed deployments.
Claims
-
A computer-implemented method for deterministic evidence lifecycle control without payload retention, the method comprising: (a) receiving an evidence payload and provenance metadata including a collection timestamp recorded as data and a schema version identifier; (b) canonicalising the evidence payload under a version-bound schema to produce CanonicalEvidence; (c) computing an EvidenceCommitment as H(CanonicalEvidence || ProvenanceMetadata || SchemaVersionId); (d) generating a LifecycleRecord binding the EvidenceCommitment, SchemaVersionId, PermittedUseScope identifier, RetentionPolicy identifier, ExpiryTime, and CreationTimestamp, each recorded as data; (e) appending the LifecycleRecord to an immutable store; (f) deleting or not persisting the evidence payload beyond commitment generation; and (g) prior to executing a processing operation referencing the EvidenceCommitment, verifying lifecycle eligibility against the LifecycleRecord and, upon failure of any eligibility condition, suppressing execution in a fail-closed manner.
-
The method of claim 1 wherein eligibility verification confirms existence of the EvidenceCommitment, validity of PermittedUseScope, non-expiry under ExpiryTime, and compliance with RetentionPolicy constraints.
-
The method of claim 1 wherein eligibility verification is performed without access to the evidence payload.
-
The method of claim 1 wherein a deterministic rejection record identifying the violated lifecycle constraint is appended to the immutable store upon eligibility failure.
-
The method of claim 1 wherein replay recomputes EvidenceCommitment using stored LifecycleRecord fields and does not depend on current system time.
-
The method of claim 1 wherein distributed nodes possessing identical LifecycleRecord entries and identical SchemaVersionId produce identical eligibility determinations.
-
A computing system comprising one or more processors and memory storing instructions which, when executed, cause the processors to perform the method of any of claims 1 to 6.
-
A non-transitory computer-readable medium storing instructions which, when executed, cause one or more processors to perform the method of any of claims 1 to 6.
Licence
Any person is granted a perpetual, irrevocable, worldwide, royalty-free licence to make, use, implement, modify, or distribute any system or method described in this disclosure for any purpose, without restriction, under the Apache License 2.0.
A copy of the Apache License 2.0 is available at https://www.apache.org/licenses/LICENSE-2.0
Abstract
A deterministic evidence lifecycle without payload retention is disclosed. Evidence payloads are canonicalised under a version-bound schema and an EvidenceCommitment is computed as H(CanonicalEvidence || ProvenanceMetadata || SchemaVersionId). A LifecycleRecord binding the commitment, permitted-use scope, retention policy, and expiry constraints is appended to an immutable store. The evidence payload is deleted or not retained after commitment generation. Processing operations referencing the EvidenceCommitment are gated by deterministic eligibility verification against the LifecycleRecord, and execution is suppressed in a fail-closed manner when eligibility conditions are not satisfied. Replay uses stored timestamps and does not depend on current system time. The system modifies processor execution behaviour by enforcing cryptographically verifiable evidence usage without payload retention across distributed nodes.