The TML framework does not replace the binary inference engine. This is the most consequential architectural fact in the entire specification, and every design decision in openapi.yaml and tml_schema.json flows from it.

The binary inference engine operates as the system's fast cognitive layer: speed, pattern recognition, and statistical throughput. The ternary logic operates as a sovereign governance coprocessor running in parallel. These two systems are not sequential; they are not a pipeline where one feeds the other and then yields. They operate simultaneously on distinct lanes, and their relationship is asymmetric by constitutional design.

The binary system proposes actions. The ternary system dictates whether those actions physically cross the threshold into execution.

This asymmetry is not a preference. It is the architectural enforcement of the Goukassian Vow:

The binary system can only ever produce a proposal. The ternary system holds the actuation gate. No proposal from the binary system authorizes execution. Only a cryptographically valid Permission Token, issued exclusively by the Anchoring Lane after an immutable Moral Trace Log has been committed, authorizes execution. This is the No Log = No Action iron law, enforced at three independent layers: the OpenAPI contract, the JSON Schema bundle, and the on-chain ABI.

The separation of proposal from authorization is expressed at every layer of the specification. This section traces the full lifecycle of a decision vector to demonstrate that no ambiguity exists in the contract between the binary and ternary systems.

Decision vector submission. The binary inference engine submits a JustificationObject alongside a proposedAction to POST /decisions. The JustificationObject.proposedState field is described as "a proposal only; the Anchoring Lane determines the authoritative state." The uncertaintyScore field, if it breaches the configured SacredZero threshold, overrides the binary engine's proposedState and mandates currentState: 0 regardless of what the binary engine proposed. The Anchoring Lane cannot be argued out of Sacred Zero by a confident binary engine. The JustificationObject travels from the Inference Lane to the Anchoring Lane. It informs. It does not authorize.

Anchoring Lane evaluation. POST /anchoring-logs receives the complete TSLF record. The Anchoring Lane performs its own ternary evaluation, independent of the binary engine's proposedState. The EthicalVerification schema captures this independent assessment: it requires a PillarVerificationResult for each of the Eight Pillars, and its overallVerdict field is determined by the Anchoring Lane alone. A FAILED verdict from any pillar triggers currentState: -1 regardless of what the binary engine proposed.

Permission Token as actuation gate. The Permission Token's structure enforces authorization integrity through five properties: logHash (SHA-256 of the anchored log; no token without a log), laneOrigin: const "ANCHORING_LANE" (schema-level rejection of Inference Lane tokens), merkleRoot (binds token to public blockchain anchor), expiresAt (hard expiry; actuation layer must reject expired tokens), and signatureValue (HSM signature verified before actuation). The StateEnvelope schema enforces the token's mandatory presence via an if/then constraint: when currentState is 1, permissionToken is a required field. This constraint cannot be bypassed by a conforming implementation.

Sacred Zero (State 0) is the most architecturally significant state in the TML framework, and the state most vulnerable to misrepresentation. It is a first-class integer member of the triadic state space. It is not null. It is not false. It is not an HTTP error code. It is not a timeout.

In tml_schema.json, the StateEnvelope if/then/else block enforces that when currentState is 0, three distinct fields must carry three distinct values:

The Sacred Pause is not Sacred Zero. The Sacred Pause is the operational workflow that executes when the system enters Sacred Zero. A system that labels its state as "SacredPause" has confused the state with the process. The TSLF-State0 schema enforces this with const constraints on all three fields.

The Sacred Pause workflow in the API surface is expressed through four resources. GET /sacred-zero/escalations is the human-in-the-loop review queue. GET /sacred-zero/escalations/{escalationId} returns full detail including the UncertaintyQuantification record and the DeliberationMatrix presented to the human reviewer. PATCH /sacred-zero/escalations/{escalationId} is the human authority resolution endpoint: resolvedState accepts only 1 or -1; State 0 is not a valid resolution. The sacredPauseEscalation webhook delivers async notification to all registered escalation endpoints when Sacred Zero activates.

The UncertaintyQuantification schema captures the epistemic conditions. The epistemicHoldActive field carries const: true in State 0 contexts. Epistemic Hold is the canonical TML term for the system's recognition that it has reached the boundary of its reliable knowledge. The Anchoring Lane does not speculate beyond this boundary. It holds.

When Sacred Zero is activated, LanternStatus.compliancePosture reflects "SACRED_ZERO_ACTIVE" and activeSacredZeroCount increments. The TSLF-State0 schema includes a required lanternStatus field: the Goukassian Promise Lantern must be captured at the moment of Sacred Zero activation. The Lantern's public signal must not lag behind the governance state.

The Goukassian Promise (Pillar III) contributes three canonical artifacts to the TML system. In the monograph these are named as a triad. In the specification they are expressed as distinct schema types and API resources, each with its own artifactName property carrying a const value that is the lowercase canonical artifact name.

The Lantern is the public compliance beacon, exposed at GET /sacred-zero/lantern and required in TSLF-State0 records. The LanternStatus schema carries artifactName: const "lantern". Its compliancePosture field provides a five-value enum spanning the full range of system compliance states. Its pillarStatuses object reports per-pillar live status across all Eight Pillars. The LanternStatus is embedded in the GatewayRoutingStatus schema, so operators reading Gateway status get the Lantern signal without a separate call.

The Signature is the provenance and non-repudiation artifact. It is exposed at GET /goukassian/signature and embedded as a required field in TSLF-StateP1 (as theSignature), in LanternStatus, in ComplianceAttestation, and in the EIP-712 GoukassianSignatureAttestation typed data schema. The SignatureBlock schema carries artifactName: const "signature". Its signatureAlgorithm field enumerates current SHIPPING algorithms (ES256 through RS512) alongside FUTURE-reserved PQC identifiers (SLH-DSA-SHAKE-128s, ML-KEM-1024). The PQC identifiers are present to enable forward-compatible migration without a breaking schema change.

The License governs authorized use of the TML system, exposed through POST /goukassian/license/validate (validation) and POST /refusals/license-violations (violation recording). The LicenseValidationRequest schema carries artifactName: const "license". The LicenseViolationRecord schema records violations with a violatedArtifact field using lowercase canonical artifact names: "lantern", "signature", or "license". In the ITMLEnforcer ABI, these are encoded as integer ordinals (1 = lantern, 2 = signature, 3 = license) for on-chain encoding compatibility.

The specification provides a dedicated endpoint group for auditors and regulators, secured by AuditorRegulatorSecurity (CA-VettedJWT + IPAllowlist). This group is read-dominant by design: auditors do not produce state; they verify it.

The auditor's complete verification workflow, using only endpoints in this specification, proceeds as follows:

This workflow does not require access to implementation code, deployment infrastructure, or internal system state beyond what the API surface exposes. The constitutional compliance matrix (Step 4) maps each step to the monograph sections and regulatory provisions it satisfies.

Every error response across the specification conforms to RFC 7807 application/problem+json with two TML-specific extensions: x-tml-state (the triadic state active at error time, as a signed integer) and x-tml-pillar (the canonical Pillar identifier most directly implicated). These extensions ensure that error responses are themselves constitutionally legible: an error is not an escape from the triadic state space. The ProblemDetail schema enforces unevaluatedProperties: false, preventing error responses from carrying undeclared fields that could introduce ambiguity.

The SacredZeroHold408 response is the canonical HTTP expression of Sacred Zero in the error surface. A 408 response carrying x-tml-state: 0 is not a timeout in the conventional sense. It is a constitutional hold. The retry_after field provides a retry interval, but the caller must await the sacredPauseEscalation webhook notification or poll GET /sacred-zero/escalations for resolution before resubmitting the same action vector.

Every POST, PUT, and PATCH endpoint in the specification requires an Idempotency-Key header (UUID v4). The idempotency window is 24 hours; within this window, a repeated request with the same key returns the original response without re-executing the operation.

Idempotency and AlwaysMemory (Pillar II) interact at the pre-actuation commit boundary. A POST /anchoring-logs request that commits a Moral Trace Log and receives a Permission Token in response cannot be re-executed to produce a second Permission Token for the same log. The first commit is the anti-spoliation anchor. The idempotency guarantee ensures that network failures between the Anchoring Lane and the calling system cannot result in duplicate log entries or duplicate token issuances for the same decision.

A feature is FUTURE when it is blocked by a named constraint from Section 10 of the TML Constitutionalization Monograph v3.3. A feature is BETA when buildable with documented tradeoffs. A feature is SHIPPING when buildable with 2025 production libraries with no known Section 10 blockers. This appendix covers FUTURE only.