← Documentation home

Canonical Markdown source · Oct 20, 2018

AI agent evidence registry — technical recommendation

technical-recommendations/ai-agent-evidence-registry-2026-08-25.md · 39 lines · SHA-256 cb1065f231eb

Impact summary

`ai-agent-evidence-registry.ts` is now the versioned leaf contract for the six

model-readiness surfaces. It centralizes provider, assignment, review, retirement,

source-receipt, configuration-key, verification-kind, and trial-command metadata.

Readiness, its verification CLI, and audit machine-scorecard projection resolve

canonical paths from this registry. Provider parsers remain strict and unchanged;

the canonical replay still reports four provider-evidence surfaces, two prepared

review assignments, two retired behaviors, and zero proven advantages.

Ranked coupling and failure findings

  1. High — verification dispatch remains procedural: canonical metadata is now

singular, but the CLI still contains a branch per receipt family and can drift

when a new verification kind is introduced.

  1. High — external human evidence remains absent: cleaner routing improves

maintainability but cannot resolve Calliope or Clio quality and effort gates.

  1. Medium — registration validity is test-time enforced: duplicate paths and

missing metadata are covered in tests, not parsed from an external schema at

process startup.

Actions

| Owner | Action and acceptance criteria | Validation |

|---|---|---|

| AI Reliability | Replace procedural CLI branches with an exhaustive verifier map keyed by `verificationKind`; every non-`none` registration must have exactly one verifier | Add compile-time and runtime completeness tests, then run readiness replay |

| AI Evaluation | Import two genuine timed reviewer responses for each prepared Calliope and Clio packet | Aggregate exact packet/key-bound responses and require all registered gates |

| Search/Relevance | Configure governed Voyage or SigLIP infrastructure only after privacy/rights authorization; registry presence must never imply provider readiness | Readiness remains `configure-provider` until configuration plus verified receipt exist |

| Maintainers | Keep the registry a leaf module with no parser, filesystem, environment, or provider imports | Boundary test plus `pnpm exec tsc --noEmit --pretty false` |

Next-cycle hypothesis

An exhaustive verifier map can make every registered verification kind fail closed

without procedural path branches or loss of the current readiness result. Falsify

by adding an unhandled verification kind or mutating a receipt; compilation/tests

must fail or the affected surface must lose evidence credit.