P275 — AIEP — Fail-Closed Evidence Admissibility Gate

Publication Date: 2026-04-12 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Limited Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1 Patent ID: P275 Classification: OS — Open Source Prior Art Implemented in: AIEP GENOME SDK admissibility gate module Related filings: GB2519711.2 (AIEP Core Protocol)

Field of the Invention

[0001] The disclosure relates to access-control gate architectures for evidence evaluation pipelines.

[0002] More particularly, the disclosure concerns a fail-closed admissibility gate enforcing three constitutional constraints in a fixed evaluation order, in which any value in the gate-status field other than the explicit string "OPEN" results in refusal, and in which refused evidence is recorded as an immutable commitment rather than discarded.

Framework Context

[0003] This disclosure operates within the AIEP framework.

[0004] The AIEP protocol processes evidence records — structured data items representing observations, conclusions, or inferences — through a pipeline that assesses their canonical hash identity (P270–P274), their plausibility (P90), and any registered dissent (P91) before they are admitted to the evidence substrate. The admissibility gate is the final mandatory checkpoint before admission.

[0005] This disclosure describes the gate architecture, its three constitutional constraints, the evaluation order, and the immutability rule governing refused entries.

Background

[0006] Access-control gates in software systems typically operate in one of two default modes: default-permit (the gate passes items unless a rule explicitly blocks them) or default-deny (the gate blocks items unless a rule explicitly permits them). This distinction determines the system’s failure behaviour.

[0007] A default-permit gate has the property that if the rule evaluation engine fails — for example, if a rule fails to load, if an exception is thrown mid-evaluation, or if a rule’s input data is missing — the gate will pass the item. For security-critical systems, default-permit means: any error in the enforcement mechanism results in unrestricted access. This is the failure mode of most application-layer firewalls that are misconfigured.

[0008] For an evidence admissibility control system, a default-permit failure is categorically unacceptable. An evidence item that reaches the substrate only because the plausibility check failed to execute, or because the dissent position was not yet recorded, must not be treated as admitted. Such an item has not been cleared — it has slipped through a gap in the gate.

[0009] Existing evidence management systems do not typically:

(a) specify a fail-closed semantics in which null, absent, or unexpected gate-status values are refused rather than permitting admission; (b) enforce constitutional constraints in a guaranteed fixed evaluation order with short-circuit semantics; (c) distinguish between a gate-status of "OPEN" and a gate-status of null, "PENDING", "CLOSED", or any other string — treating all non-"OPEN" values as equivalent refusals; (d) record refused evidence entries as immutable REFUSED commitments in the evidence substrate rather than discarding or silently passing them; or (e) define a test suite (ADM-001, ADM-002, ADM-003) covering the closed-gate, dissent veto, and all-pass cases.

[0010] There exists a need for an admissibility gate architecture that fails closed, that requires an explicit positive authorisation signal for admission, and that establishes an auditable record of every refusal.

Summary of the Disclosure

[0011] A fail-closed evidence admissibility gate is provided, enforcing three constitutional constraints in a fixed evaluation order.

[0012] The gate evaluates the following three constraints in order, short-circuiting on first failure:

CC-005 (gate status — evaluated first): If gate_status != "OPEN" then REFUSE with refusing constraint CC-005. The explicit string "OPEN" is the only admitted value. Any other value — including null, absent, "CLOSED", "PENDING", or any other string — results in refusal.

CC-001 (plausibility — evaluated second): If plausibility_status == "implausible" then REFUSE with refusing constraint CC-001.

CC-004 (dissent veto — evaluated third): If dissent_final_position == "reject" then REFUSE with refusing constraint CC-004.

[0013] If all three constraints are satisfied — gate_status == "OPEN", plausibility is not "implausible", and dissent position is not "reject" — the gate emits ADMITTED.

[0014] The evaluation order is fixed. CC-005 is always evaluated before CC-001. CC-001 is always evaluated before CC-004. The gate does not evaluate CC-001 or CC-004 if CC-005 fails. This short-circuit evaluation means that a closed gate is a complete block: no amount of passing plausibility or dissent will cause admission.

[0015] Refused evidence entries are recorded in the evidence substrate as REFUSED commitments. The REFUSED status is immutable: a refused entry cannot be changed to ADMITTED by any subsequent operation. A refused entry may be superseded by a new submission with different content, but the original refusal record is not deleted and is not editable.

[0016] The technical effect is modification of a computing system’s evidence processing behaviour such that the gate fails closed — defaulting to refusal rather than admission — and that every admission requires an explicit, positive, auditable authorisation through all three constitutional constraints.

Brief Description of the Drawings

[0017] Figure 1 illustrates the three-constraint gate evaluation cascade with short-circuit paths and outputs.

[0018] Figure 2 shows the fail-closed safety inversion argument contrasting this gate with a default-permit firewall.

[0019] Figure 3 shows the test vectors ADM-001, ADM-002, ADM-003 and the constraint each exercises.

ASCII Drawings

Figure 1 — Gate Evaluation Cascade

Evidence item submitted to gate
              |
              v
CC-005: gate_status == "OPEN"?
   NO  ─────────────────────────────► REFUSE (CC-005)
   YES
              |
              v
CC-001: plausibility_status == "implausible"?
   YES ──────────────────────────────► REFUSE (CC-001)
   NO
              |
              v
CC-004: dissent_final_position == "reject"?
   YES ──────────────────────────────► REFUSE (CC-004)
   NO
              |
              v
         ADMITTED

Figure 2 — Fail-Closed Safety Inversion

Default-PERMIT gate:              Default-DENY (this disclosure):

rule_engine.load() → ERROR        rule_engine.load() → ERROR
        |                                  |
        v                                  v
  gate = PERMIT                      gate = REFUSE
  [attack surface OPEN]               [substrate PROTECTED]

"Any rule failure = breach"        "Any rule failure = lockout"
[Firewall that allows all          [Gate that blocks
 when rules fail to load]           when rules fail to load]

Figure 3 — Conformance Test Vectors

Vector  | gate_status | plausibility  | dissent     | Expected   | Refused by
--------+-------------+---------------+-------------+------------+-----------
ADM-001 | "CLOSED"    | "plausible"   | "agree"     | REFUSED    | CC-005
ADM-002 | "OPEN"      | "plausible"   | "reject"    | REFUSED    | CC-004
ADM-003 | "OPEN"      | "plausible"   | "agree"     | ADMITTED   | (none)

Detailed Description of Embodiments

Constraint Definitions

[0020] The three constitutional constraints are defined as follows.

CC-005 — Gate Status: The gate-status field MUST be the exact string "OPEN". The check is performed by strict string equality. The following values ALL produce refusal:

• null or absent: the gate has not been explicitly opened
• "CLOSED": explicitly closed
• "PENDING": pending authorisation is not authorisation
• "open": case mismatch; protocol values are case-sensitive
• any other string: not the required authorisation signal

This property is the fail-closed core. An evidence item submitted before the gate has been explicitly opened is refused, even if it would pass all other checks.

CC-001 — Plausibility: The plausibility field MUST NOT be "implausible". This constraint is evaluated only if CC-005 passes. The plausibility assessment is performed by the plausibility engine (P90) before the gate is reached; the gate reads the pre-computed result. A plausibility status of "plausible", "uncertain", or any non-"implausible" value passes CC-001.

CC-004 — Dissent Veto: The dissent-final-position field MUST NOT be "reject". This constraint is evaluated only if CC-005 and CC-001 both pass. The dissent position is the output of the dissent arbitration process (P91). A position of "agree" or "abstain" passes CC-004. A position of "reject" is a veto, regardless of gate status or plausibility.

Short-Circuit Evaluation

[0021] The evaluation order is CC-005 ← CC-001 ← CC-004. This is not interchangeable. The rationale for CC-005 first is: the gate-status field is a precondition, not an evidence property. A gate that has not been opened cannot process evidence regardless of the evidence’s quality. Evaluating plausibility before checking the gate would allow a plausibility engine to be invoked against evidence in a closed session — an unnecessary information leak.

[0022] CC-001 is evaluated before CC-004 because plausibility is a simpler, cheaper check. Dissent arbitration (P91) is a more expensive operation. Short-circuiting on implausibility avoids invoking the dissent process for evidence that would be refused anyway.

Refusal Immutability

[0023] An evidence item that receives a REFUSED decision is recorded in the substrate with status REFUSED and the identifying refusing_constraint field. This record is immutable: once written as REFUSED, the entry MUST NOT be updated to ADMITTED or PENDING by any process.

[0024] The purpose of refusal immutability is auditable accountability. If an evidence item was refused, it must remain visible that it was submitted and refused. Deletion or status mutation would enable an operator to hide the evidence submission history.

[0025] A re-submission with corrected content is permitted: the requester may submit a new evidence item with a new record ID, addressing the reason for the original refusal. The new item passes through the gate independently. But the original refusal record is not modified.

Gate Status Management

[0026] The gate-status is managed by a gate-control process external to the admissibility gate. The admissibility gate is a read-only consumer of the gate-status field; it does not set or change the gate status. The gate-control process is responsible for:

(a) setting gate-status to "OPEN" when a review session is authorised to receive evidence; (b) setting gate-status to "CLOSED" when the review session ends or is suspended; (c) ensuring that the gate-status field is absent or "CLOSED" during system initialisation.

[0027] The admissibility gate requires that this field be explicitly set to "OPEN". Absent and null are treated identically to "CLOSED" — the gate has not been opened.

Python Reference Implementation

[0028] The admissibility gate is implemented as:

def admissibility_gate(
    gate_status: object,
    plausibility_status: object,
    dissent_final_position: object,
) -> dict:
    # CC-005: fail-closed gate check — MUST be checked FIRST
    if gate_status != "OPEN":
        return {"decision": "REFUSED", "refusing_constraint": "CC-005"}

    # CC-001: plausibility check
    if plausibility_status == "implausible":
        return {"decision": "REFUSED", "refusing_constraint": "CC-001"}

    # CC-004: dissent veto
    if dissent_final_position == "reject":
        return {"decision": "REFUSED", "refusing_constraint": "CC-004"}

    return {"decision": "ADMITTED"}

[0029] The gate function is pure: it has no side effects. The calling process is responsible for recording the decision to the evidence substrate according to the immutability rule in [0023]–[0025].

Claims Summary

[0030] The following novel aspects of the fail-closed admissibility gate are asserted as prior art:

1. An evidence admissibility gate in which the gate-status field must be the exact string "OPEN" and any other value — including null, absent, "CLOSED", and "PENDING" — results in refusal, establishing fail-closed default behaviour.

2. A fixed evaluation order of three constitutional constraints (gate status first, plausibility second, dissent veto third) with short-circuit semantics, such that a closed gate is a complete block against which no evidence property provides override.

3. A refusal immutability rule specifying that refused evidence entries are recorded as REFUSED commitments in the evidence substrate and cannot be subsequently updated to ADMITTED by any process.

4. A safety inversion argument establishing that default-permit gate behaviour is categorically equivalent to a firewall that permits all traffic when its rules fail to load, and is therefore unacceptable for evidence admissibility control.

5. A conformance test suite of three vectors (ADM-001, ADM-002, ADM-003) specifically targeting the closed-gate block, the dissent veto, and the all-pass case, as minimum coverage for the gate’s three constitutional constraints.

Related Specifications