Elyon-Sol v0.9.8.4 — Enforcement Evidence Addendum (Revision 3)

Elyon-Sol is a deterministic, fail-closed HTTP admission gate derived from a formal admissibility specification. The canonical model is unchanged from v0.9.8.4: G(I) = AC³ ∧ T²⁶ ∧ CCS. This addendum (Revision 3) reports enforcement evidence for a fixed implementation snapshot, superseding Revision 2 (DOI 10.5281/zenodo.20387278). All three canonical invariants — Authority (AC³), Coverage (T²⁶), and Continuity (CCS) — are implemented and exercised in code at the snapshot; Continuity is realized at the admissibility envelope layer (a content-hashed record of decision state, reasserted against live state; a change in canon, manifest, or evaluator state invalidates a prior ELIGIBLE per canon §12.4, and eligibility does not persist across transitions without revalidation per canon §13). Since Revision 2, while the canon stayed locked, the implementation advanced to a signed, enforced, multi-process gate: target-side envelope verification, delivery to an enforcing downstream, mandatory Ed25519 signing of every admitted forward, issuer-key expiry plus a published signed key record with revocation and planned key/root rotation, cross-host transport of the integrity-anchored record, a machine-checked readiness instrument, and a standalone reference enforcing target exercised across separate processes over real TLS — closing in code the Revision-2 items of non-bypassable enforcement (for routed, attested traffic) and evaluator-domain canon-derived testing. Measured results: the full repository test suite passes 211 of 211, 0 xfailed (up from 84 at Revision 2); and a third-party-observed enforcement run recorded 204 HTTP calls (102 REFUSE, 102 ELIGIBLE), 0 unexpected outcomes, and exactly 102 external executions — one per ELIGIBLE call, zero from REFUSE calls — with each ELIGIBLE forward gate-signed. The attached PDF contains the evidence summary, the canon-derived adversarial validation surface, an explicit honest-scope section (no external adversarial validation on a real multi-host surface has been performed; the enforcement run is author-driven third-party observation over local transport), and provenance. This is an evidence publication for provenance, not a build guide: the production implementation is proprietary and is not distributed, and step-by-step reproduction instructions, internal structure, and deployment detail are intentionally omitted. The canonical model is published for citation; the production implementation and its reproduction procedures are proprietary, all rights reserved. Additional Notes: Revision 3 — provenance & evidence edition. Supersedes the prior version. The canonical model (v0.9.8.4) is unchanged. This version refreshes the enforcementevidence to the current implementation snapshot — full repository test suite 211/211passing (0 xfailed, up from 84), and a third-party-observed run of 204 HTTP calls(102 REFUSE → 403 with 0 external executions; 102 ELIGIBLE → 200 with exactly 102external executions, each gate-signed). It records the capabilities added sinceRevision 2 (target-side verification, envelope delivery and enforcement, mandatorysigning, key/root records with revocation and rotation, cross-host transport, and areference enforcing target) at the claims level. The publication is scoped to claims and evidence for provenance. Step-by-stepreproduction instructions, internal structure, and deployment detail have beenintentionally removed; the production implementation is proprietary (all rightsreserved). The canonical model remains published for citation.