qodiqa
SpecificationRun a simulation

Product · Architecture

How a decision becomes evidence.

Follow one request through the execution boundary: verified, decided, recorded and receipted. Every diagram below plays by itself on a loop, and its parts can be selected.

  • 7 stages
  • Plays on a loop · parts can be selected
  • 7 offline checks

1 · The big picture

From request to receipt.

One request, from the application to a receipt that anyone can check, with the AI provider called only when every check has passed.

What happens

The application asks the gateway to sign a permission for one exact request, then sends both together.

More

The gateway checks the artifact, asks the policy engine about consent, writes its intent to the record, and only then calls the provider. The answer comes back with a signed receipt.

Why it matters

A request nobody authorised never reaches a model, and its intent is recorded before the call.

More

If the intent cannot be recorded the call is not made. Most refusals are recorded too, so they leave evidence just as an answer does (the exceptions are listed below).

What you can verify

The receipt names one audit entry and one transparency-log leaf. A verifier can check it on its own machine.

More

A verifier holding the right public keys needs no help from the gateway. Section 6 shows how.

  1. The application asks the gateway to sign a request, then sends the request with the artifact.
  2. The gateway verifies the artifact and asks the policy engine about consent.
  3. On approval the gateway records its intent, calls the AI provider, records the decision and returns the answer with a receipt.
  4. On refusal it records the block and returns the reason; the provider is not called.
  5. A verifier checks the receipt offline with a trusted key.
Technical depth: what is and is not recorded

Requests that fail the input guards, cannot be decoded, or are rejected by the artifact checks (signature, time, key status) are counted but are not written to the audit chain or the transparency log. Rejections from the request-binding check onward are recorded. This is why the "blocked" variants above end differently.

A record proves that the gateway recorded a decision. It does not prove the decision was right, and the operator vouches for the evidence unless an independent witness or anchor is used.

2 · The seven stages

Checks in a fixed order, and a hard stop.

The first check that fails ends the request, writes the reason, and leaves the provider dark: no model call, no partial answer.

What happens

Ingress guards run first, then validation, the artifact check, consent and policy. Only then is the provider called.

More

The artifact is proven genuine, fresh and bound to this exact request. Afterwards the answer is checked and the decision becomes evidence.

Why it matters

The order is enforced: a failed check stops the request. A missing store, an expired artifact or a revoked consent ends in a refusal.

More

An unwritable audit entry also ends in a refusal, never in a silent pass. Choose a failure below and watch the line stop.

What you can verify

Every stage and outcome code here is the one the simulation uses.

More

In the simulation you can run each case with real cryptography, inside your browser.

  1. Ingress, validation, identity and proof, consent and policy, execution, output and evidence, delivery.
  2. The first failing check stops the request with a reason code.
  3. The AI provider is called only in stage 5, and only if stages 1 to 4 passed.
The seven stages, what each checks and the codes returned when it fails
StageWhat is checkedOutcome codes when it fails
Technical depth: how the stages map to the gateway's steps

The seven stages are a way of grouping the steps the gateway documents (input guards, artifact decoding, artifact validation, request binding, nonce registration, burst detection, policy, provider execution, audit write, transparency leaf). The gateway itself does not use the word "stage" for them.

Policies run in the order the tenant configured, and the first denial wins. A refusal is returned as a decision (HTTP 200 by default); the operator can switch to class-based HTTP statuses. An optional content check can sit between policy and provider; it is off in the sandbox and is not drawn here.

3 · The consent artifact

A signed permission for one request.

Five fields, one Ed25519 signature, a fingerprint of the exact request it allows, and a validity that expires within sixty seconds.

What happens

The gateway fingerprints the method, path and body, puts the fingerprint in the artifact and signs it.

More

The signed artifact travels with the request in a header.

Why it matters

Change one byte of the body and the artifact no longer covers the request.

More

The fingerprint no longer matches. Use the artifact twice and the second use is refused. Wait too long and it has expired.

What you can verify

The fingerprint is a plain SHA-256 over a published canonical form. Try it on the right.

More

The values are computed in your browser from the prompt shown, with the same function the simulation uses.

Five fields: expiry, payload, publicKeyId, signature, timestamp. Lifetime at most 60 seconds. Single use. The payload carries a hash of the exact request.

Technical depth: how the hashes are built

envelopeHash = SHA-256("QODIQA::ARTIFACT::V1" || canonical({expiry, payload, publicKeyId, timestamp})), and the signature is Ed25519 over that 32-byte digest.

requestHash = SHA-256("QODIQA::REQUEST::V1" || canonical({body, method, path})). In the first protocol version it binds method, path and body, not headers or the query string; a later version can bind more but is off by default for issuance. Each hash starts with its own label, so a hash made for one purpose cannot be mistaken for another.

4 · The evidence stack

Three layers, each checkable alone.

A hash-linked audit chain, a Merkle transparency log with inclusion proofs, signed checkpoints, and a receipt that points at both.

What happens

Each decision becomes an audit entry that hashes the one before it, and a leaf in a Merkle log.

More

The log's signed root lets anyone prove the leaf is in it. A signed receipt names the entry and the leaf.

Why it matters

Editing an old entry changes its hash, which breaks every link after it.

More

A log can show a leaf is included without showing the other leaves. A signed checkpoint vouches for the head of the chain at a regular position.

What you can verify

Play "Verify", then try the real Merkle proof below. The records hold hashes, never the prompt text.

More

So the evidence can be shared without the content.

  1. Each audit entry stores the hash of the entry before it.
  2. Each entry also becomes a leaf in a Merkle log with a signed root.
  3. Signed checkpoints vouch for the head of the chain; a receipt names one entry and one leaf.

An inclusion proof recomputes the path from one leaf to the signed root using only the sibling hashes.

Technical depth: formats and limits

entry.hash = SHA-256("QODIQA::AUDIT::V1" || sortedJSON(coreFields)); the first entry points at GENESIS. The Merkle log follows RFC 6962 with SHA-256, a 0x00 prefix for leaves and 0x01 for inner nodes. A receipt is {v, requestId, decision, issuedAt, entryHash, leafHash, keyId, signature}.

The audit hash is unkeyed, so on its own it detects accidental or partial edits. Rewriting the whole chain is caught by a signed checkpoint, a signed leaf or an independent anchor, not by the chain alone. The Merkle explorer uses illustrative entry hashes, not real gateway data.

5 · Trust domains and keys

Three key sets, each signing one kind of thing.

Artifact keys, transparency-log keys and checkpoint keys are separate Ed25519 key sets, so a leaked key in one domain gives you nothing in the other two.

What happens

Artifact keys sign consent artifacts, transparency-log keys sign Merkle roots, checkpoint keys sign checkpoints.

More

Each set has its own key file and its own lifecycle: keys can be rotated, deprecated or revoked.

Why it matters

Forging an artifact, a log entry and a checkpoint are three different jobs that need three different keys.

More

There is one algorithm, Ed25519, and no negotiation, so there is no weak option to downgrade to.

What you can verify

The artifact and transparency key sets are published as public key lists you fetch over a channel you trust.

More

Give them to the verifier. Never take them from the evidence you are checking.

  1. Artifact keys sign consent artifacts.
  2. Transparency-log keys sign the roots of the Merkle log; receipts are checked against this key set.
  3. Checkpoint keys sign audit checkpoints.
Technical depth: what separation does and does not give

Separate domains limit what one stolen key can do. They do not remove the operator from the trust path: unless an independent witness or an external anchor is used, the operator who runs the gateway vouches for all three. Verification is circular if the keys and the evidence come from the same instance.

6 · Offline verification

A receipt and a trusted key are enough.

The verifier reads two files, runs seven checks in order, and answers VALID or INVALID. It makes no network call and imports nothing from the gateway.

What happens

The verifier checks the receipt's shape, version and fields, then the signing key, the signature and the key's status.

More

The key must be in the set you trust, and the signature is Ed25519. The first failure wins and names its reason.

Why it matters

You do not have to trust the gateway's code to check its receipt.

More

A tampered decision, an unknown key or a revoked key each fail in a different, named way.

What you can verify

A valid receipt says a trusted key signed a record of one decision for one request.

More

It does not say the decision was right, or that the keys you trusted were the right ones. Try the same check in the verifier.

  1. Inputs: the receipt and the public keys you trust, obtained separately.
  2. Seven checks run in order; the first failure returns its reason code.
  3. If all pass the verdict is VALID. No network is used.
The receipt checks in order and the reason returned on failure
CheckWhat is testedReason on failure
Technical depth: run the public verifier

The public verifier repository includes recorded sessions you can check without a gateway. Exit code 0 means valid, 1 means invalid.

Terminal
node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json
# exit 0 = VALID

Verifier README

7 · Streaming and agents

The same checks, with the differences stated.

Streamed answers and agent tool calls pass through the same front-door checks. What changes after that is shown here.

Streaming

The five request checks run before the stream opens; a failed check returns a plain refusal and no stream.

More

When output inspection is on, the answer is held in a small buffer, checked, and only then released to the client, window by window.

Agents and tools

Each tool call needs its own action artifact, bound to the exact call, and goes only to registered servers.

More

A delegation can hand on only a subset of its own rights. Tools that need it require a human approval tied to that exact action.

What you can verify

Both paths leave evidence: for streams, that the request was authorised and how many bytes were sent.

More

The audit record does not hold the streamed text. For tool calls, the gateway records intent and commit entries for the action.

Streaming: check, then release

  1. The five request checks run before any stream header is sent.
  2. Provider text is held in a bounded buffer, checked, then released.
  3. A final check on the whole answer can record a block but cannot recall text already sent.

Agents: one artifact per action

  1. Each action needs its own artifact, bound to the exact call.
  2. Delegation only narrows rights; irreversible tools need a human approval.
  3. The gateway calls only registered servers and screens what comes back.

Delegation only narrows

  • A root grant gives a subset of the issuer's rights; each child gets a subset of its parent's.
  • Action classes, tools, the action count and the lifetime can only stay equal or shrink.
  • The depth of a chain is bounded and no agent can appear twice.

Delegation tokens and chains in the public repository define the checks shown above.

Related documents

Cover of the Technical Overview, QODIQA-TO-1.0: the gateway, in engineering terms.

Technical Overview

The gateway in engineering terms: architecture, request lifecycle, cryptographic artifacts, evidence and verification.

PDF · 24 pages · 1.3 MB · QODIQA-TO-1.0 · v1.0

Download PDF

All documents