Four pieces of software, an evidence specification and the help to fit them to a service you already run. Together they answer three questions about any message: who asked for this, what did it rely on, and what was measured while it ran.
Digital Name / CorpID patterns and request-signing tools connect an instruction to its principal, delegated scope and validity window.
The organization defines authority; government adoption maps this to the agency’s own mandate and credentials.
Source services and adapters retain source references, data versions and the quality checks the workflow requires. Origin is one working prepared-data service.
A hash, a publisher signature and a quality test are distinct evidence. Each keeps its own meaning.
Integration software binds a request and its result to available measurements from the agreed application and infrastructure. It signs the resulting evidence.
The deployment states exactly which layers are measured, by whom, and for how long.
Signatures cover the content and context of the exchange. Request binding, validity windows and replay controls make the message independently checkable.
The selected profile defines what is covered and which checks the recipient must enforce.
Preserve the record, authority history and evidence needed to verify an exchange later, with access and disclosure under the owner’s control.
Retention, encryption, recovery and any public anchoring are agreed for the deployment.
Verification software checks signatures, request binding, evidence scope and freshness against the recipient’s acceptance policy before the next action.
The customer determines the policy, exceptions and accountable decision-maker.
Binder sits at the agreed service boundary. It receives or references the signed request, consumes measurements and assertions from the selected stack, and binds them to the signed output.
A deployment may begin with a signed service response and measured boot. Application, model and confidential-compute evidence are additional integrations with their own acceptance criteria.
What is demonstrated today| Responsibility | Role in the delivery |
|---|---|
| Customer or public authority | Owns the service rules, authorization policy, records and decisions. Defines who may act and what evidence is sufficient. |
| Rootz | Provides the message-security components, Binder integration, verification tooling and evidence specifications for the agreed workflow. |
| Data-center operator | Runs the agreed hosting and key infrastructure, supplies available measurements, and owns operational support within its contract. |
| Microlink and delivery partners | Bring infrastructure and application integration into the customer program. Project scope names the implementation and support responsibilities. |
| Application provider | Supplies the licensing, permitting, registry or AI business application and its interfaces. |
The integration defines the message format, authority roots, required data checks, measurement sources, validity windows and failure handling. This is the common specification the producing and consuming systems implement.
Business applications, models and infrastructure can vary. The recipient still needs to understand what the evidence means and apply its own policy.
The scoping session produces a delivery boundary, integration dependencies and acceptance criteria.
Start with the workflow