P17 — AIEP — Deterministic Cross-Jurisdiction Evidence Normalisation
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 jurisdiction-aware admissible determination systems within computing environments.
[0002] More particularly, the disclosure concerns a deterministic mechanism for normalising evidence artefacts across multiple legal and regulatory jurisdictions within an Architected Instruction and Evidence Protocol (AIEP) system, such that jurisdiction-specific representations are transformed into canonical forms suitable for reproducible hash-binding, admissibility evaluation, and cross-node verification.
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] Evidence admissibility requirements vary across legal and regulatory jurisdictions. Differences include required metadata fields, formatting constraints, certification requirements, temporal validity rules, and authentication standards.
[0006] Evidence objects processed in distributed computing systems frequently originate from multiple jurisdictions, each applying different structural conventions and admissibility criteria.
[0007] Existing systems rely on human interpretation, mutable policy engines, and heuristic mapping logic to reconcile jurisdiction-specific evidence representations. Such approaches produce inconsistent admissibility outcomes that are not reproducible across distributed nodes.
[0008] Non-deterministic jurisdiction normalisation produces inconsistent cryptographic identifiers for semantically equivalent evidence, breaks audit trails, and prevents reproducible admissibility evaluation.
[0009] Existing systems do not provide:
(a) deterministic resolution of jurisdiction identifiers against a versioned immutable registry; (b) version-bound retrieval of jurisdiction-specific normalisation rule sets without fallback; (c) canonical transformation of evidence artefacts into jurisdiction-specific forms under declared rules only; (d) fail-closed suppression of admissibility when jurisdictional requirements are not satisfied; or (e) deterministic replay of normalisation outcomes independent of current system time or jurisdiction state.
[0010] There exists a need for a deterministic cross-jurisdiction evidence normalisation mechanism that resolves jurisdiction identifiers, applies version-bound rule sets, produces canonically bound outputs, and fail-closes when deterministic normalisation conditions cannot be satisfied.
Summary of the Disclosure
[0011] A computer-implemented deterministic cross-jurisdiction evidence normalisation method is executed by one or more processors.
[0012] An evidence artefact is received together with a declared JurisdictionIdentifier.
[0013] The JurisdictionIdentifier is resolved deterministically against a versioned JurisdictionRegistry. If the jurisdiction cannot be resolved, processing is denied without fallback.
[0014] Upon successful resolution, a version-bound JurisdictionRuleSet is retrieved from the JurisdictionRegistry corresponding to the resolved identifier.
[0015] The JurisdictionRuleSet defines:
(a) mandatory evidence fields and their formats; (b) required formatting and structural constraints; (c) certification and authentication requirements; (d) temporal validity rules; and (e) admissibility criteria.
[0016] The evidence artefact is transformed into a JurisdictionCanonicalForm by applying the JurisdictionRuleSet deterministically, comprising deterministic field ordering, explicit compliance mapping, and defined validation constraints.
[0017] A JurisdictionCanonicalHash is computed as:
JurisdictionCanonicalHash = H(JurisdictionCanonicalForm || JurisdictionRuleSetVersionId || SchemaVersionId)
[0018] A NormalisationRecord is generated binding JurisdictionIdentifier, JurisdictionRuleSetVersionId, SchemaVersionId, transformation step identifiers, JurisdictionCanonicalHash, and a timestamp recorded as data, and appended to an immutable store.
[0019] If any jurisdictional requirement is missing, structurally invalid, non-compliant, or incompatible with registry rules, the admissibility state is deterministically set to non-admissible and execution is suppressed in a fail-closed manner.
[0020] The technical effect is modification of computing system operation by enforcing deterministic jurisdiction-aware normalisation prior to admissibility evaluation, enabling reproducible cross-jurisdictional evidence processing across distributed nodes.
Brief Description of the Drawings
[0021] Figure 1 illustrates the deterministic cross-jurisdiction normalisation pipeline from evidence receipt through jurisdiction resolution, rule set retrieval, canonical transformation, and hash binding.
[0022] Figure 2 illustrates the fail-closed admissibility gate applied when jurisdictional requirements are not satisfied.
[0023] Figure 3 illustrates the NormalisationRecord binding architecture showing the cryptographic relationship between JurisdictionCanonicalForm, JurisdictionRuleSetVersionId, and SchemaVersionId.
[0024] Figure 4 illustrates deterministic replay equivalence across distributed nodes operating under identical JurisdictionRegistry and SchemaVersionId.
ASCII Drawings
Figure 1 — Deterministic Cross-Jurisdiction Normalisation Pipeline
+---------------------------+
| Evidence Artefact |
| + JurisdictionIdentifier |
+------------+--------------+
|
v
+------------+--------------+
| JurisdictionRegistry |
| (Versioned, Immutable) |
| Resolve Identifier |
+------------+--------------+
|
+------+------+
Resolved Not Resolved
| |
v v
+------------------+ +-----------+
| Retrieve | | DENY |
| JurisdictionRule | | Processing|
| Set (Version- | | No Fallback
| Bound) | +-----------+
+--------+---------+
|
v
+--------+---------+
| Deterministic |
| Transformation |
| - Field ordering |
| - Compliance map |
| - Validation |
+--------+---------+
|
v
+--------+---------+
| JurisdictionCanon|
| icalForm |
+--------+---------+
|
v
+--------+---------+
| JurisdictionCanon|
| icalHash |
| H(CanonicalForm |
| || RuleSetVer |
| || SchemaVer) |
+------------------+
Figure 2 — Fail-Closed Admissibility Gate
+---------------------------+
| Jurisdictional |
| Requirements Check |
| (a) Mandatory fields? |
| (b) Format constraints? |
| (c) Certification valid? |
| (d) Temporal validity? |
| (e) Registry compliant? |
+------------+--------------+
|
+------+------+
All Met Any Fail
| |
v v
+------------------+ +-----------+
| Set Admissible | | SUPPRESS |
| State | | Execution |
| Generate | | Fail- |
| NormalisationRecord | Closed |
+------------------+ | |
| Generate |
| Rejection |
| Record |
+-----------+
Figure 3 — NormalisationRecord Binding Architecture
JurisdictionCanonicalForm ----+
\
JurisdictionRuleSetVersionId ---+--> H(CanonicalForm ||
/ RuleSetVersionId ||
SchemaVersionId ----+ SchemaVersionId)
|
v
+------------------------------------+
| NormalisationRecord |
|------------------------------------|
| JurisdictionIdentifier |
| JurisdictionRuleSetVersionId |
| SchemaVersionId |
| Transformation Step IDs |
| JurisdictionCanonicalHash |
| Timestamp (stored data) |
+------------------------------------+
|
v
+------------------------------------+
| Append-Only Immutable Store |
+------------------------------------+
Figure 4 — Deterministic Replay Across Distributed Nodes
Node A Node B
+--------------------+ +--------------------+
| Evidence Artefact | | Evidence Artefact |
| (identical) | | (identical) |
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| JurisdictionRegistry | JurisdictionRegistry
| (identical version)| | (identical version)|
+---------+----------+ +---------+----------+
| |
v v
+---------+----------+ +---------+----------+
| JurisdictionCanon- | | JurisdictionCanon- |
| icalHash | | icalHash |
+---------+----------+ +---------+----------+
| |
+------------------+----------------+
|
v
+------------------------+
| Hash Equivalence |
| Verification |
| (stored timestamps |
| used — does not |
| depend on current |
| system time) |
+------------------------+
Detailed Description
1. Jurisdiction Identification and Registry Resolution
[0025] An evidence artefact is received together with a declared JurisdictionIdentifier.
[0026] The JurisdictionIdentifier is validated against a versioned JurisdictionRegistry.
[0027] If the jurisdiction cannot be resolved deterministically against the registry, processing is denied without fallback to alternative jurisdiction rules.
[0028] Registry entries are versioned and immutable once published, ensuring that resolution outcomes are reproducible across distributed nodes and audit cycles.
2. Versioned JurisdictionRuleSet Retrieval
[0029] Upon successful jurisdiction resolution, the corresponding JurisdictionRuleSet is retrieved deterministically using the JurisdictionIdentifier and registry version.
[0030] No fallback to alternative or approximate rule sets is permitted.
[0031] The JurisdictionRuleSet defines for the resolved jurisdiction:
(a) mandatory evidence fields and required formatting structures; (b) certification and authentication constraints; (c) temporal validity rules; and (d) admissibility criteria governing field presence, structure, and compliance.
3. Deterministic Canonical Transformation
[0032] The evidence artefact is transformed into a JurisdictionCanonicalForm by applying each rule in the JurisdictionRuleSet in deterministic order.
[0033] Transformation comprises deterministic field ordering, explicit compliance mapping, and defined validation constraint enforcement.
[0034] No heuristic inference, semantic interpretation, or discretionary override is permitted during transformation.
[0035] Identical evidence artefacts processed under identical JurisdictionRuleSet versions produce identical JurisdictionCanonicalForm outputs across distributed nodes.
4. Hash Binding and NormalisationRecord Generation
[0036] A JurisdictionCanonicalHash is computed as:
JurisdictionCanonicalHash = H(JurisdictionCanonicalForm || JurisdictionRuleSetVersionId || SchemaVersionId)
[0037] Inclusion of both JurisdictionRuleSetVersionId and SchemaVersionId ensures that changes to either rule set or schema produce distinct hash values.
[0038] A NormalisationRecord is generated comprising:
(a) JurisdictionIdentifier; (b) JurisdictionRuleSetVersionId; (c) SchemaVersionId; (d) transformation step identifiers in application order; (e) JurisdictionCanonicalHash; and (f) timestamp recorded as a data field.
[0039] The JurisdictionCanonicalForm and NormalisationRecord are appended to an append-only immutable store.
5. Fail-Closed Admissibility Enforcement
[0040] If any jurisdictional requirement is missing, structurally invalid, non-compliant, or incompatible with JurisdictionRegistry rules, the admissibility state is deterministically set to non-admissible.
[0041] Execution of any downstream operation dependent on the evidence artefact is suppressed in a fail-closed manner.
[0042] Suppression prevents allocation of processor cycles and memory to dependent operations.
[0043] A deterministic rejection record is appended identifying the violated jurisdictional constraint, the JurisdictionRuleSetVersionId, and the transformation step at which failure occurred.
6. Deterministic Replay
[0044] Replay is performed using stored JurisdictionRuleSetVersionId and SchemaVersionId together with stored evidence artefact data.
[0045] Replay recomputes JurisdictionCanonicalHash using stored fields including timestamps recorded as data and does not depend on current system time.
[0046] Identical evidence artefacts processed under identical JurisdictionRuleSet versions produce identical JurisdictionCanonicalForm and identical JurisdictionCanonicalHash values across distributed nodes.
7. Distributed Consistency
[0047] Distributed nodes possessing identical evidence artefacts and identical JurisdictionRegistry versions produce identical admissibility determinations.
[0048] Deterministic cross-jurisdiction normalisation therefore yields reproducible and auditable outcomes across distributed deployments without discretionary interpretation.
Claims
-
A computer-implemented method for deterministic cross-jurisdiction evidence normalisation, the method comprising: (a) receiving an evidence artefact with a declared JurisdictionIdentifier and resolving the identifier deterministically against a versioned immutable JurisdictionRegistry, denying processing without fallback if resolution fails; (b) retrieving a version-bound JurisdictionRuleSet corresponding to the resolved identifier, the JurisdictionRuleSet defining mandatory fields, formatting constraints, certification requirements, temporal validity rules, and admissibility criteria; (c) transforming the evidence artefact into a JurisdictionCanonicalForm by applying the JurisdictionRuleSet deterministically, comprising deterministic field ordering, explicit compliance mapping, and constraint validation, without heuristic inference or discretionary override; (d) computing a JurisdictionCanonicalHash as H(JurisdictionCanonicalForm || JurisdictionRuleSetVersionId || SchemaVersionId); (e) generating a NormalisationRecord binding the JurisdictionIdentifier, JurisdictionRuleSetVersionId, SchemaVersionId, transformation step identifiers, JurisdictionCanonicalHash, and a timestamp recorded as data, and appending it to an immutable store; and (f) upon detection that any jurisdictional requirement is missing, structurally invalid, non-compliant, or incompatible with registry rules, setting admissibility state to non-admissible and suppressing execution in a fail-closed manner.
-
The method of claim 1 wherein JurisdictionRegistry entries are versioned and immutable once published.
-
The method of claim 1 wherein a deterministic rejection record identifying the violated constraint and JurisdictionRuleSetVersionId is appended to the immutable store upon admissibility failure.
-
The method of claim 1 wherein replay recomputes JurisdictionCanonicalHash using stored fields and does not depend on current system time.
-
The method of claim 1 wherein identical evidence artefacts processed under identical JurisdictionRuleSet versions on distributed nodes produce identical JurisdictionCanonicalForm and identical JurisdictionCanonicalHash 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 cross-jurisdiction evidence normalisation mechanism is disclosed. Evidence artefacts with declared JurisdictionIdentifiers are resolved against a versioned immutable JurisdictionRegistry without fallback. A version-bound JurisdictionRuleSet is retrieved and applied to produce a JurisdictionCanonicalForm by deterministic transformation without heuristic inference. A JurisdictionCanonicalHash is computed as H(JurisdictionCanonicalForm || JurisdictionRuleSetVersionId || SchemaVersionId) and a NormalisationRecord is appended to an immutable store. If any jurisdictional requirement is missing, invalid, or non-compliant, 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 mechanism enforces reproducible jurisdiction-aware admissibility across distributed nodes without discretionary interpretation.