The outcome you are walking toward
The ability to take any conformance statement — ours or anyone's — and place it: which level, which object, which version, and what the level does and does not tell you. Plus a clear request path for the evidence that sits behind the level, which is shared under NDA through diligence rather than published.
1. The four levels, in order
Every certificate the program issues sits at exactly one level, and the levels are cumulative:
- Laboratory — passes synthetic and controlled tests. The development gate.
- Pilot — laboratory plus a limited real-world pilot. A controlled production trial.
- Production — full conformance plus operational evidence. General deployment.
- Institutional — production plus additional audit, supply-chain, and long-term support evidence. For large networks and regulated environments.
Certificates are designed to be version-specific and time-bounded: a new major version requires re-certification. A level with no object and no version attached is not a conformance claim — it is an adjective.
2. What gets certified
The program certifies four object types, each with its own certificate scope: devices (device class plus firmware family), edge nodes and runtimes (hardware model plus runtime version), agent packages (a specific package version), and kits (a full reference configuration). When you evaluate a deployment, ask for the level of each object separately — a certified kit does not make an uncertified agent package certified.
3. The domains behind every claim
Any device or software claiming Edge Runtime compatibility is designed to pass a defined battery before admission:
- Offline continuity — critical loops continue and degrade correctly without connectivity.
- Event integrity and replay — stable event identity, correct buffering and replay, explicit gap detection, no silent loss of critical events.
- Policy enforcement while disconnected — signed policy snapshots are evaluated locally, and policy does not weaken offline.
- Resource isolation — vision, agents, commerce, and safety lanes cannot starve one another under load.
- Attestation and secure update — hardware-backed identity, runtime attestation, signed updates only, working rollback.
- Reconciliation correctness — deterministic rejoin and state reconciliation on reconnect.
- Vertical-specific critical loops — access, safety, commerce, and form feedback survive outages in the verticals that depend on them.
The full program evaluates further domains — authority and capability boundaries, evidence completeness, interoperability, and operational resilience under power, network, storage, and component failure. The offline contract guide walks through the behavior those suites measure, and the institutional deployment guide shows where the levels gate expansion. The governing rule is: no device is admitted to the production Mesh without conformance evidence.
4. What is public and what is not
The level is public. What is not public is the evidence behind it: detailed test results and findings remain controlled artifacts. Institutional customers can receive deeper evidence packs under NDA through the diligence process. This is deliberate — publishing full test evidence would expose security-relevant detail — so the public surface states the level, and diligence is where you verify it. The audit trail and evidence model doc covers how the underlying record keeps those results reproducible.
5. Who certifies
Certification is designed to be independent of the people who build: there is a clear separation between those who build agents/devices and those who certify, with accountable owners per domain and versioned test manifests so results stay reproducible. The certifier is internal-first — the program runs inside our own organization today, with customer-auditable evidence available under NDA — and independent third-party assessment is a later stage, not the basis of any current claim. Field surveillance is designed to trigger re-evaluation or revocation when behavior regresses.
6. What to ask for in diligence
Three requests cover most of the ground: the level, object, and version for every device, runtime, agent package, and kit in your proposed deployment; the offline and reconciliation battery summary for the runtime version you would run; and the evidence pack itself under NDA via the diligence resources page. For a Business-In-A-Box deployment, the bar is the whole stack at once — every device at Production or Institutional, the runtime certified, every active agent package certified at the required level, and the site's offline and safety acceptance cases passed on that site.