Skip to main content
[AVAILABLE], precisely scoped. packages/runtime/src/services/verification-service.ts. CLAIMS.md 2.15.
An earlier six-stage verification pipeline (@parmana/verification) existed and was deleted (“retired in Session 5 — it had no real implementation and no real test coverage,” per CLAIMS.md §4). It is not documented here as existing. If you see references to Authority/Intent/Evidence verification stages elsewhere, they describe that retired package or a not-yet-built future addition — not current behavior.

​
The 3 checks, exactly

// packages/runtime/src/services/verification-service.ts:90-153
  1. Integrity — recompute the Trust Record’s canonical hash; must match the stored trustRecordHash.
  2. Signature — the stored cryptographic signature must verify against the stored public key.
  3. Authorization binding — every APPROVED execution must carry a non-empty authorizationId in its metadata. REJECTED-decision executions are exempt.
All three checks always run, independently, regardless of whether an earlier one failed — so a single verification report can name every check that failed, not just the first (runChecks() accumulates failures into an array rather than short-circuiting).

​
Two different operations, two different routes

SDK callHTTPWhat it does
client.verification.verify(id)POST /verifyRuns a fresh verification; appends a new Verification to the record’s history
client.verification.get_latest(id)GET /verification/:idReads back the most recent Verification without re-verifying
These are genuinely different routes (packages/api/src/routes/verify.ts vs. verify-get.ts), not the same endpoint called twice — a distinction the Python SDK only got right this session (see Python SDK).

​
Real output

client.verification.verify() -- fresh (POST /verify):
  status:      VerificationStatus.VERIFIED
  verified_at: 2026-07-06 04:10:15.021000+00:00
  hash:        861fe01aaadf904a003d3e6118e74f967164a52d91eb18f97ca6cbce71292768

client.verification.get_latest() -- cached (GET /verification/:id):
  status:      VerificationStatus.VERIFIED
  verified_at: 2026-07-06 04:10:15.021000+00:00
  hash:        861fe01aaadf904a003d3e6118e74f967164a52d91eb18f97ca6cbce71292768
Real run, 2026-07-06, python/examples/verify/.

​
Tampering is actually caught

packages/api/test/verification-negative.integration.test.ts — “reports FAILED when the persisted record is tampered after execution” — proves this end to end, not just at the unit level.