10contributors verified
3first-seal packages
32bytes per edge object
8/8controls passed
01 / Explore
Explore the measured outcomes
These buttons display saved test results. They do not send transactions or change the running stack.
| Contributor | Evidence status | Local warehouse position | Finding |
|---|
02 / Evidence
What this run establishes
The native edge, admission journal, first-seal engine, warehouse and second-seal code ran locally. The existing Chamber warehouse verifier checked proofs through an in-process HTTP test transport. A new, small case adapter joined the evidence; no orchestration service was introduced.
- Evidence for all ten contributors was reconstructed across three separate first-seal packages.
- The second seal and its synthetic delegated signature verified.
- Replaying an admitted frame did not create another admission.
- The generated Chamber database was deleted and restored from its local backup; the evidence was verified again.
03 / Next step
Next, before a partner pilot
- live HTTP/TLS/session enrollment and separate servers not exercised
- Chamber case aggregation is this new pilot adapter, not deployed API
- five synthetic ERP work threads, not real clinical deployment or real partner integration
- case plan and lane/member binding are trusted fixture configuration
- independent storage failure domains and fleet recovery not demonstrated
Ten simulated identities are not ten participating companies. This run uses five paired ERP work threads as evidence fixtures; it does not execute a clinical model or prove business acceptance. Reusing the evidence path for Ambiti8n's actual deployment steps remains integration work.