# Enrichment Source Expansion Review V01 Issue: #419 Parent: #411 Depends on: #412, #413, #414, #415, #416, #417, #418 ## Purpose And Non-Implementation Boundary This artifact defines the candidate-review and backlog-control lane for future enrichment-source catalog expansion. #419 is a non-implementation review lane. It does not add active sources, source candidates, source fetching, source discovery, source promotion, runtime behavior, browser behavior, provider behavior, package authority, or approved package source-set changes. Candidate review is not source approval. Candidate approval requires a future owner-approved implementation issue, registry update, validation coverage, and receipt. No candidate becomes an active source by appearing in this review artifact. No candidate becomes a default source by appearing in this review artifact. This artifact records the model, template, lifecycle, principles, and follow-up requirements that a future child issue must satisfy before any candidate can enter `docs/product-architecture/enrichment_source_registry_v01.json`. ## Candidate Classes To Evaluate Future review lanes may evaluate these generic candidate classes only after a bounded child issue defines the candidate scope: - Additional foundation model providers. - Additional official vendor docs. - Additional regulator guidance. - Additional AI safety benchmarks. - Additional incident databases. - Additional agent/RAG engineering references. - Additional GxP and medical device guidance. - Additional OT and infrastructure references. - Additional independent expert resources. This class list is not a candidate inventory. It does not identify, approve, fetch, rank, or promote any named source. ## Required Review Field Template Every future candidate source must be reviewed with this field template before it can be proposed for a later registry update: | Review field | Required review posture | | --- | --- | | `source ID proposal` | Proposed identifier only. It is not active until a future owner-approved registry update lands. | | `display name` | Human-readable source name for review. It is not source approval. | | `source pack` | Must align to an existing source pack from the governed registry taxonomy. | | `authority class` | Must classify the source authority type without overstating compliance, product, or evidence authority. | | `source role` | Must describe the source's role, such as obligation, guidance, framework, implementation reference, product behavior, or evidence context. | | `trust ceiling` | Must state the maximum authority the source can support. | | `activation policy` | Expected to remain unavailable, admin-gated, product-triggered, profile-triggered, or user-selected until a later issue approves otherwise. | | `default policy` | Expected `not_default` unless a future owner-approved issue explicitly authorizes a default change. | | `status` | Must use a candidate-review lifecycle status, not an active registry status. | | `lifecycle status` | Must record final, draft, superseded, preview-only, unavailable, deprecated, retired, unknown, or equivalent review posture. | | `jurisdiction` | Must record applicable jurisdiction or `not_jurisdiction_specific`. | | `version label` | Must record the reviewed version, edition, date label, or `not_versioned`. | | `license mode` | Must record public, metadata-only, licensed excerpt required, rights-cleared controlled excerpt, or rights review needed. | | `retrieval mode` | Must remain static metadata, not retrievable, licensed or rights gated, or owner-approved runtime profile required until later approval. | | `browser-fetch allowance` | Expected false. | | `provider-call allowance` | Expected false. | | `package-authority flag` | Expected false. | | `registry mutability by user` | Expected false. | | `owner approval requirement` | Expected true. | | `marketing-page exclusion` | Expected true unless a future owner-approved issue explicitly allows tightly scoped metadata use. | | `useful-for notes` | Must describe narrow useful contexts without implying approval or default use. | | `not-useful-for notes` | Must describe prohibited or misleading uses. | The template is a review checklist, not a registry schema migration. A future issue may propose concrete registry fields only after owner approval. ## Candidate Lifecycle And Status Model Candidate-review status values are: - `candidate_identified` - `needs_rights_review` - `needs_owner_review` - `rejected` - `deferred` - `approved_for_future_child_issue` These statuses do not imply active registry inclusion. They do not imply source approval, default approval, retrieval approval, package-authority approval, provider-call approval, browser-fetch approval, or source-set approval. `approved_for_future_child_issue` means only that a future owner-approved implementation issue may be drafted. It does not authorize a registry mutation by itself. Do not use `active_default`, `active_available`, `profile_default`, or any other status that implies active registry inclusion in this candidate-review artifact. ## Candidate Source Principles - Broad catalog is allowed. - Narrow defaults remain mandatory. - New sources must be source-role and artifact-type classified. - Official vendor docs are highest authority for their own product behavior only. - Vendor system cards and safety policies are provider self-report, not independent proof. - Independent evidence sources are evidence context, not normative authority. - Licensed standards require metadata-only, licensed excerpt, or rights-cleared handling. - Draft sources must remain preview-only unless owner-approved later. - Marketing pages are excluded unless a future owner-approved issue explicitly allows tightly scoped metadata use. - No candidate becomes an active source by appearing in this review artifact. - No candidate becomes a default source by appearing in this review artifact. ## Source-Pack Alignment Rules Future candidate review must align every source to the #412 registry source-pack taxonomy: - `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, and #419 does not authorize any default change. If a candidate does not fit an existing source pack, the future issue must request owner review for taxonomy handling before any registry update. It must not create an implicit source pack, hidden default, or runtime branch. ## Vendor And Provider Boundary Rules Official vendor documentation can be authoritative for that vendor's own product behavior only. Vendor system cards, model cards, safety policies, release notes, and product claims are provider self-report. They are not independent proof, not compliance authority, not package authority, not market-wide best-practice proof, and not owner validation for internal-source claims. Foundation model provider material must remain product-triggered, profile-triggered, user-selected, admin-gated, or unavailable unless a future owner-approved issue authorizes narrower handling. Vendor/provider sources must not be used to claim regulatory compliance, certification, conformance, independent empirical proof, neutral industry proof, package approval, enterprise tool approval, workflow approval, data-class approval, or production approval. ## Licensed And Rights-Controlled Source Handling Licensed standards and rights-controlled sources require rights review before any full-text, excerpt, or retrieval handling. Permitted review outcomes for rights-controlled material are metadata-only, licensed excerpt required, rights-cleared controlled excerpt, deferred, or rejected. Do not ingest licensed full text without rights clearance. Do not use unofficial mirrors for rights-controlled standards. Do not treat a public landing page, catalog page, table of contents, or marketing page as a substitute for rights-cleared source content. ## Draft, Preview, Deprecated, And Unavailable Handling Draft sources must remain preview-only unless owner-approved later. Preview-only, deprecated, retired, unavailable, superseded, or unknown-lifecycle sources must not become global defaults, active registry entries, package authority, or production retrieval sources through #419. A future issue must record the lifecycle status, version label, reviewed date posture, residual risk, and required re-review trigger before proposing any registry update. ## Required Validation And Receipt Expectations Any future implementation issue that proposes adding a candidate to the active registry must include: - owner-approved issue scope - candidate review evidence - source-role classification - artifact-type classification where applicable - authority class - trust ceiling - license and rights posture - lifecycle status - retrieval mode - default policy - activation policy - no-browser-fetch confirmation - no-provider-call confirmation - no-package-authority confirmation - no-user-registry-mutability confirmation - marketing-page exclusion or explicit owner-approved exception - registry diff - focused validation coverage - validation receipt - context-pack or discoverability update if repo convention requires it The receipt must confirm whether runtime behavior, UI behavior, source selection behavior, answer telemetry behavior, advanced pasted-source behavior, Request new source behavior, provider/model configuration, Cloudflare configuration, package authority, approved package source sets, source fetching, source discovery, #78, #271, and `codex-automerge` were unchanged. ## Explicit Forbidden Behavior #419 forbids: - Do not mutate the active source registry in #419. - Do not add runtime behavior. - Do not add arbitrary web search. - Do not add browser-side source fetching. - Do not add browser-side provider calls. - Do not add URL fetching. - Do not add source discovery, crawling, queue, worker, scheduled job, webhook, polling, durable storage, or durable memory. - Do not ingest licensed full text without rights clearance. - Do not use unofficial mirrors for rights-controlled standards. - Do not mutate package authority. - Do not mutate approved package source sets. - Do not change provider/model configuration. - Do not change Cloudflare configuration or use Cloudflare CLI/API. - Do not mutate #78. - Do not reopen #271. - Do not apply `codex-automerge`. ## Follow-Up Model For Future Child Issues Future child issues must be narrow and owner-approved before implementation. A child issue may handle one candidate, one tightly bounded source class, or one taxonomy repair, but it must not bundle unrelated candidate expansion with runtime work. A future child issue must state whether it is review-only, registry-update-only, extraction-profile work, runtime enablement work, or documentation/receipt work. Those lanes must remain separate unless the owner explicitly approves a coherent implementation cluster. The minimum future sequence is: 1. Candidate review packet. 2. Owner decision. 3. Owner-approved implementation issue. 4. Registry update, if approved. 5. Focused validator and fixtures, if registry content changes. 6. Discoverability and context-pack update, if repo convention requires it. 7. Validation receipt. 8. Draft PR unless the owner explicitly authorizes a ready PR. ## Boundary Confirmations - No active source is added. - No candidate source entry is added. - No runtime behavior is changed. - No UI behavior is changed. - No source selection behavior is changed. - No answer telemetry behavior is changed. - No advanced pasted-source behavior is changed. - No Request new source behavior is changed. - No provider or model configuration is changed. - No Cloudflare configuration is changed. - No active source registry content is mutated. - No package authority is mutated. - No approved package source set is mutated. - No arbitrary web search is added. - No browser-side source fetching is added. - No browser-side provider call is added. - No URL fetching is added. - No source discovery, crawling, queue, worker, scheduled job, webhook, polling, durable storage, or durable memory is added. - No source registration is implemented. - #78 is not mutated. - #271 is not reopened. - `codex-automerge` must not be applied.