Skip to main content
Both operations answer 501 not_configured. There is no attestations table. This matters more than most refusals on this surface, because required_attestations appears as an empty array on every card returned by the board — and an empty array reads as “nothing is required”.
501
GET /v1/attestation-parity names one further dependency: parity is declared claims against covered claims, and the declared set comes from the compiled manifest, which has no storage either.

What an attestation is

A per-(claim, attester) record answering one question with three possible answers: pass, fail, or absent. The third is the reason a single evidence blob cannot stand in for it — a blob can tell you a check ran, but not that a required check did not.

What exists instead today

tasks_mirror.verification_evidence — one JSONB column on a card. It carries whatever the completion path put there. It is why a card can be done and verified, and why a card whose claim could not be adjudicated lands in the unverified column with unverified_because set. That column supports the board’s two computable diagnostics (stranded and unverified) and nothing more.

Reading required_attestations correctly

Every card from the board carries:
Do not render this as “no attestations required”. The pairing of an empty array with an *_unavailable_because sibling is the surface’s convention for we cannot tell you. If your UI shows a checklist, show it as unavailable rather than as complete.