Protocol Architecture

Section 1

How to read this map

Badge definitions. Each diagram carries a classification badge. Verified means source-grounded and confirmed in implementation. Partial means partially implemented or partially confirmed — do not read as a complete implementation claim. Beta means early or incomplete. Source Gap means could not be confirmed from source. Future means planned but not implemented. Adapter means an extension surface, not V1 kernel. Extension means a vertical feature consuming the protocol.
Reading order. Start with D1 (Core Protocol Truth Chain) for the end-to-end request flow. Then D2 (Evaluation & Convergence) for how CE decides exercisability. Explore other diagrams by interest.
Caveat visibility. Diagrams labelled Partial or Beta reflect partial implementation or incomplete confirmation. They describe architectural intent, not finished modules.
D8 excluded. The Carrier Boundary Map (D8) is not published in this version. No carrier resolution code currently exists in the source. Publishing it would imply unimplemented features.

Section 2

Core architectural invariant

The protocol has one non-negotiable invariant that every other component serves:

"The Constraint Convergence Engine is the sole source of final evaluation truth. No other component creates a second evaluation path."

Verified in source: evaluation-guardian.js line 15 — "The Guardian does NOT make enforcement decisions — it delegates entirely to the constraint convergence engine."

Guardian enforces the CE output — it does not re-evaluate. Stages 5, 9, and 10 of the mutation pipeline are context-preservation stages — they do not independently block entitlement mutations. Stage 11 is a pre-flight verification gate, not a second truth path. Stored evaluation results are evidence, not enforcement inputs.

Section 3 · D1

Core Protocol Truth Chain

The end-to-end flow for every entitlement mutation. An incoming request passes through identity resolution, authorisation gating, 12 pipeline stages, and the Constraint Convergence Engine before any mutation is committed. Stage 12 — invoking CE through the Evaluation Guardian — is the canonical final gate.

D1 — Core Protocol Truth Chain V1 Core Verified

flowchart TD CALLER["Caller / Agent / External System"] subgraph AUTH["Stage 1–4: Identity & Authority"] ACTOR["Actor Ingress\nlib/actor-ingress.js"] GATE["Auth Gate\nlib/gate-mutation.js"] AUTH_ENGINE["Authorisation Engine\nlib/authorisation-engine.js"] end subgraph PIPELINE["Stages 5–12: Protocol Mutation Pipeline\nlib/protocol-mutation-pipeline.js"] S5["Stage 5: Enforcement State Load\nCONTEXT PRESERVATION — not blocking"] S9["Stage 9: Contestation Overlay\nCONTEXT PRESERVATION — not blocking"] S10["Stage 10: Policy Guardian\nCONTEXT PRESERVATION — not blocking"] S11["Stage 11: VER Pre-flight Gate\nBlocks if VER prerequisites unsatisfied"] S12["Stage 12: Constraint Convergence Gate\nFINAL TRUTH GATE\nlib/evaluation-guardian.js → CE"] end subgraph CE["Constraint Convergence Engine\nlib/constraint-convergence/"] CE_ENGINE["evaluateEntitlementUsability()\nevaluation-engine.js\n7 canonical + D8 ACCEPTANCE"] CE_CONVERGE["converge()\nce-01-h.js\n7 canonical DimensionResults → outcome"] CE_OUT["ConvergenceResult\nexercisable: bool\nPASS | BLOCKED | DENIED | INVALID_CONFIGURATION"] end subgraph MUTATION["Mutation & Events"] TX["Database Transaction\nSerializable isolation\nlifecycle_state_canonical updated"] EVENTS["Event Emission\nlib/events.js"] RESPONSE["HTTP Response\n200 / 403 EvaluationDeniedResponse\n/ 403 AuthorisationErrorResponse"] end CALLER --> ACTOR ACTOR --> GATE GATE --> AUTH_ENGINE AUTH_ENGINE -->|"DENIED → 403"| RESPONSE AUTH_ENGINE -->|"APPROVED"| S5 S5 --> S9 S9 --> S10 S10 --> S11 S11 -->|"VER blocked → 403"| RESPONSE S11 -->|"VER passed"| S12 S12 --> CE_ENGINE CE_ENGINE --> CE_CONVERGE CE_CONVERGE --> CE_OUT CE_OUT -->|"exercisable=false → 403 EvaluationDeniedResponse"| RESPONSE CE_OUT -->|"exercisable=true"| TX TX --> EVENTS EVENTS --> RESPONSE style S12 fill:#2d4a2d,color:#fff style CE_CONVERGE fill:#2d4a2d,color:#fff style CE_OUT fill:#1a3a1a,color:#fff

Source: lib/protocol-mutation-pipeline.js, lib/evaluation-guardian.js, lib/gate-mutation.js · Stages 5/9/10 demoted per MAP-01-FIX (context-preservation only; final gate is Stage 12)

Section 4 · D2

Evaluation & Convergence

The Constraint Convergence Engine evaluates 7 canonical dimensions (LC, TMP, ENF, DEP, CAP, VER, DEC) through ce-01-h.js. ACCEPTANCE is formally classified as D8 and is evaluated at the evaluation-engine.js level alongside the canonical dimensions via resolveOutcome(). The external API always-7 dimension summary reflects the seven canonical CE dimensions and is unchanged.

Outcome precedence is immutable: INVALID_CONFIGURATION > DENIED > BLOCKED > PASS. Four protocol invariants prevent nonsensical dimension/outcome combinations.

D2 — Evaluation & Convergence Map V1 Core Verified

flowchart TD INPUT["Entitlement State\n+ actor_id, operation_class\n+ verification_context, evaluation_time"] subgraph DIMS["7 Canonical Dimensions — lib/constraint-convergence/dimensions/"] LC["LC — Lifecycle\nPENDING/ISSUED→intermediate\nCONSUMED/REVOKED→DENIED\nCannot be BLOCKED"] TMP["TMP — Temporal\nCURRENT→PASS\nNOT_YET/EXPIRED/INVALID→DENIED\nCannot be BLOCKED"] ENF["ENF — Enforcement\nREVOCATION>SUSPENSION>HOLD>RESTRICTION\nActive→BLOCKED\nCannot be DENIED"] DEP["DEP — Dependency\nSATISFIED→PASS\nPENDING→PENDING\nFAILED→DENIED\nCannot be DENIED from policy"] CAP["CAP — Capacity\nAVAILABLE→PASS\nEXHAUSTED/INVALID→BLOCKED"] VER["VER — Verification\nVERIFIED→PASS\nUNVERIFIED/FAILED→DENIED"] DEC["DEC — Decision\nAPPROVED→PASS\nREJECTED→DENIED\nPENDING→BLOCKED"] end D8["(+) ACCEPTANCE — D8\nacceptance-dimension.js\nevaluation-engine.js resolveOutcome()\nMissing/Rejected→DENIED\nPending→BLOCKED\nAccepted→PASS\nNOTE: D8 is NOT in ce-01-h.js converge()"] subgraph CE["Convergence Engine — ce-01-h.js"] VALIDATE["CE-INPUT-01 Preflight Validation\nAll 7 dimensions present\n9-field contract enforced"] INVARIANTS["Protocol Invariant Guards\nENF≠DENIED · LC≠BLOCKED\nTMP≠BLOCKED · DEP≠DENIED"] PRECEDENCE["Outcome Precedence (locked)\n1. INVALID_CONFIGURATION\n2. DENIED\n3. BLOCKED\n4. PASS"] RESULT["ConvergenceResult\nexercisable: bool\noutcome, blocking_reasons[]\ndimension_results[7]"] end subgraph EXTERNAL["External Classification (Envelope)"] EXT1["PASS → PASS"] EXT2["BLOCKED → CONDITIONAL"] EXT3["DENIED → STRUCTURAL"] EXT4["INVALID_CONFIGURATION → STRUCTURAL"] end INPUT --> LC & TMP & ENF & DEP & CAP & VER & DEC & D8 LC & TMP & ENF & DEP & CAP & VER & DEC --> VALIDATE D8 -->|"Aggregated via resolveOutcome()"| RESULT VALIDATE -->|"invalid"| RESULT VALIDATE -->|"valid"| INVARIANTS INVARIANTS -->|"violation"| RESULT INVARIANTS -->|"clean"| PRECEDENCE PRECEDENCE --> RESULT RESULT --> EXT1 & EXT2 & EXT3 & EXT4 style PRECEDENCE fill:#1a3a1a,color:#fff style INVARIANTS fill:#2d2d1a,color:#fff style D8 fill:#2a1a3a,color:#d4b8ff

Source: lib/constraint-convergence/ce-01-h.js, dimensions/*.js, evaluation-engine.js, outcome-resolver.js · ACCEPTANCE formally D8 per MAP-01-FIX · External API always-7 invariant preserved (dimension-coverage.js, expectation-map.js)

Section 5 · D3

Guardian Enforcement

The Evaluation Guardian sits at Stage 12 of the mutation pipeline. It invokes CE, persists evaluation evidence, emits events, and enforces the CE outcome. The Guardian never reads stored evaluation results to make decisions — it always invokes the live engine. Stored results are evidence only.

D3 — Guardian Enforcement Map V1 Core Verified

sequenceDiagram participant Pipeline as Protocol Mutation Pipeline (Stage 12) participant Guardian as Evaluation Guardian\nlib/evaluation-guardian.js participant CE as Constraint Convergence Engine\nlib/constraint-convergence/ participant Events as Event Layer\nlib/evaluation-events.js participant DB as evaluation_results\n(INSERT-only evidence) Pipeline->>Guardian: runEvaluationGuardian({entitlement_id, tenant_id, operation_class, actor_ref}) Guardian->>Events: emitEvaluationRequested(evaluation_id, entitlement_id) Note over Guardian: evaluation_id pre-generated BEFORE engine invocation Guardian->>CE: evaluateEntitlementUsability(entitlement_id, context) alt System error CE-->>Guardian: throws ConstraintEvaluationError Guardian->>Events: emitEvaluationFailed(evaluation_id) Guardian-->>Pipeline: re-throws — pipeline fails closed else Evaluation complete CE-->>Guardian: ConvergenceResult {exercisable, outcome, dimension_results} Guardian->>DB: INSERT evaluation_results (ON CONFLICT DO NOTHING — idempotent) Guardian->>Events: emitEvaluationCompleted(evaluation_id, canonical_result) Guardian-->>Pipeline: return ConvergenceResult end alt exercisable = true Pipeline->>Pipeline: open transaction → execute mutation else exercisable = false Pipeline->>Pipeline: throw EvaluationGuardianBlockedError Pipeline-->>Caller: HTTP 403 EvaluationDeniedResponse end Note over Guardian,CE: INVARIANT: Guardian NEVER reads stored evaluation_results.\nGuardian ALWAYS invokes the live engine. Note over DB: Stored results are EVIDENCE ONLY.\nNot used for future enforcement decisions.

Source: lib/evaluation-guardian.js, lib/protocol-mutation-pipeline.js Stage 12 · Persistence failure is non-fatal; enforcement continues

Section 6 · D5

Entitlement Lifecycle

Five canonical lifecycle states with explicit transition authorities. CONSUMED and REVOKED are terminal — no transitions out. EXPIRED is not a lifecycle state; expiry is handled by the TMP dimension at evaluation time. SUSPENDED and FROZEN are runtime evaluation overlays via the ENF dimension — they do not change lifecycle state.

D5 — Entitlement Lifecycle State Machine V1 Core Verified

stateDiagram-v2 [*] --> PENDING : entitlement.create PENDING --> ISSUED : issue (issuer) ISSUED --> ACTIVE : activate (holder, issuer) ACTIVE --> CONSUMED : consume (holder, issuer, system) ACTIVE --> REVOKED : revoke (issuer only) CONSUMED --> [*] : TERMINAL REVOKED --> [*] : TERMINAL state "SUSPENDED and FROZEN are ENF dimension overlays, not lifecycle states. Evaluated at runtime by CE." as ENF_OVERLAY ACTIVE --> ENF_OVERLAY : ENF evaluation overlay ENF_OVERLAY --> ACTIVE : lifecycle unchanged state "EXPIRED is NOT a lifecycle state. Expiry is TMP dimension evaluation. Entitlement stays ACTIVE, exercisability blocked at CE." as TMP_NOTE ACTIVE --> TMP_NOTE : TMP may deny exercisability TMP_NOTE --> ACTIVE : lifecycle unchanged

Source: lib/lifecycle.js — STATES, VALID_TRANSITIONS, TRANSITION_AUTHORITY (lines 88–151) · Database constraint chk_lifecycle_state_canonical enforces enum

Section 7 · D7

Operation Taxonomy

The operation class registry defines the canonical grammar for all protocol surface operations. Grammar: <domain>[.<subdomain>].<verb>[.<subtype>] — max 4 segments. Spec-locked in operation-class-taxonomy.md.

D7 — Operation Taxonomy Map Boundary Verified

mindmap root((Operation Class\nTaxonomy)) Entitlement Domain entitlement.create entitlement.consume entitlement.transition entitlement.transition.issue entitlement.transition.activate entitlement.transition.cancel entitlement.transition.redeem entitlement.expire entitlement.import Container Domain container.create container.import container.update Enforcement Domain enforcement.apply enforcement.lift enforcement.expire Delegation Domain delegation.grant delegation.revoke delegation.action.log Contestation Domain contestation.create contestation.effect.assign Claims Domain claim.create claim.line.create claim.assess claim.transition Settlement Domain settlement.create Template Domain template.create template.update template.delete Verification Domain verify.submit verify.revoke Authorisation Domain authorisation.create

Source: lib/operation-class-registry.js, docs/protocol/operation-class-taxonomy.md

Section 8 · D4

Agent Decision Flow

How a MTK-aware agent interprets structured evaluation responses vs. a naive agent that retries blindly. The protocol's machine-readable decision format enables agents to distinguish remediation paths from terminal denials.

D4 — Agent Decision Flow Boundary Partial Beta

Caveat — UAR next_action fields are partially wired (ANS-FIX-01). No standalone UAR module confirmed in source tree. This diagram describes the intended flow; implementation status of next_action guidance is PARTIAL. Do not read this as a fully implemented feature.

sequenceDiagram participant Agent as MTK-Aware Agent participant Naive as Naive Baseline participant API as MintPass API Note over Naive,API: NAIVE BASELINE — no protocol awareness Naive->>API: POST /api/entitlements/{id}/consume API-->>Naive: HTTP 403 (generic) Naive->>Naive: Retry blindly Naive->>API: POST /api/entitlements/{id}/consume API-->>Naive: HTTP 403 (infinite loop risk) Note over Agent,API: MTK-AWARE FLOW Agent->>API: GET /api/entitlements/{id}/evaluation API-->>Agent: EvaluationEnvelope {decision: PASS|CONDITIONAL|STRUCTURAL,\nprimary_reason, dimension_summary[7],\nnext_action [PARTIAL]} alt decision = PASS Agent->>API: POST /api/entitlements/{id}/consume {quantity: 1} API-->>Agent: HTTP 200 {consumed: true} else decision = CONDITIONAL (BLOCKED — remediation possible) Agent->>Agent: Read blocking_constraints[]\nidentify blocking dimension Agent->>Agent: Execute remediation\n(lift enforcement / replenish capacity) Agent->>API: Re-evaluate API-->>Agent: PASS Agent->>API: POST consume API-->>Agent: HTTP 200 else decision = STRUCTURAL (DENIED — terminal) Agent->>Agent: Read denial_reasons[]\nidentify terminal dimension Agent->>Agent: Escalate or abandon — no blind retry end Note over Agent: MTK reduces: blind retries, guessed recovery paths,\nambiguous failures, repeated invalid calls

Source: Memory (ANS-FIX-01, CG-19 agent test results), routes/sandbox.js test cases, OpenAPI (EvaluationDeniedResponse, BlockingConstraintItem) · PARTIAL: next_action UAR field wired per ANS-FIX-01; no standalone UAR module confirmed

Section 9 · D6

Architecture Layer Map

The layered architecture of the V1 protocol. Runtime and constitutive layers are verified in source. The carrier layer is a partial adapter — only bare UUID and API token are implemented; JWT, QR, and wallet carriers are conceptual.

D6 — Architecture Layer Map Partial

Caveat — The carrier row (JWT / QR / wallet) is labelled CONCEPTUAL. These carriers are not implemented. Bare entitlement UUID and API token identity are the only implemented carrier mechanisms.

graph TB subgraph CONSTITUTIVE["Constitutive Layer (V1 Partial — VERIFIED)"] TERMS["Terms Governance\nlib/terms.js, terms-binding.js\nterms-acceptance.js\nStatus: IMPLEMENTED"] AUTHORITY["Issuer Authority\nlib/authorisation-engine.js\nStatus: IMPLEMENTED"] JURISDICTION["Jurisdiction\nterms_versions.jurisdiction\nStatus: PARTIAL"] end subgraph RUNTIME["Runtime Layer (V1 Core — VERIFIED)"] LC_R["Lifecycle\nlib/lifecycle.js"] TMP_R["Temporal\ntmp-dimension.js"] ENF_R["Enforcement\nenforcement-overlay.js"] DEP_R["Dependency\nlib/dependency.js"] CAP_R["Capacity\ncap-dimension.js"] VER_R["Verification\nver-enforcement.js"] DEC_R["Decision\nexternal-decision-binding.js"] CE_R["CE — Convergence Engine\nlib/constraint-convergence/\nSOLE TRUTH AUTHORITY"] GUARD_R["Guardian\nlib/evaluation-guardian.js\nENFORCEMENT GATE"] end subgraph CARRIER["Carrier Layer (PARTIAL ADAPTER — SOURCE GAP)"] BARE_C["Bare Entitlement UUID\nStatus: IMPLEMENTED"] API_C["API Token + X-Tenant-Id\nlib/api-keys.js\nStatus: PARTIAL"] JWT_C["JWT Carrier\nStatus: CONCEPTUAL (not implemented)"] QR_C["QR Code Carrier\nStatus: CONCEPTUAL (not implemented)"] WALLET_C["Wallet Pass\nStatus: CONCEPTUAL (not implemented)"] end subgraph EXTENSION["Extension Layer (V1 Peripheral)"] CONT["Contestation\nStatus: IMPLEMENTED"] CLAIM["Claims\nStatus: PARTIAL — ADAPTER"] SETTLE["Settlements\nStatus: PARTIAL — ADAPTER"] end CONSTITUTIVE --> RUNTIME RUNTIME --> CARRIER CARRIER -.->|"Carrier presents — does not define truth"| RUNTIME RUNTIME --> EXTENSION style JWT_C fill:#4a1a1a,color:#ff9999 style QR_C fill:#4a1a1a,color:#ff9999 style WALLET_C fill:#4a1a1a,color:#ff9999 style CE_R fill:#1a3a1a,color:#88cc88 style GUARD_R fill:#2d4a2d,color:#88cc88

Source: Multiple lib/ and routes/ files · Carrier layer: SOURCE GAP — no CRB module found in source tree

Section 10 · D9

Evidence-to-Assertion Pattern

How external evidence (terms acceptance, verification tokens, external decisions) flows through normalisation and assertion steps before becoming inputs to CE dimension evaluation. SCL and AER are architecture patterns describing these responsibilities — they are not standalone runtime modules.

D9 — Evidence-to-Assertion Flow Partial

Caveat — SCL (Standard Compatibility Layer) and AER (Assertion/Evidence Resolution) are architecture patterns, not runtime modules. No lib/scl or lib/aer module exists. These responsibilities are implemented across domain-specific components in terms, verification, and dimension-evaluation code. Do not read this diagram as evidence that standalone SCL/AER modules exist.

flowchart LR subgraph EVIDENCE["External Evidence Sources"] TERMS_EV["Terms Acceptance Record\nterms_acceptance_log"] VER_EV["Verification Evidence\nverification_tokens, verification_consents"] EXT_DEC["External Decisions\nexternal_decision_binding.js"] end subgraph NORMALISE["Normalisation (SCL role — PATTERN, not module)"] TERMS_NORM["lib/terms.js\nDeterministic hashing\nBINARY/STRUCTURED/TEXT"] VER_NORM["lib/ver-enforcement.js\nLoads effective VER\nMaps to VER policy"] end subgraph ASSERT["Assertion (AER role — PATTERN, not module)"] ACC_ASSERT["lib/terms-acceptance.js\nbindEntitlementToTerms()\nper-actor-per-version ledger"] VER_ASSERT["verification_consents\nstatus resolution"] end subgraph CE_INPUT["CE Dimension Inputs"] ACC_DIM["acceptance-dimension.js\n(D8) → DimensionResult"] VER_DIM["ver-dimension.js\n→ DimensionResult"] DEC_DIM["dec-dimension.js\n→ DimensionResult"] end TERMS_EV --> TERMS_NORM VER_EV --> VER_NORM EXT_DEC --> DEC_DIM TERMS_NORM --> ACC_ASSERT VER_NORM --> VER_ASSERT ACC_ASSERT --> ACC_DIM VER_ASSERT --> VER_DIM ACC_DIM & VER_DIM & DEC_DIM --> CE["CE — evaluateEntitlementUsability()"]

Source: lib/terms.js, lib/terms-acceptance.js, acceptance-dimension.js, ver-enforcement.js · SCL/AER: architecture patterns only per MAP-01-FIX

Section 11 · D10

Entitlement Relationship Map

The relationships between an entitlement and the protocol entities it connects to. Core relationships (container, terms, dependency, enforcement, evaluation results, lifecycle) are verified. Claims, itineraries, and settlements are vertical adapters — not V1 kernel.

D10 — Entitlement Relationship Graph Partial

Caveat — Claims, claim lines, itinerary nodes, and settlement receipts are labelled Vertical Adapters. They consume the protocol but are not part of the V1 kernel. Do not read their presence as evidence of core protocol features.

Relationship	Classification	Source	Status
entitlement → container	V1 Core	containers table, FK on entitlements	IMPLEMENTED
entitlement → terms_version	V1 Core	lib/terms-binding.js, migration 069	IMPLEMENTED
entitlement → dependency (BLOCKS_ON)	V1 Core	dependency.js, dependency_grants table	IMPLEMENTED
entitlement → enforcement_actions	V1 Core	enforcement-overlay.js, ENF dimension	IMPLEMENTED
entitlement → evaluation_results	V1 Core	evaluation-guardian.js (INSERT-only evidence)	IMPLEMENTED
entitlement → lifecycle_transitions	V1 Core	lifecycle.js audit trail	IMPLEMENTED
container → container_policies	Boundary	contestation-policy routes	IMPLEMENTED
entitlement → delegation_grants	Boundary	delegation routes	IMPLEMENTED
entitlement → contestations	Boundary	contestation-policy-snapshot.js	IMPLEMENTED
entitlement → claims	Adapter	routes/claims.js	PARTIAL — VERTICAL ADAPTER
entitlement → itinerary_nodes	Future	routes/itineraries.js	PARTIAL — VERTICAL ADAPTER
entitlement → settlement_receipts	Adapter	routes/settlements.js	PARTIAL — VERTICAL ADAPTER

Source: lib/dependency.js, lib/terms-binding.js, database table list (CLAUDE.md), lifecycle.js

Section 12

V1 Kernel Summary

The V1 kernel is the set of components that must exist for MintPass to be structurally coherent. Boundary components prevent architectural drift. Adapter/extension surfaces consume the protocol without defining protocol truth.

V1 Kernel — Required

Constraint Convergence Engine (ce-01-h.js + 7 canonical + D8)
Evaluation Guardian (evaluation-guardian.js)
Protocol Mutation Pipeline (protocol-mutation-pipeline.js)
Lifecycle State Machine (lifecycle.js)
Authorisation Engine + gate-mutation.js
Actor Ingress (actor-ingress.js)
Operation Class Registry
Evaluation Envelope (normalise + buildCanonical)
Terms Governance (terms.js, terms-binding.js, terms-acceptance.js)
Event emission layer (evaluation-events.js, events.js)

Boundary Components

constraint-result.js (projectUsability)
Stage 11 VER gate (ver-enforcement.js)
replay-engine.js
Expectation map (expectation-map.js)
dimension-coverage.js (always-7 invariant)

Adapter / Extension Surfaces

enforcement-overlay.js (ENF context input)
dependency.js (DEP context input)
api-keys.js (API token identity)
contestation overlay context
Claims (Vertical Adapter — Insurance)
Claim lines (Vertical Adapter — Insurance)
Settlement receipts (Vertical Adapter)
Itinerary nodes (Future / Vertical Adapter)
JWT / QR / Wallet carriers (Conceptual)

Section 13

Boundary Rules

CE is the evaluation truth authority. The Constraint Convergence Engine is the sole source of final evaluation truth. No other component creates a second evaluation path.
Guardian enforces CE output — does not create a second truth path. The Evaluation Guardian invokes CE and enforces the result. It does not re-evaluate, re-interpret, or override CE output.
Stages 5, 9, and 10 preserve context — they do not independently block. These stages enrich the mutation context and provide inputs to later evaluation, but they do not independently decide final entitlement exercisability. Final mutation permission is controlled by Stage 12 through the Evaluation Guardian and Constraint Convergence Engine.
Stage 11 is a pre-flight VER gate. Stage 11 may block before Stage 12 when verification prerequisites are unsatisfied. It does not create a second truth path — CE remains the canonical source of final evaluation truth.
Carriers present or invoke entitlements — they do not define protocol truth. A carrier must be replaceable by a bare entitlement reference without changing correctness. CE receives an entitlement_id, not the carrier itself.
SCL and AER are architecture patterns in V1, not standalone runtime modules. Standard compatibility and evidence resolution are implemented through domain-specific normalisation, terms, verification, external decision, and dimension-evaluation components rather than standalone runtime modules.
Vertical adapters consume the protocol — they do not define protocol truth. Claims, itineraries, settlements, and contestation policy system are extension surfaces. They consume V1 protocol primitives but are not part of the V1 kernel and must not influence the core truth chain.
Stored evaluation results are evidence, not future enforcement truth. The evaluation_results table is INSERT-only evidence for audit and replay. The Guardian never reads stored results to make decisions — it always invokes the live engine.

Section 14

What is not V1 kernel

Component	Classification	Notes
Claims / Claim lines	Adapter Extension	Vertical adapter for insurance use case. Not V1 kernel.
Itinerary nodes	Future Adapter	Travel insurance vertical. Not V1 kernel.
Settlement receipts	Adapter Extension	Vertical adapter. Downstream of claims. Not V1 kernel.
Full contestation policy system	Extension	Complex extension. Contestation overlay context is a boundary pipeline input.
JWT / QR / Wallet carriers	Future	CONCEPTUAL. No carrier resolution code exists. Bare UUID and API token are implemented.
Carrier Resolution Boundary (CRB)	Source Gap	No CRB module found in source. Architecture pattern, not an implemented module.
SCL (Standard Compatibility Layer)	Pattern	Architecture pattern. Implemented across terms/verification components. Not a runtime module.
AER (Assertion/Evidence Resolution)	Pattern	Architecture pattern. Implemented across dimension-evaluation components. Not a runtime module.
D8 Carrier Boundary Map	Excluded	Excluded from this publication. No carrier resolution code exists; publishing would imply unimplemented features.

Section 15

Source and confidence notes

MAP-01 (Report #633836, 2026-05-04) produced the protocol cartography and structural necessity audit. It read and verified: ce-01-h.js, evaluation-engine.js, dimensions/*.js, evaluation-guardian.js, protocol-mutation-pipeline.js, lifecycle.js, gate-mutation.js, authorisation-engine.js, operation-class-registry.js, and the OpenAPI spec (165 operations). 24 components were audited for structural necessity.

MAP-01-FIX (Report #633882, 2026-05-04) applied six architecture drift corrections before publication. MAP-01-FIX is the controlling correction layer where the two reports differ. Key corrections: ACCEPTANCE formally classified as D8; Stage 5/9/10 demotion formalised; Stage 11 classified as pre-flight VER gate; SCL/AER classified as architecture patterns; carrier layer labelled Partial Adapter; vertical adapters separated from V1 kernel.

Diagrams labelled Verified are source-grounded and confirmed in implementation. Diagrams labelled Partial or Beta should not be read as complete implementation claims.

D8 Carrier Boundary Map was excluded from this publication because no carrier resolution code currently exists in the source tree. Publishing it would imply unimplemented features.

CG-19 chain preservation: This page build did not modify any OpenAPI schemas, public endpoint response definitions, sandbox discovery responses, consume contract documentation, HTTP 403 disambiguation semantics, or CG-19-validated contract elements. Zero runtime API contract changes.

MintPass Protocol Architecture