Overview
Every call toPOST /verify records a verification result in audit_verifications. This creates a persistent record that an attestation was verified, when it was verified, and whether it was valid.
Verification record fields
| Column | Type | Description |
|---|---|---|
execution_fingerprint | string | Links to the audit_decisions record |
execution_id | string | The executionId from the attestation |
valid | boolean | Whether verification passed |
signature_verified | "verified" | "failed" | "unknown" | Ed25519 signature check result |
runtime_verified | "verified" | "failed" | "unknown" | Runtime identity check result |
schema_compatible | "verified" | "failed" | "unknown" | Schema version compatibility |
verified_at | string | ISO 8601 timestamp of verification |
Verification status on decision rows
The decision list (GET /audit/decisions) includes verification fields on each DecisionRow:
Querying unverified decisions
Decisions where verification has not been run yet showverification_valid: null and verified_at: null.
Verification statistics
invalid_verifications count warrants immediate investigation — it means one or more attestations failed signature verification after being produced.
Troubleshooting
verification_valid: null for all decisions — Verification records are only created when POST /verify is called. Decide whether to verify immediately after each execution (recommended) or in a batch process.
invalid_verifications > 0 — At least one verification failed. Check the audit_verifications table directly for the failing records. Retrieve the full attestation and re-run verification to confirm. Investigate whether the attestation was tampered with or whether a key rotation caused the failure.
Verification shows runtime_verified: "failed" — The attestation was produced by a different runtime version than the one performing verification. This is expected when the runtime is updated. Store historical public keys and use the correct one for the attestation’s signerKeyId.