Skip to content
#software testing Open access

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

Oct 2026 · Zenodo (CERN European Organization for Nuclear Research)
Access Control and Trust

Abstract

**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** — Authority and Coverage are the two per-request set-containment checks against a SHA-256-pinned manifest, and Continuity is the property that a past admission is not honored after the policy or decision logic it depended on changes. Per the canon, the superscripts are nominal labels from the original notation, not exponents. **This revision (Revision 9) supersedes Revision 8** (DOI 10.5281/zenodo.21364720). It is a **correction-and-evidence revision**, not a model advance: it corrects four statements in Revision 8 that are no longer true, re-measures the enforcement evidence at a new snapshot with a harness that is now committed, and adds evidence from a real multi-container stack. Snapshot commit 2d5c6bf6c97edacc12748e6186b6ccf4eb853115, observed 2026-10-08. **What Revision 8 stated that is no longer true, corrected here.** First, licensing: the core implementation and the companion operator console are AGPL-3.0 with no commercial, proprietary, or dual-licensed components; the "open-core / proprietary tooling SDK" description was withdrawn on 2026-07-26. Second, the live surface: the four public test nodes were retired on 2026-07-20, six days after Revision 8 was published; there is no live public surface, and nothing in this revision was measured on one. Third, the evaluator pin: the SHA-pinned evaluator moved once, at ledger entry VL-150, to carry refusal reason codes that name which admission condition refused; no admissibility decision changed, the canon and manifest pins are unchanged, and the published record was regenerated through its generator. A verifier comparing a current envelope against Revision 8's record sees an evaluator mismatch; against this revision's record it does not. Fourth, the test suite is 689, up from 616. **What changed since Revision 8.** Twelve admission fixes, each pinned by a test that fails if the fix is removed, found by a white-box review of every path that honors a token and by the follow-up that closed everything it named: among them, the forward now connects to the address the guard vetted so a resolver cannot answer differently to the guard and the forward; the executor SDK refuses a token without a single-use identifier and can never reach the verifier's unsigned path; root-key validity windows are enforced; approval holds expire; the forward-target guard covers every non-global address range and its allowlist matches origins rather than hostnames; the generated secrets file is owner-only; the sidecar's decision port is loopback-only; every container image is pinned by digest. The human-approval path was proven across two gate replicas with a shared store and a mutually-authenticated target, under containers: an unapproved high-impact call is held and the target is never called; a grant minted by a separate approver process releases it exactly once; a replayed grant is refused on both replicas; the issuance and approval logs reconcile clean. A self-host stack replaces the retired live surface, so any reader can stand up the same gate, target, publisher and sidecar and run the same attacks. **Enforcement evidence, re-measured with a committed harness.** Revision 8 reported its 204-call census from a loopback receiver but named no committed harness for that variant. This revision commits one and re-runs it at the snapshot: 204 HTTP calls, 102 REFUSE returning 403 with zero external side effects, 102 ELIGIBLE returning 200 with exactly one external POST each — every forward carrying a signed envelope with a distinct single-use identifier, zero from the REFUSE branch, zero duplicates. The harness is hermetic and now runs in continuous integration on every push. The third-party receiver leg was **not** re-run; Revision 8's run stands as the last external confirmation of the forward count. In addition, the live attack suite — un-attested, forged, replayed, rebound and cross-target presentations plus a positive control — defeated six of six against the self-hosted stack over plain HTTP and again over TLS. **Licensing and access.** The canonical model remains published for citation. The core implementation, and the companion operator console GLESAC, are licensed under AGPL-3.0; there are no commercial, proprietary, or dual-licensed components (see LICENSING.md in the repository). Source public at https://github.com/Elyon-Sol/Elyon-Sol. This document is licensed CC BY 4.0. **Honest scope.** This is development-side, referent-bound evidence — the test suite, the runnable proofs, the hermetic census, and author-side executions against a stack on a single host, where custody separation between gate, approver and publisher is by container and process, not by host. No external, third-party adversarial validation on a real multi-host public surface has been performed; there has been no live public surface since 2026-07-20, so that remains the open finish line. No guarantee is claimed as deployment-certified. One deployment-visible change is recorded: an allowlist entry that is a bare hostname now admits that host on the scheme's default port only. This is an evidence publication for provenance, not a build guide. Related identifiers- https://github.com/Elyon-Sol/Elyon-Sol — Is supplemented by (software)- 10.5281/zenodo.21364720 — Is new version of (Revision 8) Additional notesRevision 9 — correction-and-evidence revision. Corrects Revision 8 on licensing (AGPL-3.0 only; no commercial, proprietary or dual-licensed components), on the live surface (retired 2026-07-20; no live public surface exists), on the evaluator pin (ca7c922c since VL-150, refusal reason codes; canon and manifest unchanged) and on the test count (689). Twelve admission fixes since Revision 8, each pinned by a revert-proven test; the governance approval path proven across two replicas under containers; the enforcement census re-run at the snapshot commit with a committed hermetic harness (204 / 102 / 102 / 0 unexpected / 102 forwards, 0 from REFUSE); the live attack suite 6/6 over HTTP and over TLS against a self-hosted stack. Supersedes Revision 8 (DOI 10.5281/zenodo.21364720). Canonical model (v0.9.8.4) unchanged. Honest scope retained: author-side / white-box / single host; the third-party census leg not re-run; no external multi-host adversarial validation.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54
#computer vision Review Mar 2008

Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum

The results show that the embedded industry has been able to apply agile methods in its development processes and that the appreciation of the agile methods and their individual practices appears to increase once adopted and applied in practice.

O. Salo, P. Abrahamsson · 238 citations · ⚡9
#computer vision Open access Jul 2017

What happens when software developers are (un)happy

Consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts are found.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 236 citations · ⚡13
#computer vision Open access Oct 2004

Mobile-D: an agile approach for mobile application development

The Mobile-D approach is briefly outlined here and the experiences gained from four case studies are discussed, which helped develop an agile development approach for mobile application development.

P. Abrahamsson, Antti Hanhineva, H. Hulkko et al. · 225 citations · ⚡18

Related blog posts

Microsoft Research Blog Oct 12, 2026

Simulating student learning for better AI tutoring

StudentSim is a research system for evaluating and improving AI tutoring tools before they are tested with learners. It models how individuals may engage with tutors, giving feedback to improve tutor performance across subjects like chess, writing, and mathematics. The post Simulating student learning for better AI tutoring appeared first on Microsoft Research.

MIT News · Artificial Intelligence Oct 2, 2026

Documenting the tech worker movement

Writing as a participant and researcher, PhD student JS Tan SM ’22 has co-authored a new book about the rise of tech worker protests and the employer backlash that followed.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.