# Enrichment Source Registry V01

Issue: #412

Parent: #411

## Purpose

This artifact defines the deterministic enrichment-source registry schema, source-pack taxonomy, seed catalog, and safety validation posture for future source-grounded assistant enrichment work.

This is field guidance and repo-control metadata, not policy.

The registry is static package-adjacent governance evidence. It is not runtime source configuration, not Preview source-set configuration, not Production source-set configuration, not external retrieval, not arbitrary web search, not browser-side source retrieval, not browser-side provider behavior, and not package authority.

## Registry Artifact

The static registry artifact is `docs/product-architecture/enrichment_source_registry_v01.json`.

The registry records:

- required source-entry fields
- source-pack taxonomy
- deterministic enum values
- global default policy
- profile-triggered source seeds
- product-triggered and user-selectable vendor/provider seeds
- license and lifecycle gates
- package-authority, browser-fetch, provider-call, user-mutability, and marketing boundaries

## Source-Pack Taxonomy

The required source packs are:

- `core_ai_capability`
- `ai_security`
- `ai_governance`
- `gxp_regulated_life_sciences`
- `medical_device_samd`
- `ot_endpoint_infrastructure`
- `foundation_model_providers`
- `agent_rag_engineering`
- `independent_evidence`
- `vendor_product_docs`

Only `core_ai_capability` may contain globally default-selected sources.

## Global Default Policy

Only these four core NIST sources are global defaults:

- NIST AI RMF 1.0
- NIST AI 600-1 Generative AI Profile
- NIST CSF 2.0
- NIST SP 800-218 SSDF

Global default selection does not make any enrichment source package authority.

## Provider And Vendor Rule

Provider and vendor sources are product-triggered, profile-triggered, or user-selected only.

Provider and vendor sources may be highest authority for their own product behavior and strong self-report for their own system cards, model cards, safety policies, release notes, and product-specific implementation guidance.

Provider and vendor sources are not package authority, compliance authority, regulatory proof, or neutral cross-vendor best practice unless supported by stronger independent sources.

## Licensed And Draft Source Rule

Licensed standards, rights-controlled sources, draft sources, preview-only sources, unavailable sources, deprecated sources, and retired sources cannot be default-selected.

ISO, IEC, ISPE, ISA/IEC, and CIS entries remain metadata-only, licensed-excerpt-required, rights-controlled, preview-only, licensed-required, unavailable, or admin-gated unless rights are cleared in a later owner-approved issue.

Draft sources are marked `lifecycle_status: "draft"` and `status: "preview_only"` or otherwise prevented from answer generation.

## Validation Scope

`validation/scripts/check_enrichment_source_registry.py` validates the registry deterministically.

The validator checks required fields, unique source IDs, enum values, default policy, source-pack boundaries, licensed-source gating, draft-source gating, no package-authority promotion, no browser fetch, no provider calls, no user registry mutability, no invalid default selection, no vendor global defaults, no marketing authority, and passing/failing fixtures.

## Boundary Confirmations

- No runtime provider or model behavior is changed.
- No external fetching is added.
- No arbitrary web search is added.
- No browser-side source retrieval is added.
- No browser-side provider call is added.
- No approved package authority is changed.
- No Preview source set is changed.
- No Production source set is changed.
- No full text of licensed standards is ingested.
- No unofficial mirror is used for ISO, IEC, ISPE, ASTM, ISA/IEC, or CIS content.
- No user-pasted session source is persisted.
- #78 is not mutated.
- #271 is not reopened.
- #414, #415, #416, #417, #418, and #419 are not implemented.
- `codex-automerge` must not be applied.

## Next Owner Decision

After this registry and validator slice lands, future issues can decide whether to build a request model, UX, telemetry, admin request workflow, retrieval workflow, or provider integration. Those future issues must preserve package-authority and source-set gates until explicitly approved.