A common contract
Types, generated bindings and schemas connect the application core to its service interfaces. Contract generation becomes part of the build.
Built with Canopy · EFDI Accelerator 2.0
From requirement to a working demonstrator.
Cerberus brings reports, a shared operational picture and authorised tasking into one application. It shows Canopy’s development and integration capabilities working together.
2½ weeksTeam-reported demonstrator build
Synthetic dataAn engineering demonstration
Hardware evidenceRecorded protected call · 21 September 2026
The application
One connected workflow.
-
Receive reports
Sources contribute observations with identity, status and provenance handled by the application.
-
Build the picture
Correlation and assessment turn reports into a shared view with explicit uncertainty.
-
Authorise a response
Application controls determine who may task an asset and record the resulting transitions.
-
Share the outcome
Browser views and published event interfaces expose the appropriate picture to each consumer.
The development period builds on existing Canopy capabilities and Cerberus-derived concepts. It is a case-study timeline, not a measured comparison with another development stack.
What Canopy supplied.
Interfaces for other teams
REST, WebSocket events, API descriptions, schemas and bounded MCP tools provide independently consumable integration surfaces.
Runtime composition
Communication and object-lifetime mechanisms support the application without putting its operational domain into Canopy’s runtime core.
A protected execution path
The recorded hardware deployment places the regional application inside a non-debug Intel SGX enclave, with independent appraisal before a protected call.
Recorded evidence
Check the workload. Then make the call.
On 21 September 2026, the project recorded an independent client accepting hardware evidence for the expected enclave and signer, confirming non-debug operation, then completing a protected application call through that appraised session.
This establishes a specific measured boundary and checked session. It does not establish the accuracy of incoming observations or continuous service availability.
Three lessons from the demonstrator.
Integration needs usable artifacts
Published contracts and generated interfaces reduce repeated work. Partner data meanings, access policy and adapter testing remain explicit tasks.
AI authority belongs in the application
Read-only advisory interfaces expose a bounded tool set. A separate, explicitly authorised synthetic controller has a different action scope. The external model is outside the attested boundary.
Disclosure is a policy decision
The replication implementation filters events and has in-process duplicate/replay tests. General field redaction, inference prevention and a complete deployed regional exchange are separate claims.
What the next deployment must establish.
The hardware records include availability and admission limits under load. Production identity, upgrade policy, persistent recovery and an independently trusted browser-verification path still require work. The current full regional hardware application is one enclave.
Attestation-gated credential issuance is a proposed integration. The protected direct-client call is evidence for a different path.
Evidence summary reviewed 22 September 2026. This page reports project records, not a fresh live acceptance test.
Bring your own application boundary.
SovereignTEE works with teams to identify which components need isolation, how they should integrate and what evidence a deployment must provide.