> ## Documentation Index
> Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Verification

> Exactly 3 checks, always run, always reported independently.

<Info>**\[AVAILABLE]**, precisely scoped. `packages/runtime/src/services/verification-service.ts`. CLAIMS.md 2.15.</Info>

<Warning>
  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.
</Warning>

## The 3 checks, exactly

```typescript theme={null}
// 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 call                             | HTTP                    | What it does                                                                        |
| ------------------------------------ | ----------------------- | ----------------------------------------------------------------------------------- |
| `client.verification.verify(id)`     | `POST /verify`          | Runs a **fresh** verification; appends a new `Verification` to the record's history |
| `client.verification.get_latest(id)` | `GET /verification/:id` | Reads 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](/sdks/python)).

## 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.