P43 — AIEP — Dual-Mode Deterministic Execution Profile System
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 execution control in distributed computing systems.
[0002] More particularly, the disclosure concerns a dual-mode deterministic execution profile system configured to regulate execution behaviour within an Architected Instruction and Evidence Protocol (AIEP) system, enabling controlled exploratory behaviour under entropy-governed constraints while preserving invariant-bound governance and replay-certifiable execution across distributed nodes.
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] Deterministic computing frameworks are commonly configured to enforce invariant-bound state transitions to ensure reproducibility. In development environments, it is often desirable to permit controlled divergence, exploratory branch expansion, or variation injection for testing, evaluation, or capability development.
[0006] Conventional systems that permit exploratory execution frequently relax deterministic constraints in a manner that compromises replayability, certification capability, or cross-node reproducibility. Where execution profiles exist, such profiles are typically implemented as runtime configuration flags without deterministic gating tied to invariant validation.
[0007] Uncontrolled divergence between development and regulatory execution environments may introduce state drift, unverifiable outputs, or non-reproducible behaviour across distributed nodes.
[0008] Existing systems do not provide:
(a) schema-bound execution profiles distinguishing invariant-enforced regulatory behaviour from entropy-governed exploratory behaviour; (b) incorporation of the active ExecutionProfile identifier into deterministic state identity computation; (c) schema-defined EntropyAllowance parameters governing permissible exploratory divergence bounds; (d) deterministic ProfileTransitionRecord generation on profile change; or (e) fail-closed suppression of execution on profile constraint violation while preserving replay certification capability.
[0009] There exists a need for a deterministic dual-mode execution system that allows controlled exploratory behaviour within schema-defined entropy bounds while preserving invariant-bound governance, replay-certifiable state transitions, and cross-node reproducibility under identical profile and schema conditions.
Summary of the Disclosure
[0011] A computer-implemented dual-mode deterministic execution profile method is executed by one or more processors within a distributed arbitration substrate.
[0012] At least two schema-bound ExecutionProfiles are defined: a STRICT profile and a CONTROLLED profile.
[0013] The STRICT profile enforces full invariant compliance without allowance for outlier generation or exploratory divergence. No entropy-based mutation is permitted. ExecutionEnablementSignal is generated only if all deterministic invariants are satisfied.
[0014] The CONTROLLED profile permits bounded exploratory behaviour under schema-defined EntropyAllowance parameters, which may comprise limits on exploratory branch count, structural mutation scope, threshold deviation limits, and permitted outlier classes. All exploratory branches remain subject to invariant validation prior to execution enablement.
[0015] The active ExecutionProfile is bound to a canonical schema version and incorporated into deterministic state identity computation, such that nodes operating under identical inputs and identical ExecutionProfile produce identical state transitions.
[0016] A ProfileIdentityHash is computed as:
ProfileIdentityHash = H(StateArtefactHash || ExecutionProfileId || SchemaVersionId)
[0017] A ProfileTransitionRecord is generated on any change between execution profiles, comprising previous profile identifier, new profile identifier, schema version, and a timestamp recorded as data, and appended to an immutable store. Profile transitions require schema-authorised permission.
[0018] ExecutionEnablementSignal generation requires compliance with active ExecutionProfile constraints. Where exploratory behaviour exceeds EntropyAllowance or invariant violations occur, execution is suppressed in a fail-closed manner.
[0019] The technical effect is controlled entropy introduction within a deterministic computing framework without compromising replay-certifiable execution behaviour or cross-node reproducibility.
Brief Description of the Drawings
[0020] Figure 1 illustrates STRICT profile execution showing invariant-bound gating and suppression of all exploratory divergence.
[0021] Figure 2 illustrates CONTROLLED profile execution showing bounded exploratory branch generation within schema-defined EntropyAllowance constraints.
[0022] Figure 3 illustrates deterministic recording of profile transitions and the ProfileTransitionRecord structure.
[0023] Figure 4 illustrates fail-closed suppression of execution under profile constraint violation and the ProfileIdentityHash binding architecture.
ASCII Drawings
Figure 1 — STRICT Profile Execution
+---------------------------+
| Arbitration Substrate |
| ExecutionProfile:STRICT |
+------------+--------------+
|
v
+------------+--------------+
| Invariant Validation |
| Full enforcement |
| No exploratory ops |
| No entropy mutation |
+------------+--------------+
|
+------+------+
All pass Any fail
| |
v v
+------------------+ +-----------+
| Generate | | SUPPRESS |
| Execution | | Execution |
| Enablement | | Fail- |
| Signal | | Closed |
+------------------+ +-----------+
Figure 2 — CONTROLLED Profile Execution
+---------------------------+
| Arbitration Substrate |
| ExecutionProfile: |
| CONTROLLED |
+------------+--------------+
|
v
+------------+--------------+
| EntropyAllowance Check |
| - Branch count limit |
| - Mutation scope limit |
| - Deviation threshold |
| - Outlier class scope |
+------------+--------------+
|
+------+------+
Within Exceeds
Allowance Allowance
| |
v v
+------------------+ +-----------+
| Exploratory Op | | SUPPRESS |
| Permitted | | Execution |
| Record as | | Fail- |
| Append-Only | | Closed |
| Artefact | +-----------+
| |
| Invariant |
| Validation Still |
| Required |
+------------------+
Figure 3 — ProfileTransitionRecord Structure
Previous Profile ID ----+
New Profile ID ----+
\
Schema Version ID -----+--> ProfileTransitionRecord
/
Timestamp (data) ----+
Schema-Authorised |
Permission Token |
v
+------------------------------+
| ProfileTransitionRecord |
|------------------------------|
| PreviousProfileId |
| NewProfileId |
| SchemaVersionId |
| AuthorisationToken |
| Timestamp (stored data) |
+------------------------------+
|
v
+------------------------------+
| Append-Only Immutable Store |
+------------------------------+
Figure 4 — ProfileIdentityHash Binding and Fail-Closed Enforcement
StateArtefactHash ----+
ExecutionProfileId ----+--> H(StateArtefactHash ||
SchemaVersionId ----+ ExecutionProfileId ||
SchemaVersionId)
|
v
+------------------------+
| ProfileIdentityHash |
+------------------------+
|
+------------+-----------+
| Profile constraint |
| satisfied? |
+------------+-----------+
|
+--------+--------+
Yes No
| |
v v
+-----------+ +-----------+
| Generate | | SUPPRESS |
| Execution | | Execution |
| Enablement| | Fail- |
| Signal | | Closed |
+-----------+ +-----------+
| (stored timestamps
| used — does not
| depend on current
| system time)
+-----------+
Detailed Description
1. Execution Profile Definitions
[0024] Two schema-bound ExecutionProfiles are defined within the canonical schema:
(a) STRICT profile: enforces invariant-bound deterministic execution prohibiting exploratory divergence, outlier generation, and entropy-based mutation; and
(b) CONTROLLED profile: permits bounded exploratory behaviour under schema-defined EntropyAllowance parameters comprising limits on exploratory branch count, structural mutation scope, threshold deviation limits, and permitted outlier classes.
[0025] ExecutionProfile definitions are schema-version-bound and immutable once published within the schema version.
2. Profile Binding and State Identity
[0026] The active ExecutionProfile is bound to a canonical schema version upon substrate initialisation.
[0027] The ExecutionProfile identifier is incorporated into deterministic state identity computation.
[0028] A ProfileIdentityHash is computed as:
ProfileIdentityHash = H(StateArtefactHash || ExecutionProfileId || SchemaVersionId)
[0029] Nodes operating under identical inputs and identical ExecutionProfile produce identical state transitions and identical ProfileIdentityHash values.
3. STRICT Profile Behaviour
[0030] In STRICT profile, invariant enforcement prohibits all exploratory divergence.
[0031] No outlier generation is permitted. No entropy-based mutation is permitted.
[0032] ExecutionEnablementSignal is generated only if all deterministic invariants are satisfied under the STRICT profile rules.
4. CONTROLLED Profile Behaviour
[0033] In CONTROLLED profile, exploratory operations are permitted subject to schema-defined EntropyAllowance parameters.
[0034] Exploratory results are recorded as append-only immutable artefacts.
[0035] All exploratory branches remain subject to invariant validation prior to execution enablement. No profile permits bypass of invariant validation.
[0036] Where exploratory behaviour exceeds EntropyAllowance, execution is suppressed in a fail-closed manner.
5. Profile Transition
[0037] Transition between STRICT and CONTROLLED profiles is performed through a deterministic ProfileTransitionRecord appended to the genealogical structure.
[0038] Profile transitions require schema-authorised permission. Unauthorised profile transitions cause fail-closed suppression of execution.
[0039] The ProfileTransitionRecord comprises previous profile identifier, new profile identifier, schema version, authorisation token, and a timestamp recorded as data.
6. Fail-Closed Enforcement
[0040] ExecutionEnablementSignal generation requires compliance with active ExecutionProfile constraints.
[0041] Where invariant violations occur, execution is suppressed regardless of active profile.
[0042] Replay recomputes ProfileIdentityHash using stored ExecutionProfileId and SchemaVersionId and does not depend on current system time.
Claims
-
A computer-implemented method for regulating deterministic execution within a distributed arbitration system, the method comprising: (a) defining at least two schema-bound ExecutionProfiles comprising a STRICT profile enforcing full invariant compliance without exploratory divergence, and a CONTROLLED profile permitting bounded exploratory operations within schema-defined EntropyAllowance constraints; (b) binding the active ExecutionProfile to a canonical schema version and incorporating the ExecutionProfile identifier into deterministic state identity computation; (c) computing a ProfileIdentityHash as H(StateArtefactHash || ExecutionProfileId || SchemaVersionId); (d) enforcing invariant validation according to the rules of the active ExecutionProfile, recording exploratory results as append-only immutable artefacts under CONTROLLED profile; (e) generating a ProfileTransitionRecord comprising previous profile identifier, new profile identifier, schema version, and a timestamp recorded as data upon profile change, and requiring schema-authorised permission for any such transition; and (f) generating an ExecutionEnablementSignal only when deterministic invariants and active profile constraints are satisfied, otherwise suppressing execution in a fail-closed manner.
-
The method of claim 1 wherein EntropyAllowance comprises limits on exploratory branch count, structural mutation scope, threshold deviation limits, and permitted outlier classes.
-
The method of claim 1 wherein no ExecutionProfile permits bypass of invariant validation.
-
The method of claim 1 wherein replay recomputes ProfileIdentityHash using stored fields and does not depend on current system time.
-
The method of claim 1 wherein nodes operating under identical inputs and identical ExecutionProfile produce identical state transitions and identical ProfileIdentityHash values.
-
A distributed computing system configured 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 dual-mode deterministic execution profile system is disclosed for distributed arbitration systems operating within an Architected Instruction and Evidence Protocol (AIEP) environment. A STRICT profile enforces full invariant-bound deterministic execution without exploratory divergence. A CONTROLLED profile permits bounded exploratory operations under schema-defined EntropyAllowance parameters. The active ExecutionProfile identifier is incorporated into state identity computation and a ProfileIdentityHash is computed as H(StateArtefactHash || ExecutionProfileId || SchemaVersionId). Profile transitions generate a deterministic ProfileTransitionRecord and require schema-authorised permission. ExecutionEnablementSignal generation is suppressed in a fail-closed manner upon invariant violation or profile constraint breach. Replay uses stored fields and does not depend on current system time. Nodes operating under identical inputs and identical ExecutionProfile produce identical state transitions and hash values.