Touchstone

Products · Control Language

The unit of verification

A control is a machine-checkable claim compiled from the issuer's own words. It names its subject, cites the exact bytes it came from, and states a predicate an engine can evaluate without judgment. A model proposes; a human approves or declines under signature; the engine evaluates. Below is a control from the approved set, dissected.

Anatomy

Every field, and why it is there

This control is one of the 9 in the current approved set. Its fields are the complete instruction the evaluator follows — there is no other configuration, and nothing about it is interpreted at run time.

ustb-nav-daily-freshness

APPROVED
Subject
Superstate USTB daily NAV feed publishes a NAV row dated within the last two business days
One sentence stating what is checked, in language a risk officer can argue with. Written by the compiler, approved by a human.
Cited span
The byte-exact quotation from the issuer's own document that the compiler drew this control from
Compile-time evidence, not this epoch's observation. It travels verbatim inside the control record in every verification bundle, so the claim can always be traced back to the sentence that produced it.
Source
superstate-ustb-nav-daily · issuer-api
Where evidence comes from, and what kind of authority it is. An issuer API proves publication, not truth, and the authority class is recorded so nobody has to guess which was meant.
Adapter
ustb-nav-daily
The deterministic code path that retrieves and normalises evidence for this control. Same bytes in, same observation out.
Operator
fresh_within
The comparison the evaluator applies. The operator set is small and fixed; a control cannot smuggle in new semantics.
Expected value
2 business days
What the operator compares against — here the issuer's own declared publication policy, not a threshold Touchstone invented.
Cadence
business-daily, with a recorded grace period
How often evidence is expected, and how many periods may lapse before absence counts against the asset rather than being treated as noise.
Effective period
In force from a recorded date, with no end date set
A control applies to observations inside its effective period only. Retiring one means ending it, not deleting it — so an old report stays readable against the rules it was actually judged under.
Approval state
approved, EIP-712 signed by 0x537873b087654395CB0A487B50d0bFBe15fA16Bc
Approval changes exactly two fields — the approval state and the compilation digest. Nothing else about a control can be edited by a human, which is why a bad proposal has to be declined rather than repaired.
Content hash
SHA-256 over the control's canonical bytes
The signed report references the control by this hash. Change one byte of the control and the hash changes, so no report can silently point at a different rule than the one it names.
Compilation
The artifact the control was accepted in
The control is read from that artifact; the approval ledger can only point at it, never restate it. The artifact also carries the model, prompt and provider-response digests behind the proposal.

Pipeline

From proposal to published verdict

  1. Proposed

    A model reads the issuer's published documents and proposes candidate controls. Each cites the exact bytes it was drawn from and carries the compiler's own confidence, alongside the prompt and response digests that produced it.

  2. Gated

    Deterministic checks screen every candidate before a human sees it. A candidate below the confidence floor is abstained from — recorded in the compilation artifact, never shown as approvable.

  3. Approved or declined, under signature

    A human decides each surviving candidate. Approval may change only the approval state and the compilation digest. Since ledger version 2 every decision — approvals and declines alike — carries the approver's EIP-712 signature over the exact proposal it decides, so the identity behind the human boundary is recoverable by anyone holding the bytes.

  4. Evaluated

    Each epoch the engine retrieves fresh evidence and evaluates every approved control in force. A control the evidence cannot answer is reported unevaluable, not skipped — an abstention is a result, and it is what keeps a thin evidence day from reading as a clean one.

  5. Published

    Results are bound into a report by content hash, control-set root and evidence root, signed with Ed25519, and published to the registries on X Layer mainnet and testnet — where a gate can act on them.

The approval ledger

What was turned down is part of the record

9

controls approved and in force

7

candidates declined, with reasons

100%

of decisions carry the approver's signature

A control set that silently omits what a human turned down cannot be audited for why. So the ledger keeps both, and the declines are the more revealing half: most of them are not invalid candidates at all.

ustb-outstanding-shares-present

Declined

“Compiler confidence is 0.80 against a gate of < 0.80, so it clears by zero margin. That is not a deterministic invalidity and the candidate is well formed, but zero margin is not the evidence quality a first approved set should rest on when ustb-nav-per-share-present already covers the NAV value claim.”

ustb-yield-seven-day-present

Declined

“Valid, but a third presence check on the same yield document is additional scalar coverage rather than breadth. ustb-yield-one-day-present is the representative field; approving all three would present duplication as product scope.”

Reasons are quoted from the approval ledger itself, which is published inside every verification bundle and hashed into every signed report. The current ledger digest is b2d8ab788a0ac43b18d0438ba50daf7e3a098003ea0650d8561c0cbb475f5c91, and the decisions in it were signed on 2026-08-19 — dated when the signatures were made, never backdated to the decisions they attest.

See the controls as evaluated Check the ledger yourself