P27 — AIEP — Deterministic Multi-System Evidence Interoperability
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 interoperable admissible determination systems within computing environments.
[0002] More particularly, the disclosure concerns a deterministic multi-system evidence interoperability mechanism enabling independent evidence evaluation systems to exchange evidence artefacts in canonical form, evaluate compatibility deterministically against a versioned registry, and reject incompatible artefacts without semantic translation or heuristic adaptation.
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] Independent admissible determination systems frequently exchange evidence artefacts across organisational, regulatory, and technical boundaries.
[0006] Conventional interoperability approaches rely on translation layers, middleware adapters, semantic mapping engines, and manual reconciliation. These approaches introduce ambiguity in representation, hidden transformation logic, non-reproducible compatibility outcomes, and dependency on discretionary interpretation.
[0007] Non-deterministic interoperability prevents consistent cryptographic binding of exchanged evidence, breaks audit trails, and produces divergent admissibility outcomes when identical artefacts are evaluated by different receiving systems.
[0008] Existing systems do not provide:
(a) exchange of evidence artefacts in a canonical structured representation with deterministic field ordering, explicit typing metadata, and version identifiers; (b) deterministic validation of canonical structure prior to compatibility evaluation; (c) version-bound retrieval of interoperability rules from an immutable registry without fallback translation; (d) cryptographic binding of exchange outcomes to the interoperability registry version applied; or (e) fail-closed rejection of artefacts that violate canonical schema, fail compatibility checks, or reference unsupported protocol versions.
[0009] There exists a need for a deterministic interoperability mechanism in which evidence artefacts are exchanged in canonical form, compatibility is evaluated deterministically against versioned registry rules, and incompatible artefacts are rejected without semantic translation or heuristic adaptation.
Summary of the Disclosure
[0011] A computer-implemented deterministic multi-system evidence interoperability method is executed by one or more processors.
[0012] Participating systems exchange evidence artefacts in a canonical structured representation comprising deterministic field ordering, explicit typing metadata, canonical serialisation, and version identifiers. Non-canonical representations are rejected upon receipt.
[0013] Upon receipt of an artefact, the receiving system validates canonical structure against the InteroperabilityRegistry and retrieves the applicable interoperability rules deterministically using the artefact’s schema version identifier and protocol version identifier.
[0014] The InteroperabilityRegistry defines compatible canonical schema versions, permitted equivalence mappings, required validation constraints, and protocol alignment requirements. Registry entries are versioned and immutable once published.
[0015] Compatibility is evaluated deterministically using explicit equivalence constraints retrieved from the registry. No fallback translation mechanism, semantic mapping, or heuristic adaptation is permitted.
[0016] An InteroperabilityHash is computed as:
InteroperabilityHash = H(CanonicalArtefact || InteroperabilityRuleSetVersionId || InteroperabilityRegistryVersionId)
[0017] An ExchangeRecord is generated binding sending system identifier, receiving system identifier, InteroperabilityRuleSetVersionId, InteroperabilityRegistryVersionId, InteroperabilityHash, compatibility outcome, and a timestamp recorded as data, and appended to an immutable store.
[0018] If an artefact violates canonical schema, fails registry-defined compatibility checks, or references an unsupported protocol version, it is deterministically rejected and execution is suppressed in a fail-closed manner.
[0019] The technical effect is modification of computing system behaviour by enforcing deterministic cross-system evidence exchange without semantic translation, enabling reproducible compatibility verification and audit-verifiable interoperability across distributed independent systems.
Brief Description of the Drawings
[0020] Figure 1 illustrates the canonical evidence exchange pipeline from sending system through canonical representation, transmission, receipt, and structure validation at the receiving system.
[0021] Figure 2 illustrates the deterministic compatibility evaluation pipeline from InteroperabilityRegistry retrieval through equivalence constraint application and fail-closed rejection or acceptance.
[0022] Figure 3 illustrates the ExchangeRecord hash binding architecture showing the cryptographic relationship between the canonical artefact, InteroperabilityRuleSetVersionId, and InteroperabilityRegistryVersionId.
[0023] Figure 4 illustrates deterministic replay equivalence across distributed receiving nodes operating under identical InteroperabilityRegistry versions.
ASCII Drawings
Figure 1 — Canonical Evidence Exchange Pipeline
SENDING SYSTEM RECEIVING SYSTEM
+--------------------+ +--------------------+
| Evidence Artefact | | Receipt |
| Canonicalised: | +--------+-----------+
| - Det. field order | |
| - Explicit typing | v
| - Canonical serial.| +--------+-----------+
| - Version IDs | | Canonical Structure|
+--------+-----------+ | Validation |
| +--------+-----------+
v |
+--------+-----------+ +--------+-----------+
| Transmit in |--------> Valid? |
| Canonical Form | +--------+-----------+
+--------------------+ |
+--------+-----------+
Yes No
| |
v v
+--------+-----+ +-----------+
| Proceed to | | REJECT |
| Compatibility| | Fail- |
| Evaluation | | Closed |
+--------------+ +-----------+
Figure 2 — Deterministic Compatibility Evaluation Pipeline
+---------------------------+
| InteroperabilityRegistry |
| Lookup |
| (SchemaVersionId + |
| ProtocolVersionId) |
+------------+--------------+
|
+------+------+
Found Not Found /
| Unsupported
v |
+------------------+ +-----------+
| Apply Equivalence| | REJECT |
| Constraints | | Fail- |
| Deterministically| | Closed |
| | +-----------+
| - Schema compat. |
| - Equivalence |
| mappings |
| - Validation |
| constraints |
| - Protocol align.|
+--------+---------+
|
+------+------+
Compatible Incompatible
| |
v v
+----------+ +-----------+
| Generate | | REJECT |
| Exchange | | Fail- |
| Record | | Closed |
| Append to| | Append |
| Immutable| | Rejection |
| Store | | Record |
+----------+ +-----------+
Figure 3 — ExchangeRecord Hash Binding Architecture
CanonicalArtefact ----+
\
InteroperabilityRuleSetVersionId ---+--> H(CanonicalArtefact ||
/ RuleSetVersionId ||
InteroperabilityRegistryVersionId--+ RegistryVersionId)
|
v
+------------------------------------+
| ExchangeRecord |
|------------------------------------|
| Sending system identifier |
| Receiving system identifier |
| InteroperabilityRuleSetVersionId |
| InteroperabilityRegistryVersionId |
| InteroperabilityHash |
| Compatibility outcome |
| Timestamp (stored data) |
+------------------------------------+
|
v
+------------------------------------+
| Append-Only Immutable Store |
+------------------------------------+
Figure 4 — Deterministic Replay Across Distributed Receiving Nodes
Receiving Node A Receiving Node B
+--------------------+ +--------------------+
| CanonicalArtefact | | CanonicalArtefact |
| (identical) | | (identical) |
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| Interoperability | | Interoperability |
| Registry | | Registry |
| (identical version)| | (identical version)|
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| InteroperabilityHash | InteroperabilityHash
+---------+----------+ +---------+----------+
| |
+------------------+----------------+
|
v
+------------------------+
| Hash Equivalence |
| Verification |
| (stored timestamps |
| used — does not |
| depend on current |
| system time) |
+------------------------+
Detailed Description
1. Canonical Evidence Representation
[0024] Participating systems exchange evidence artefacts in a canonical structured representation comprising:
(a) deterministic field ordering under InteroperabilityRegistry-defined rules; (b) explicit typing metadata identifying field types and encoding; (c) canonical serialisation producing identical byte representations for identical semantic content; and (d) version identifiers including schema version identifier and protocol version identifier.
[0025] Non-canonical representations are rejected upon receipt without processing.
[0026] The canonical representation format is defined in the InteroperabilityRegistry and is version-bound, ensuring that format expectations are reproducible across all participating systems.
2. InteroperabilityRegistry
[0027] The InteroperabilityRegistry defines for each supported combination of schema version and protocol version:
(a) compatible canonical schema versions; (b) permitted equivalence mappings between fields across schema versions; (c) required validation constraints confirming structural and semantic integrity; and (d) protocol alignment requirements confirming that the artefact was produced under a supported protocol version.
[0028] Registry entries are versioned and immutable once published. New interoperability requirements are addressed by publishing new registry versions as separate entries.
3. Deterministic Compatibility Evaluation
[0029] Upon receipt of a canonically structured artefact, the receiving system validates canonical structure against the InteroperabilityRegistry.
[0030] The applicable interoperability rules are retrieved deterministically using the artefact’s schema version identifier and protocol version identifier.
[0031] No fallback translation mechanism, semantic mapping engine, or heuristic adaptation is permitted at any stage of compatibility evaluation.
[0032] Compatibility is evaluated by applying explicit equivalence constraints, validation constraints, and protocol alignment requirements retrieved from the registry.
4. Hash Binding and ExchangeRecord Generation
[0033] An InteroperabilityHash is computed as:
InteroperabilityHash = H(CanonicalArtefact || InteroperabilityRuleSetVersionId || InteroperabilityRegistryVersionId)
[0034] An ExchangeRecord is generated comprising:
(a) sending system identifier; (b) receiving system identifier; (c) InteroperabilityRuleSetVersionId; (d) InteroperabilityRegistryVersionId; (e) InteroperabilityHash; (f) compatibility outcome; and (g) timestamp recorded as a data field.
[0035] The ExchangeRecord is appended to an append-only immutable store.
5. Fail-Closed Rejection
[0036] If an artefact violates canonical schema, fails registry-defined compatibility checks, or references an unsupported or unavailable protocol version, the artefact is deterministically rejected.
[0037] Execution of any downstream operation dependent on the artefact is suppressed in a fail-closed manner.
[0038] A deterministic rejection record is appended identifying the violated constraint, InteroperabilityRuleSetVersionId, and the validation stage at which failure occurred.
6. Reproducible Exchange State
[0039] Successful interoperability produces an ExchangeRecord forming a deterministic compatibility record, canonical exchange commitment, and version-bound validation artefact appended to the immutable store.
[0040] These records enable audit verification of all exchange events across participating systems.
7. Deterministic Replay
[0041] Replay is performed using stored CanonicalArtefact, InteroperabilityRuleSetVersionId, and InteroperabilityRegistryVersionId.
[0042] Replay recomputes InteroperabilityHash using stored fields and does not depend on current system time.
[0043] Distributed receiving nodes operating with identical canonical artefacts and identical InteroperabilityRegistry versions produce identical compatibility outcomes and identical InteroperabilityHash values.
Claims
-
A computer-implemented method for deterministic multi-system evidence interoperability, the method comprising: (a) exchanging evidence artefacts in a canonical structured representation comprising deterministic field ordering, explicit typing metadata, canonical serialisation, and version identifiers, and rejecting non-canonical representations upon receipt; (b) validating canonical structure of a received artefact against an InteroperabilityRegistry and retrieving applicable interoperability rules deterministically using the artefact’s schema version identifier and protocol version identifier, without fallback translation or heuristic adaptation; (c) evaluating compatibility by applying explicit equivalence constraints, validation constraints, and protocol alignment requirements retrieved from the InteroperabilityRegistry; (d) computing an InteroperabilityHash as H(CanonicalArtefact || InteroperabilityRuleSetVersionId || InteroperabilityRegistryVersionId); (e) generating an ExchangeRecord binding sending and receiving system identifiers, InteroperabilityRuleSetVersionId, InteroperabilityRegistryVersionId, InteroperabilityHash, compatibility outcome, and a timestamp recorded as data, and appending it to an immutable store; and (f) upon detection that an artefact violates canonical schema, fails compatibility checks, or references an unsupported protocol version, rejecting the artefact and suppressing execution in a fail-closed manner.
-
The method of claim 1 wherein InteroperabilityRegistry entries are versioned and immutable once published.
-
The method of claim 1 wherein a deterministic rejection record identifying the violated constraint and InteroperabilityRuleSetVersionId is appended to the immutable store upon rejection.
-
The method of claim 1 wherein replay recomputes InteroperabilityHash using stored fields and does not depend on current system time.
-
The method of claim 1 wherein distributed receiving nodes operating with identical canonical artefacts and identical InteroperabilityRegistry versions produce identical compatibility outcomes and identical InteroperabilityHash values.
-
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 5.
-
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 5.
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 multi-system evidence interoperability mechanism is disclosed. Evidence artefacts are exchanged in a canonical structured representation comprising deterministic field ordering, explicit typing metadata, and version identifiers. Upon receipt, canonical structure is validated and interoperability rules are retrieved deterministically from a versioned immutable InteroperabilityRegistry without fallback translation. Compatibility is evaluated using explicit equivalence constraints and protocol alignment requirements. An InteroperabilityHash is computed as H(CanonicalArtefact || InteroperabilityRuleSetVersionId || InteroperabilityRegistryVersionId) and an ExchangeRecord is appended to an immutable store. Artefacts violating canonical schema, failing compatibility checks, or referencing unsupported protocol versions are rejected and execution is suppressed in a fail-closed manner. Replay uses stored fields and does not depend on current system time.