Where the project is
E1 — the source-statement evidence spine — is complete and locally attested. P1 — the public foundation, including this website — is in progress. E2, the agent-facing typed interface demonstrator, is authorised and not started. Everything after that is planned, not built.
The next admission condition is not a feature
It is independent review and CI reproduction of the E1 report. Public deployment is explicitly not the next gate. A project whose thesis is verifiability does not get to skip being verified.
Two sequences, not one
Engineering gates and public milestones are separate sequences, because they were previously one and collided. An engineering gate is admitted on executed evidence. A public milestone is admitted on an independent audit of a public surface. Neither blocks the other from being described honestly.
E0 · E1 · E2 … Engineering gates
Admitted on executed evidence.
- An objective written before the work
- Commands, hosts, versions, and results
- A published unresolved-risk register
- An admission condition for the next gate
P0 · P1 · P2 … Public milestones
Admitted on an independent audit of a public surface.
- Every factual claim traced to an artefact
- Every implementation status labelled
- Every recorded risk published
- A verdict of PASS or PASS WITH CONDITIONS
decisions/002-gate-namespaces.md — pending. The namespaces below are adopted on the founder's recorded decision of 2026-08-10 and this page will cite the ADR once it is committed.
Engineering gates
Founding architecture
Complete- Objective
- Fix the invariants, trust boundaries, wire schemas, and governance law before writing the implementation they constrain.
- Evidence
- ARCHITECTURE.md, CHARTER.md, constitution/, schemas/cddl, THREAT_MODEL.md
- Open risk
- A written invariant is not an enforced one. E0 is only credible because E1 tested it.
- Admission
- Superseded by E1.
Source-Statement Evidence Spine
Complete- Objective
- Prove the smallest complete path from an origin's bytes to a typed, provenance-bearing value, with an independent second implementation checking the canonical artefact.
- Evidence
- reports/gate-1-genesis.md — 94 named Go test events, 16 shared Go/C observation vectors, 11 extraction vectors, 4 Go fuzz targets, 5,000 sanitizer-instrumented C libFuzzer executions, offline replay.
- Open risk
- Seven unresolved risks, published in full. Hosted CI has never executed, so local acceptance is the only executed validation evidence.
- Admission
- Independent review and CI reproduction of the E1 report. Public deployment is explicitly not the next gate.
Agent-Facing Typed Interface Demonstrator
Next- Objective
- Prove that one canonical operation definition can expose a real read-only resource to an agent through CLI, JSON Schema, OpenAPI, and MCP at once — preserving native meaning, immutable evidence, exact semantic closure, and field-level provenance.
- Evidence
- None yet. Authorised as an engineering proposal; not started.
- Scope
-
- Minimal TWIR Core 0.1 — only the primitives the demonstration needs
- A canonical typed result envelope that fails closed without required provenance
- Manifest-last evidence bundles: logical transactionality without claiming a filesystem transaction
- Observation v2 recording the redirect chain and an allowlist of representation-relevant headers
- Independent C verification extended from the observation to the result envelope and bundle manifest
- TWIRX as its own first typed origin: project.getStatus, project.getEngineeringGateReport, project.listUnresolvedRisks
- A deterministic agent transcript: make demo-e2
- Open risk
- Bindings are where a protocol quietly acquires a runtime dependency. MCP tooling must stay pinned and isolated under bindings/, never in the core.
- Admission
- One operation definition, four generated bindings, verified in Go and C, with a reproducible transcript and a controlled — not universal — performance comparison.
Multi-origin deterministic compiler
Planned- Objective
- Compile three distinct representation classes — JSON API, JSON-LD or structured HTML, and RSS or Atom — into adapters deterministically, and answer one common semantic query across all of them.
- Evidence
- None. No implementation exists.
- Open risk
- Automatic compilation is where silent misinterpretation becomes cheap. The conformance corpus has to grow first.
- Admission
- Deterministic output across two implementations for a published corpus, using controlled fixtures and recorded public snapshots.
Isolated browser discovery
Planned- Objective
- Use a browser for discovery only, inside process or microVM isolation, with no access to canonical state, credentials, or the control network.
- Evidence
- None. Genesis is browser-free by design.
- Open risk
- A browser is the largest attack surface this project will ever adopt. It must never enter the execution path.
- Admission
- Demonstrated isolation and egress control, and the proven inability of a discovery worker to write canonical state. Only after result envelopes, bundle admission, independent verification, and agent bindings are stable.
Schema induction and learning ledger
Research- Objective
- Deterministic schema candidates first, then a neutral record of proposals, acceptances, rejections, drift, and repair that later research could learn from.
- Evidence
- None. No model exists anywhere in the canonical path.
- Open risk
- Prompt injection from observed content is assumed, not hypothetical. A model output is untrusted data.
- Admission
- A proposal can never promote itself. Every accepted proposal keeps the adjudication record that accepted it.
Public milestones
Private foundation
Complete- Objective
- A private repository with a charter, licence, security policy, threat model, access policy, funding covenant, and a public-readiness audit before anything is exposed.
- Evidence
- CHARTER.md, LICENSE, SECURITY.md, THREAT_MODEL.md, ACCESS_POLICY.md, FUNDING.md, reports/public-readiness.md
- Open risk
- None outstanding.
- Admission
- Superseded by P1.
Public foundation
In progress- Objective
- Make the proof legible: this website with a working provenance explorer, authoritative documentation at docs.twirx.org, a transparent treasury, and an independent factual audit of both public surfaces before the repository visibility changes.
- Evidence
- This site and reports/public-foundation-website.md. Documentation release pending. Commit-metadata privacy remediation pending.
- Open risk
- A public surface can overstate an implementation faster than code can. Every technical claim here carries an implementation-status label, and the build fails if a recorded risk is left off the page.
- Admission
- An independent audit of every factual claim, dependency, link, funding total, and status label must return PASS or PASS WITH CONDITIONS before the repository becomes public.
Public launch and funding campaign
Planned- Objective
- Public repository, live site and documentation, a verified treasury address, and an open Genesis funding campaign backed by E1 evidence with E2 in active development.
- Evidence
- None yet.
- Open risk
- Launching before the treasury address is independently verified would put contributors at risk. No address is published until it is in funding/wallets.json on the default branch.
- Admission
- History scan passes, twirx.org and docs.twirx.org are live, the ledger is verified, and every claim is either tied to evidence or explicitly marked as vision.
How a gate is admitted
A gate is not a milestone announcement. It closes only when four things exist at once:
- An objective stated in advanceWritten before the work, so that the work cannot be redefined to match whatever was achieved.
- Executed evidenceCommands, hosts, versions, and results — not a description of what the code is believed to do.
- An unresolved-risk registerPublished in full. A gate with no open risks has not been examined carefully enough.
- An admission condition for the next gateStated at the moment of closing, before there is any incentive to lower it.
A later gate may not weaken an earlier invariant without a public protocol decision and a migration path. That constraint is in the architecture baseline, and it is why the sequence is ordered as it is: every gate that adds capability comes after the gate that adds the ability to check it. E4 adds a browser only after result envelopes, bundle admission, independent verification, and agent bindings are stable.
The renumbering
Engineering and public milestones were previously one numbered sequence, and two documents disagreed about what each number meant. Rather than quietly harmonise them, the mapping is published. Historical reports keep their original numbering.
| Formerly | Now | Name |
|---|---|---|
Gate 1 | E1 | Source-Statement Evidence Spine |
Gate 2 | P1 | Public Foundation |
Gate 3 (architecture baseline 0.2: Gate 2) | E3 | Multi-origin deterministic compiler |
The E1 evidence report is still filed as reports/gate-1-genesis.md under its original name, because renaming an evidence artefact after the fact is exactly the kind of edit an evidence trail is supposed to make impossible. Machine-readable: gates.json.