How the registry decides what it knows

The registry optimizes for one question: can an agent act on this record without guessing? Four pillars answer it. Attested: every decision-relevant field names its source, its recorder, and when it was observed — or explicitly says it cannot. Relevant: verification attaches to the exact digest of the claim it supports, so editing a value invalidates its attestations. Fresh: capture, verification, effective, and publication times are separate, visible fields. Structured: the data follows a strict schema, and unknown is a first-class, displayable state.

Every record carries a source category: live execution, official documentation, vendor publication, community observation, synthetic fixture, or import. Each carries recorder, observed time, method, and reference where available.

Absences are displayed, not hidden. 'Source not supplied' means a field exists but nobody recorded where it came from. 'Nobody has verified this claim' means attestations exist (or don't) but none has been checked by a verifier your policy trusts. Imported records prove only that an external catalog was parsed — never that the vendor's claims are true. Synthetic fixtures exist for demonstrations and say so everywhere they appear.

A model is an identity, not an endpoint. Identifiers are immutable and kind-scoped: model:namespace/name@revision. Revisions are immutable; claims of mutability come with evidence for that classification.

Colloquial names are recorded as explicit alias claims with pinned target identities, never silently resolved. The four pin strengths — artifact digest, immutable artifact, provider release, mutable alias — have a declared total order, and your policy sets a minimum. An unversioned or fuzzy name is insufficient evidence by itself.

A gateway binding is a concrete serving relationship to a model revision. A compatibility assertion is a record between a harness and a model: supported, conditional, unsupported, or unknown, with the adapter configuration that makes it work and the evidence behind the claim. Claims are addressed by digest and verified by attestations that name a verifier, a verification time, and the exact claim digests they cover.

Contradictory claims are never silently resolved. The registry reports the conflict and refuses; a human resolves it.

The resolver is a local, deterministic evaluation engine. Given a snapshot and your policy, it returns exactly one route — harness + gateway + model, with bindings, configuration, evidence references, and a step-by-step trace — or a typed refusal with a reason you can act on. Ties refuse. Missing evidence refuses (in a strict posture) or proceeds with warnings (in a permissive one). The same inputs always produce the same result digest.

The decision boundary is deliberate: the catalog collects, structures, verifies, and reports facts and possibilities. The policy engine makes choices — but only from a policy a human wrote and explicitly accepted. There is no built-in default order and no hidden ranking. The registry never guesses.

Phase 0 — Importer: parse an existing model catalog into labeled Imported records. Done and demonstrated in the workbench.

Phase 1 — Local deterministic resolver: contracts, fixtures, this browser workbench, Node and plain-JavaScript consumers. This beta is Phase 1.

Phase 2 — Catalog: authenticated contribution, review, publication, a public mirror, and a feedback channel. Phase 3 — layered sidecar snapshots. Phase 4 — service methods inspectService and checkService. These ship later; the contracts reserve them and the resolver refuses them with UNSUPPORTED_FEATURE rather than guessing.

Catalog data is CC0 1.0. Code is MIT. Signed envelopes and trust infrastructure arrive with the published catalog; this beta snapshot is unsigned and marked as such.