Verification and acceptance boundaries
The four verification levels, and why none of them substitutes for another. This is the language any external capability claim has to use.
Why levels are needed
"The page exists" is not the same as "the capability is complete". In a privately deployed product the cost of confusing them is specific: the buyer will run acceptance against your description, and the acceptance failure happens at the customer site.
The platform therefore states the completeness of each capability against four distinct levels. No level substitutes for another.
| Level | Established by | What it proves | What it does not prove |
|---|---|---|---|
| 1. Implemented | Code and targeted tests | The route, API, domain service and authoritative store or runtime path exist | That it deploys, or that real external systems can be integrated |
| 2. Passing repository gates | Tests, type checks, builds, protocol and module boundary validation | The code is self-consistent in an isolated environment | Runtime behaviour — gates usually run against controlled fixtures |
| 3. Deployed | An immutable image from a named snapshot, plus health, routing and smoke checks in a named environment | That it can be deployed and the basic path is reachable | Any business capability — smoke checks only show the process is alive and routes respond |
| 4. Authenticated business end to end | A real signed-in principal using a real model gateway, Git service, connector or data plane for the corresponding read/write path | Business capability | — |
1. Implemented
The route, API, domain service and authoritative store or runtime path exist, with targeted tests.
This level proves the code was written and the path is connected. It does not prove a deployment runs, nor that a real external system can be integrated.
2. Passing repository gates
The relevant tests, type checks, builds, protocol and module boundary validation pass.
This level proves the code is self-consistent in an isolated environment. It does not prove runtime behaviour, because gates usually run against controlled fixtures.
3. Deployed
A named code snapshot is built into an immutable image and passes health, routing and the relevant smoke checks in a specified environment.
This level proves it can be deployed and that the basic path is reachable. It does not prove any business capability, because smoke checks normally verify only that the process is alive and routes respond.
4. Authenticated business end to end
A real signed-in principal completes the corresponding read and write path against a real model gateway, Git service, connector or data plane.
This is the only level that proves a business capability.
Why they do not substitute for each other
A full-route browser check against controlled fixtures proves the production bundle, routing and layout. It uses static data, so it proves nothing about the correctness of any data path.
A clean build or a basic health check cannot stand in for runtime acceptance. A deployment that never reached a model gateway can be perfectly healthy.
A cluster smoke test or a single real task cannot stand in for per-capability business acceptance. One successful task does not prove that knowledge recall, marketplace publishing or enterprise sign-in work as well.
Current state
The repository already contains a working vertical slice, runnable locally and on OrbStack, used to verify that the product's domain model, control plane, real agent sessions, isolated sandbox, dependency graph scheduling, artefact handoff, knowledge recall, runtime snapshot and resume, observability and console experience connect end to end.
That is not the same as a complete production release. The following are still under construction and acceptance:
- full coverage of the persistent services;
- enterprise single sign-on and audit;
- a highly available control plane;
- additional coding drivers;
- production installation and upgrade;
- full end-to-end acceptance against real enterprise gateways and code hosting systems.
The authoritative statement of what is implemented and what is missing is the system architecture document in the repository.
The rule for external claims
In external material, pre-sales briefings and acceptance reports:
- do not claim a capability is available without level-four evidence;
- do not use "deployed" in place of "accepted";
- state the difference between the target shape and the current implementation explicitly.
This rule governs this manual itself, not only the product.