The source in this library cites requirement identifiers heavily — 005-FR-011, 003-FR-024,
029 T015, 012-FR-016a. There are roughly 350 of them across 45 of the 48 modules. This page
explains what they are so they read as citations rather than noise.
Why they are still here
This library was extracted from a larger application whose codebase writes reasoning next to code: moduledocs cite the requirement a decision serves, record what was MEASURED rather than assumed, and mark load-bearing choices with a ⚠️. The identifiers are load-bearing in that style — they say which rule a piece of code exists to satisfy, which is usually the fastest answer to "why is this like this".
They were deliberately not stripped during extraction. Many sentences are built around the
citation grammatically ("012-FR-001 forbids Ash, so this cannot delegate to a repo"), and
mechanically removing the token would leave prose that is worse than the shorthand. The tradeoff
accepted here is that an outside reader meets an unfamiliar identifier and needs this page once.
And the name Axonn
The same docs mention Axonn — Axonn.Sandbox.Provision, Axonn.ModelAccess.Backend.DelegatedCli,
"Axonn's copy of this script". That is the application this library was extracted from. Nothing
here depends on it, references it at compile time, or needs it to run; test/dependency_tree_test.exs
enforces that.
The mentions are kept for the same reason the identifiers are: they name the concrete caller a decision was measured against. "A host that tracks placements" is abstract, and the reasoning is easier to check when the host is a real one. Read them as provenance — this is who hit the problem that produced this rule — never as a dependency.
Reading one
005 - FR - 011
│ │ │
│ │ └── the requirement's number within that document
│ └──────── the kind
└────────────── the specification the requirement belongs toBoth 005-FR-011 and 005 FR-011 appear; the separator carries no meaning. A trailing letter
(012-FR-016a) marks a requirement refined after its first statement.
Kinds
| Prefix | Meaning |
|---|---|
FR | Functional requirement — a rule the implementation must satisfy |
NFR | Non-functional requirement — performance, operability, security posture |
SC | Success criterion — an observable condition that decides whether the feature is done |
T | Task — a unit of the implementation plan, e.g. 005 T060a10 |
R | Research finding — a measurement recorded before a decision, e.g. research R2, R9 |
A T citation usually explains when something arrived and what it replaced. An R citation
points at evidence: R2 and R9 in particular are cited often, and both record measurements that
overturned an earlier assumption.
The specifications
Each number is one specification in the originating application. They are not distributed with this package — the ones that matter to a reader here are summarised by the code that cites them.
| ID | Specification | What it contributes to this library |
|---|---|---|
003 | sandbox-contract | The sandbox lifecycle contract and the conformance suite that enforces it. The most-cited (116 references) — most of ExSandbox.Conformance traces here. |
005 | sandbox-beam | The BEAM mechanism, Linux hardening, and the egress work under T060. Source of the refusal-over-partial-confinement rule. |
007 | agent-runtime | Consumer-side context for how sandboxes are driven. |
008 | generation-verification | Evidence and verification requirements — why a claim needs an observed breach behind it. |
010 | observability | Telemetry event shape. |
012 | sandbox-libraries | The extraction itself: FR-001 (no host application, no Ash, no web framework), FR-004 and FR-014 (the public/private boundary), FR-016 (the third outcome). See boundary.md. |
013 | deployment-topology | Deployment separation, and the narrowed privilege grant the isolation harness runs under (FR-006b, FR-006f). |
014 | desktop-deployment | The macOS resource-cap floor — the :darwin_hardening tagged tests. |
015 | model-access | Consumer-side context for credential handling. |
029 | sandbox-reachability | Egress reachability: hostname allowlists, the DNS resolver, and what a sandbox is permitted to reach. |
The three that explain the most
If you read only a few, these carry the reasoning that shapes the whole library:
012-FR-001— this library depends on Elixir/OTP and:telemetry, and nothing else. It is why there is no repo, no schema, and no credential probe here, and why the conformance suite's credentials group reports "host capability unavailable" rather than passing.012-FR-016/016a— conformance scores three outcomes, not two: pass, guarantee failure, and capability unavailable. Collapsing the third into a failure produces breach reports for boundaries that were never tested.005R9 — a host that cannot enforce confinement gets a refusal, not a weaker sandbox. A partially confined tenant is worse than none, because it looks contained.