Architecture & verification

Follow the request. Check the result.

Two parties agree what has to be true about a message. Rootz binds that evidence to the message itself and gives the recipient a way to test it in the moment. Walk the whole path below, from instruction to verified result.

Rootz components connect a signed request, service measurements and a result to recipient verification.

The exchange, end to end

  1. Sign the instruction

    The requester signs the content and context: intended service, action, validity window and a unique request value. The service checks the relevant authority.

  2. Establish the inputs and conditions

    The workflow records the source evidence and quality checks it needs. Binder consumes the available measurements from the agreed stack.

  3. Bind and sign the result

    The result commits to the request and evidence. Changes to covered content can be detected by a recipient.

  4. Verify before proceeding

    The recipient checks signatures, request binding, freshness, status and the evidence its policy requires.

  5. Preserve the evidence

    Retain the records and verification material needed for review, recovery and later checks under the agreed retention policy.

Change the message. Watch the checks change.

A local cryptographic illustration using fictional permit data and keys generated in this browser. It demonstrates signatures and request binding; it has no government issuer or hardware attestation.

Illustrative message
Preparing the signed example…
Recipient checks

Preparing verification…

Each scenario runs Web Crypto verification in your browser. A production profile also checks the real issuer’s authority, evidence quality, status and measured process scope.

Evidence has a scope and a lifetime

EvidenceWhat it establishesWhat must remain explicit
Content signatureIntegrity of the covered bytes and possession of the signing keyIssuer authority, key history and the signed context
Source reference or hashA retrievable source or a commitment to specific contentWhether the source signed it, its version and retrieval time
Quality checkThe result of a stated test on stated dataMethod, coverage, threshold and applicability to the task
Process measurementThe covered state reported by a measurement sourceWhich layers, evidence chain, baseline and measurement time
Status evidenceThe status reported for a defined record or authorityThe authoritative source, freshness and coverage

Security follows the message; privacy needs its own design.

Signatures make covered content and context checkable. Encryption, access controls and disclosure policy govern who can read the record. Agree both in the deployment.

Verification material needed later must survive key rotation and certificate expiry. Capture the relevant historical evidence, and define the difference between a current permission check and verification of a past record.

Use your own workflow as the next example.

Bring a real request, a representative response and the conditions a recipient needs to verify.

Plan a technical workshop