P24 — AIEP — Domain-Specific Evidence Extension Framework
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 extensible admissible determination systems within computing environments.
[0002] More particularly, the disclosure concerns a deterministic domain-specific evidence extension framework for use within an Architected Instruction and Evidence Protocol (AIEP) system, enabling domain-specific admissibility rules to be defined, versioned, and invoked deterministically without modification of the core protocol.
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] Admissible determination systems frequently ingest evidence from diverse technical domains including financial systems, regulatory environments, scientific datasets, industrial telemetry, and legal documentation.
[0006] Existing approaches either embed domain logic directly within the core engine, rely on semantic interpretation layers, or permit mutable policy updates. Such approaches complicate core protocol integrity, introduce non-deterministic behaviour, allow discretionary interpretation, and reduce reproducibility.
[0007] Embedding domain-specific rules within a core protocol requires modification of that protocol whenever domain requirements change, creating version fragmentation and audit complexity.
[0008] Existing systems do not provide:
(a) external definition of domain-specific rules, constraints, and admissibility criteria versioned independently of the core protocol; (b) deterministic invocation of domain extensions using explicit identifiers and version references without fallback; (c) cryptographic binding of extension invocation to the version under which it was executed; (d) fail-closed non-admissibility when extension constraints are not satisfied; or (e) preservation of core protocol structural invariance regardless of the number of domain extensions deployed.
[0009] There exists a need for a deterministic extension mechanism that enables domain-specific admissibility without modification of the core protocol, preserving reproducibility and structural integrity across distributed deployments.
Summary of the Disclosure
[0011] A computer-implemented deterministic domain-specific evidence extension framework is executed by one or more processors.
[0012] Domain extensions are defined as structured rule sets stored in a versioned ExtensionRegistry, each comprising admissibility criteria, field mappings, constraint definitions, validation requirements, and compatibility declarations.
[0013] Each domain extension is assigned a DomainExtensionVersionId and is immutable once published. New versions are introduced as separate registry entries.
[0014] The core AIEP protocol invokes a domain extension using an explicit DomainIdentifier and DomainExtensionVersionId retrieved deterministically from the ExtensionRegistry. No alternative or fallback extension is permitted.
[0015] A DomainExtensionInvocationHash is computed as:
DomainExtensionInvocationHash = H(EvidenceArtefactHash || DomainExtensionVersionId || ExtensionRegistryVersionId)
[0016] An ExtensionInvocationRecord is generated binding DomainIdentifier, DomainExtensionVersionId, ExtensionRegistryVersionId, DomainExtensionInvocationHash, admissibility outcome, and a timestamp recorded as data, and appended to an immutable store.
[0017] If a required domain extension is unavailable, registry validation fails, or constraints are not satisfied, the admissibility state is deterministically set to non-admissible and execution is suppressed in a fail-closed manner.
[0018] The core protocol remains structurally invariant regardless of the number or nature of domain extensions deployed.
[0019] The technical effect is modification of computing system behaviour by enabling deterministic extensibility of admissibility evaluation without modifying the core protocol, thereby preserving reproducibility across distributed nodes.
Brief Description of the Drawings
[0020] Figure 1 illustrates the domain extension definition and registry storage architecture showing versioned immutable extension entries and their retrieval by the core protocol.
[0021] Figure 2 illustrates the deterministic extension invocation pipeline from core protocol invocation through registry lookup, extension application, and admissibility determination.
[0022] Figure 3 illustrates the ExtensionInvocationRecord hash binding architecture showing the cryptographic relationship between the evidence artefact, extension version, and registry version.
[0023] Figure 4 illustrates deterministic replay equivalence across distributed nodes invoking identical domain extensions under identical version identifiers.
ASCII Drawings
Figure 1 — Domain Extension Registry Architecture
Domain Extension Definitions
(External to Core Protocol)
+-----------------------------+
| DomainExtension: Finance |
| DomainExtensionVersionId: v2|
| - Admissibility criteria |
| - Field mappings |
| - Constraint definitions |
| - Validation requirements |
| - Compatibility declarations|
| Status: IMMUTABLE |
+-----------------------------+
+-----------------------------+
| DomainExtension: Regulatory |
| DomainExtensionVersionId: v1|
| - Admissibility criteria |
| - Field mappings |
| - Constraint definitions |
| Status: IMMUTABLE |
+-----------------------------+
+-----------------------------+
| DomainExtension: Scientific |
| DomainExtensionVersionId: v3|
| ... |
| Status: IMMUTABLE |
+-----------------------------+
|
v
+-----------------------------+
| ExtensionRegistry |
| (Versioned, Immutable) |
+-----------------------------+
Figure 2 — Deterministic Extension Invocation Pipeline
+---------------------------+
| Core AIEP Protocol |
| (Structurally Invariant)|
+------------+--------------+
|
| DomainIdentifier +
| DomainExtensionVersionId
v
+------------+--------------+
| ExtensionRegistry |
| Lookup |
+------------+--------------+
|
+------+------+
Found Not Found
| |
v v
+------------------+ +-----------+
| Apply Extension | | SUPPRESS |
| Rules | | Execution |
| Deterministically| | Fail- |
| | | Closed |
| Evaluate | | Non- |
| Constraints | | Admissible|
+--------+---------+ +-----------+
|
+------+------+
Satisfied Not Satisfied
| |
v v
+----------+ +-----------+
| ADMISSIBLE| | NON- |
| Generate | | ADMISSIBLE|
| Invocation| | Fail- |
| Record | | Closed |
+----------+ +-----------+
Figure 3 — ExtensionInvocationRecord Hash Binding
EvidenceArtefactHash ----+
\
DomainExtensionVersionId -----+--> H(ArtefactHash ||
/ ExtVersionId ||
ExtensionRegistryVersionId ----+ RegistryVersionId)
|
v
+------------------------------------+
| ExtensionInvocationRecord |
|------------------------------------|
| DomainIdentifier |
| DomainExtensionVersionId |
| ExtensionRegistryVersionId |
| DomainExtensionInvocationHash |
| Admissibility outcome |
| Timestamp (stored data) |
+------------------------------------+
|
v
+------------------------------------+
| Append-Only Immutable Store |
+------------------------------------+
Figure 4 — Deterministic Replay Across Distributed Nodes
Node A Node B
+--------------------+ +--------------------+
| EvidenceArtefact | | EvidenceArtefact |
| (identical) | | (identical) |
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| DomainExtension | | DomainExtension |
| (identical version)| | (identical version)|
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| Invocation Hash | | Invocation Hash |
+---------+----------+ +---------+----------+
| |
+------------------+----------------+
|
v
+------------------------+
| Hash Equivalence |
| Verification |
| (stored timestamps |
| used — does not |
| depend on current |
| system time) |
+------------------------+
Detailed Description
1. External Domain Extension Definition
[0024] Domain extensions are defined as structured rule sets external to the core AIEP protocol, comprising:
(a) admissibility criteria specifying conditions required for evidence to be admissible within the domain; (b) field mappings defining correspondence between domain-specific fields and canonical AIEP fields; (c) constraint definitions specifying validation rules applicable to domain evidence; (d) validation requirements defining mandatory checks prior to admissibility determination; and (e) compatibility declarations specifying which core protocol versions and schema versions the extension supports.
[0025] Extensions are stored in a versioned ExtensionRegistry external to the core protocol.
2. Versioned and Immutable Registry
[0026] Each domain extension is assigned a DomainExtensionVersionId upon publication.
[0027] Extensions are immutable once published. No modification of a published extension is permitted.
[0028] New domain requirements are addressed by publishing a new extension version as a separate registry entry, not by modifying existing entries.
[0029] The ExtensionRegistry itself is versioned, ensuring that the set of available extensions is reproducible across distributed nodes.
3. Deterministic Extension Invocation
[0030] The core AIEP protocol invokes a domain extension using an explicit DomainIdentifier and DomainExtensionVersionId.
[0031] The ExtensionRegistry is queried deterministically using the DomainIdentifier and DomainExtensionVersionId. No alternative, fallback, or approximate extension is permitted.
[0032] If the requested extension is not available in the registry, processing is denied in a fail-closed manner.
[0033] Multiple domain extensions may be invoked sequentially under deterministic ordering rules declared in the ExtensionRegistry.
4. Extension Application and Admissibility Determination
[0034] Upon successful registry retrieval, the domain extension rules are applied to the evidence artefact deterministically.
[0035] No semantic interpretation layer, heuristic logic, or discretionary override is applied during extension execution.
[0036] If all extension constraints are satisfied, the admissibility state is set to admissible for the domain.
[0037] If any extension constraint is not satisfied, the admissibility state is deterministically set to non-admissible and execution is suppressed in a fail-closed manner.
5. Hash Binding and ExtensionInvocationRecord Generation
[0038] A DomainExtensionInvocationHash is computed as:
DomainExtensionInvocationHash = H(EvidenceArtefactHash || DomainExtensionVersionId || ExtensionRegistryVersionId)
[0039] An ExtensionInvocationRecord is generated comprising:
(a) DomainIdentifier; (b) DomainExtensionVersionId; (c) ExtensionRegistryVersionId; (d) DomainExtensionInvocationHash; (e) admissibility outcome; and (f) timestamp recorded as a data field.
[0040] The ExtensionInvocationRecord is appended to an append-only immutable store.
6. Core Protocol Structural Invariance
[0041] The domain extension framework does not modify core protocol logic, does not introduce semantic reasoning into the core protocol, and does not permit discretionary override of core protocol behaviour.
[0042] The core protocol remains structurally invariant regardless of the number of domain extensions deployed or the nature of domain-specific rules defined within them.
7. Deterministic Replay
[0043] Replay is performed using stored DomainExtensionVersionId and ExtensionRegistryVersionId together with stored evidence artefact data.
[0044] Replay recomputes DomainExtensionInvocationHash using stored fields and does not depend on current system time.
[0045] Distributed nodes invoking identical domain extensions under identical version identifiers produce identical admissibility outcomes and identical DomainExtensionInvocationHash values.
Claims
-
A computer-implemented method for deterministic domain-specific evidence extension within an admissible determination system, the method comprising: (a) defining domain extensions as versioned immutable structured rule sets stored in an ExtensionRegistry, each extension comprising admissibility criteria, field mappings, constraint definitions, validation requirements, and compatibility declarations; (b) invoking a domain extension using an explicit DomainIdentifier and DomainExtensionVersionId retrieved deterministically from the ExtensionRegistry, without fallback or alternative extension; (c) applying the retrieved extension rules to an evidence artefact deterministically without semantic interpretation, heuristic logic, or discretionary override; (d) computing a DomainExtensionInvocationHash as H(EvidenceArtefactHash || DomainExtensionVersionId || ExtensionRegistryVersionId); (e) generating an ExtensionInvocationRecord binding DomainIdentifier, DomainExtensionVersionId, ExtensionRegistryVersionId, DomainExtensionInvocationHash, admissibility outcome, and a timestamp recorded as data, and appending it to an immutable store; and (f) upon detection that a required extension is unavailable, registry validation fails, or any constraint is not satisfied, setting admissibility state to non-admissible and suppressing execution in a fail-closed manner.
-
The method of claim 1 wherein domain extensions are immutable once published and new versions are introduced as separate registry entries.
-
The method of claim 1 wherein multiple domain extensions are invoked sequentially under deterministic ordering rules declared in the ExtensionRegistry.
-
The method of claim 1 wherein the core admissible determination protocol remains structurally invariant regardless of the number of domain extensions deployed.
-
The method of claim 1 wherein replay recomputes DomainExtensionInvocationHash using stored fields and does not depend on current system time.
-
The method of claim 1 wherein distributed nodes invoking identical domain extensions under identical version identifiers produce identical admissibility outcomes and identical DomainExtensionInvocationHash 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 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 domain-specific evidence extension framework is disclosed. Domain extensions comprising admissibility criteria, field mappings, constraint definitions, and validation requirements are defined as versioned immutable structured rule sets stored in an ExtensionRegistry. The core AIEP protocol invokes extensions using explicit DomainIdentifier and DomainExtensionVersionId without fallback. A DomainExtensionInvocationHash is computed as H(EvidenceArtefactHash || DomainExtensionVersionId || ExtensionRegistryVersionId) and an ExtensionInvocationRecord is appended to an immutable store. If a required extension is unavailable or constraints are not satisfied, admissibility is set to non-admissible and execution is suppressed in a fail-closed manner. Replay uses stored fields and does not depend on current system time. The core protocol remains structurally invariant regardless of extensions deployed, enabling deterministic extensibility without modifying core protocol logic.