Skip to content
Verifiable Claims 2.1.1Point-in-timeBilateral

Decide whether to rely on one bounded claim.

The operator says what is claimed and where the boundary is. A source supplies the evidence. You, the recipient, choose whose keys you trust, verify the exact Case, and then accept, reject, or ask to inspect.

Design partnerBrowser-local sampleNo account or upload
CASE 01
Claim under review

No record in June governed order population had trade state equal to restricted.

In plain terms: no order in the June population was in a restricted state. The formal sentence above is what was signed; this line is a reading of it.

meridian-june-booked-orders · Jun 01, 2026, 12:00 AM UTC to Jun 30, 2026, 11:59 PM UTC

Accepted for this caseThe pinned recipient accepted this exact report, purpose, population, period, and evidence window.
Independent result

Three separate questions

Reliance accepted
Cryptographically valid
Yes
Do all six signed artifacts match their canonical bytes and pinned keys?
Trusted under policy
Yes
Do source authority, active keys, modules, bindings, coverage, and time satisfy this recipient’s policy?
Accepted by recipient
Yes
Did the recipient sign an accept decision for this exact report and purpose?
Bound result

The evidence supports the claim.

satisfied
Population14 administrator-booked eventsClosed by source signed total
Source assurancesource signedExample Fund Administrator signed report
CoveragecompletePopulation and period both closed
Evidence disclosedState onlyPositions, quantities, prices, and source report remain sealed
This answers only the signed question.It does not establish current compliance, future behavior, undeclared routes, or the truth of a source beyond the authority and assurance class the recipient agreed to accept.
Recipient decision

Make one explicit reliance decision.

Each button signs a new sample decision at the pinned sample time with the browser demo key. It changes reliance, not the objective evidence result.

Valid at Jul 16, 2026, 12:01 PM UTC
Decisionaccept
RecipientExample Allocator
Report893694c5d7f…f343f51
Decision receipt1b1f3df2bc5…dc32159
Prove itTen local checks, exact artifact digests, and tamper test
Point-in-time workspace
One bounded bilateral case is present. No live status or continuing authorization is created.
Pass
Exact schemas
All six artifacts are validated against the frozen v2.1.1 schemas; malformed or downgraded input fails closed.
Pass
Canonical bytes and signatures
Raw RFC 8785 JCS bytes and Ed25519 signatures verify using transported public keys. Those keys are not trusted merely because they travel with the case.
Pass
Exact companion bindings
The report and decision bind the exact contract, policy, snapshot, manifest, and report digests.
Pass
Normalized evidence commitment
Every normalized evidence field, replay descriptor, value, and closure field reproduces the report commitment and result.
Pass
Conformance and downgrade protection
Required C0, C1, and C2a modules are negotiated at exactly 2.1.1 and bound to the signed implementation digest.
Pass
Verification result
The full signed report payload is reproduced by the shared production kernel from the supplied evidence and policy.
Pass
Recipient-owned trust anchors
The case matches recipient policy and key fingerprints supplied outside the portable case.
Pass
Historical decision window
Companion artifacts were current at the signed recipient decision time. This says nothing about current or future status.
Pass
Recipient decision semantics
The signed decision acknowledges the exact result, purpose, inspection classes, and any required exception.
Pass
Claim Contractd56e6913fe469763eee5df68dff59ef65eb129790602555477abc0d66ab7aab4
Trust Policye8dbcff45e887c0ef138c7dfd97218c56c55b2df6dea73511fd5376ea824bffa
Trust Snapshot407612c8fa5dff4a9fd55cc7b3d73b97fd8771c189a6da25b9a1a45bf952333e
Conformance Manifest3cd1b5c94cef61269b88df628811130be7d5c2d73a999a96eadd0c55754392c1
Verification Report893694c5d7f2b569f2c1e69d6086a28b0664c8cc4c493502a2957aa74f343f51
Recipient Decision1b1f3df2bc56616003cfda329888e7709a21d4d75e18c44069c25ba39dc32159
Limits and migrationWhat remains compatible and what fails closed

This is a point-in-time bilateral Assurance Case over the signed boundary and evidence window, not standing assurance.

Cryptographic validity does not establish source truth beyond the admitted issuer authority and source assurance.

The report does not establish that undeclared or bypass routes were governed.

This verifies one point-in-time bilateral Assurance Case. It is not standing assurance.

The evidence candidate records the verifier-normalized result and source-assurance class. This portable sample does not embed a source-native report signature.

Cryptographic validity is not trust. Trust requires out-of-band recipient pins. Acceptance exists only in the recipient-signed decision.

Existing v1 claims, reports, and reliance bundles remain verifiable under their original semantics. They are never relabeled as v2.1.1 artifacts. A v1 case must be recompiled, rebound, and freshly signed before it can receive a v2.1.1 recipient decision.

Use npx @veritasacta/verify <artifact.json> --mode claims --key <hex> for one portable artifact. A complete acceptance decision requires this exact companion set.

Apply it to your workflow

Run one read-only Assurance Case with your evidence and your recipient.

Two weeks. One bounded claim. Customer-controlled keys and storage. No standing authorization.

See the plans