# Expanded Current/Public Source Catalog And Approval Matrix V01

Issue: #244

Date: 2026-06-25

Status: governance catalog and candidate-only registry design. This document does not enable production current retrieval.

## Purpose

Define the broader current/public source catalog beyond NIST for Package + current context.

The catalog gives future enablement issues a governed approval matrix for external public sources. It defines source authority classes, allowed use, claim boundaries, citation boundaries, freshness expectations, exclusion rules, and enablement sequencing.

This catalog prevents Package + current context from becoming arbitrary web search, vendor marketing ingestion, model-memory answering, or silent package-authority mutation.

## Current Production Baseline

- NIST AI RMF is the only enabled current/public production source.
- All additional sources defined in this ticket remain candidate-only.
- Package-only remains the default.
- Package + current context remains explicit and package-first.
- Current/public sources enrich, compare, challenge, and suggest update candidates but do not become approved package authority.
- NIST remains current/public context only, not package authority.
- Direct browser provider calls and direct browser current-source calls remain prohibited.

## Source Authority Model

Current/public authority is scoped to what the source actually publishes. It is never a general approval layer.

| Authority lane | Meaning | Boundary |
|---|---|---|
| Package authority | Approved repository package sources, generated artifacts, manifests, receipts, and owner-reviewed package changes. | Canonical for package answers. |
| Current/public context | Separately cited public sources retrieved only after package support exists. | Enrichment and comparison only. |
| Candidate review evidence | Registry entries, source catalog rows, and review receipts. | Planning evidence only, not runtime permission. |
| Vendor self-claims | Official vendor documentation or provider documentation. | Vendor-specific facts only, not neutral governance authority. |
| Community signal | Practitioner discussion, forums, issues, or social sources. | Weak signal only and excluded from runtime by default. |

## Source Classes And Allowed Use

### 1. Government / Standards / Regulator-Adjacent Authority

Examples:

- NIST
- CISA
- OWASP
- MITRE
- ISO/IEC only if public URL and licensing allow citation and fetch
- EU AI Act official pages if public and relevant
- UK NCSC, ENISA, or similar official cybersecurity or AI governance sources if scoped tightly

Allowed use:

- governance
- risk
- security
- standards
- framework alignment
- control expectations

Claim boundary:

- authoritative for its own published material only
- not company policy
- not package authority unless later promoted through a human-approved package update

### 1A. Regulated Life Sciences / GxP / Medical Device Authority

Examples:

- FDA regulations and guidance
- European Commission EudraLex GMP guidance
- EMA guidance where scoped to regulated computerized systems, clinical systems, or data integrity
- ICH harmonized guidelines
- official standard metadata or incorporated-by-reference pages for ISO and IEC standards
- inspectorate, global health, and regulated-industry governance sources such as PIC/S, WHO, and ISPE public metadata

Allowed use:

- electronic records and signatures
- computerized systems / computerised systems
- GxP validation and assurance
- audit trails
- access control
- data integrity
- record retention
- quality systems
- risk management
- supplier/service-provider controls
- medical device software lifecycle
- clinical systems and trial records
- manufacturing and lab systems
- global regulatory comparison and gap identification

Claim boundary:

- authoritative only within the source's jurisdiction, scope, and stated applicability
- not company policy
- not legal advice
- not validation approval
- not product approval
- not production approval
- not package authority unless later promoted through a human-reviewed package update
- must not be used to claim a system is compliant
- must not override internal quality, regulatory, legal, privacy, security, or validation owner decisions
- standards that are paywalled or incorporated by reference may be cited only through official public metadata or incorporated-by-reference pages unless accessible public text is legally available

### 2. Official Vendor Documentation

Examples:

- Microsoft Learn, Azure AI, and Copilot Studio official docs
- AWS official docs, Bedrock docs, and Well-Architected docs
- Google Cloud and Vertex AI official docs
- GitHub official docs
- Cloudflare official docs
- Databricks, Snowflake, ServiceNow, Atlassian, or other platform docs only if directly relevant later

Allowed use:

- platform-specific facts
- API behavior
- supported features
- limits
- security posture claims made by that vendor
- configuration guidance
- documented capabilities

Claim boundary:

- authoritative only for that vendor's own product documentation
- not neutral comparison evidence by itself
- not governance authority
- not proof that a platform is approved, safe, compliant, or fit for regulated use
- vendor marketing pages are excluded or marketing-only and not valid for technical claims

### 3. Official Research Lab / Model Provider Documentation

Examples:

- OpenAI docs and official safety, model, or system-card pages
- Anthropic docs and official safety, model, or system-card pages
- Google DeepMind or Google AI official technical and safety docs where stable and public
- Meta AI official model docs where stable and public

Allowed use:

- model behavior
- API and runtime facts
- safety claims from the official source
- model capability caveats
- system card interpretation

Claim boundary:

- provider self-claims must be caveated
- benchmark or metric claims require source-specific citation
- benchmark or metric claims must not become package doctrine without review
- not approval for use in regulated workflows

### 4. Reputable Engineering Practice Sources

Examples:

- Google SRE book and SRE workbook
- Microsoft Architecture Center and Azure architecture guidance
- AWS Well-Architected Framework
- CNCF official docs where relevant
- Kubernetes official docs where relevant
- GitHub Engineering or official engineering blogs only if stable and clearly owned
- Thoughtworks Technology Radar as opinion or signal only

Allowed use:

- engineering reliability
- architecture
- operational patterns
- software delivery
- platform operation

Claim boundary:

- respected engineering guidance, not policy
- should not override package guidance
- should be used for comparison or enrichment with explicit citation

### 5. Security And AI Safety Framework Sources

Examples:

- OWASP Top 10 for LLMs and GenAI
- MITRE ATLAS
- CISA Secure by Design
- NIST SSDF
- UK NCSC AI or security guidance
- ENISA where relevant and public

Allowed use:

- security threat patterns
- secure design
- adversarial risk
- controls
- software supply chain
- AI-specific threat modeling

Claim boundary:

- authoritative or respected within its stated scope
- not a generic endorsement of tools or vendors
- not package authority unless later moved into package text through human approval

### 6. Community And Practitioner Sources

Examples:

- Reddit forums
- Hacker News
- Stack Overflow
- GitHub issues and discussions
- specialist practitioner forums
- independent practitioner blogs and newsletters

Default posture:

- excluded from runtime current/public source enablement unless a later owner-approved issue defines a narrow reason and strong caveats

Allowed use if ever approved:

- weak signal only
- emerging issue discovery
- community experience patterns
- known pain points
- anecdotal reports that require verification elsewhere

Claim boundary:

- not authority
- not final evidence
- not package authority
- not vendor fact source
- not compliance evidence
- not allowed for safety, security, regulatory, pricing, limits, or capability claims without independent authoritative confirmation

### 7. Excluded By Default

Examples:

- arbitrary web search results
- generic news
- social media posts
- marketing pages
- press releases
- SEO content farms
- unaudited personal sites
- scraped forum threads without review
- paywalled or login-gated sources
- sources without stable public URL
- pages with wildcard or broad path requirements
- private or internal company material
- user-provided URLs
- content with unclear licensing or citation posture

## Candidate Approval Lifecycle

1. Candidate source class is proposed.
2. Candidate ID, owner, proposed URL, allowed origin, allowed path prefix, allowed use, claim boundary, citation label, freshness cadence, risks, and enablement recommendation are recorded.
3. URL and path are verified only when an exact public URL is already known or a later verification issue proves it.
4. Candidate remains `approval_status: "candidate_only"` and `retrieval_enabled: false`.
5. Owner review confirms public availability, licensing and citation posture, source class, path scope, and claim boundary.
6. A later issue may approve exactly one or a narrowly grouped source set for preview or production configuration.
7. Production configuration happens outside the repository and must preserve server-side retrieval only.
8. Production smoke proves package-first behavior, separate citations, NIST-only baseline if no new source was approved, and zero direct browser current-source calls.
9. Rollback remains possible without code changes.

Catalog inclusion does not mean runtime enablement.

Current/public source inclusion does not mean package authority.

## Claim-Boundary Rules

- Current/public claims must be attributed to the cited source lane.
- Current/public claims must not silently rewrite package guidance.
- If package and current/public sources diverge, the answer must name the divergence and preserve both lanes.
- Vendor documentation must not be treated as neutral governance authority.
- Vendor sources must not be treated as neutral governance authority.
- Community sources must not be treated as authoritative.
- Government and standards sources are authoritative for their own public material only.
- Regulated life sciences / GxP / medical device sources are authoritative only within their source jurisdiction, scope, and stated applicability.
- Regulated life sciences / GxP / medical device sources must not be used to claim compliance, validation approval, product approval, production approval, or internal owner approval.
- Paywalled or incorporated-by-reference standards must not be treated as fetchable full text unless accessible public text is legally available.
- Reputable engineering sources can enrich implementation thinking, but they do not approve production use.
- Source catalog entries and candidate registry entries are planning artifacts, not approval artifacts.

## Citation-Boundary Rules

Current/public citations must disclose:

- source title
- source owner
- source class
- source URL or reader target
- retrieval timestamp when retrieved at runtime
- trust and freshness labels
- claim boundary
- citation label
- whether the source is package authority, which must be no for this catalog

Package citations and current/public citations must remain visually and semantically separate.

## Freshness And Review Cadence

| Source class | Minimum review cadence before enablement | Extra freshness rule |
|---|---|---|
| Government / standards / regulator-adjacent | Before production enablement, then periodic review. | Review again if the source announces a major revision. |
| Regulated life sciences / GxP / medical device authority | Before production enablement, then periodic, version-bound, or regulation-sensitive review. | Verify exact source, jurisdiction, applicability, public/legal access, and owner approval before any runtime use. |
| Official vendor documentation | Before production enablement and before any time-sensitive use. | Review before claims about pricing, limits, availability, or supported features. |
| Official provider documentation | Before production enablement and before model-sensitive claims. | Review before claims about model behavior, safety, benchmarks, or capability. |
| Reputable engineering practice | Before production enablement, then periodic review. | Treat as practice guidance, not policy. |
| Security and AI safety framework | Before production enablement, then periodic or version-bound review. | Review when a new major version is published. |
| Community and practitioner source | Excluded or deferred by default. | Requires independent authoritative confirmation before answer use. |

## Vendor Source Policy

Vendor sources may support platform-specific facts about that vendor's own products or services.

They must not be used to:

- approve a vendor
- approve a tool
- approve a model
- approve production use
- prove compliance
- supply neutral industry comparison by themselves
- override package guidance
- become package authority

Vendor marketing pages, press releases, pricing claims without time-sensitive review, and broad product pages without narrow technical path constraints are excluded from technical claims.

## Engineering-Source Policy

Engineering practice sources can help interpret reliability, architecture, operating model, delivery, and platform-operation questions after package support exists.

They must be cited as practice guidance or opinionated engineering guidance. They must not override package guidance, act as policy, or approve any production configuration.

## Community-Source Policy

Community sources are excluded from runtime current/public enablement by default.

If a later owner-approved issue allows a community source, the source can support weak signal only. It must be paired with a warning that it is anecdotal and requires verification elsewhere.

Community sources must not support final claims about security, safety, regulation, compliance, pricing, limits, supported features, or model capability.

## Exclusion Policy

The catalog excludes:

- arbitrary web search
- browser-side source fetches
- user-provided URL retrieval
- wildcard domains
- broad root-domain vendor candidates without path constraints
- private or internal hostnames
- login-gated pages
- paywalled pages
- source URLs containing credentials or secrets
- source pages without stable public URL
- marketing pages for technical claims
- community/forum content for authoritative claims
- sources with unclear licensing or citation posture

## Candidate Source Table

`current_source_registry_candidates_v02.json` records candidate-only registry metadata for this table. Existing exact URLs are preserved only when they already appear in prior reviewed registry or source-review artifacts. Otherwise the URL is marked `to_be_verified`.

| Candidate ID | Source title | Source owner | Source class | Proposed URL | Allowed origin | Allowed path prefix | Allowed use | Claim boundary | Freshness/review cadence | Citation label | Initial posture | Enablement recommendation | Notes / risks |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| `nist-ai-rmf-public-framework-candidate` | NIST AI Risk Management Framework | NIST | Government / standards / regulator-adjacent authority | `https://www.nist.gov/itl/ai-risk-management-framework` | `https://www.nist.gov` | `/itl/ai-risk-management-framework` | AI governance and risk comparison | Current/public context only, not package authority | Before enablement, then periodic | NIST AI RMF current/public context | Already enabled externally as the only production source | Keep as only enabled source until later approval | Existing production baseline source. |
| `nist-ssdf-sp-800-218-candidate` | NIST SSDF SP 800-218 | NIST CSRC | Security and AI safety framework source | `https://csrc.nist.gov/pubs/sp/800/218/final` | `https://csrc.nist.gov` | `/pubs/sp/800/218/final` | Secure software development comparison | Secure software guidance only, not package authority | Before enablement, then periodic | NIST SSDF current/public context | Candidate-only | SSDF-only PR preparation authorized; production activation and external config pending later explicit authorization | Existing reviewed candidate. Rev. 1 draft remains excluded. |
| `nist-ai-rmf-playbook-candidate` | NIST AI RMF Playbook | NIST AIRC | Government / standards / regulator-adjacent authority | `https://airc.nist.gov/airmf-resources/playbook/` | `https://airc.nist.gov` | `/airmf-resources/playbook/` | Same-family AI RMF enrichment | Current/public context only, not package authority | Living resource review before enablement | NIST AI RMF Playbook current/public context | Candidate-only | Same-family follow-on candidate | Existing reviewed candidate. |
| `owasp-genai-llm-top-10-2025-candidate` | OWASP Top 10 for LLMs and Gen AI Apps | OWASP Foundation GenAI Security Project | Security and AI safety framework source | `https://genai.owasp.org/llm-top-10/` | `https://genai.owasp.org` | `/llm-top-10/` | LLM application security comparison | Security guidance only, not package authority | Before enablement, then periodic | OWASP GenAI LLM Top 10 current/public context | Candidate-only | Candidate after NIST-family sources | Community-maintained framework, not policy. |
| `mitre-atlas-candidate-deferred` | MITRE ATLAS | MITRE | Security and AI safety framework source | `to_be_verified` | `to_be_verified` | `to_be_verified` | AI threat-modeling comparison | Security framework context only, not package authority | Verify exact public path before enablement | MITRE ATLAS current/public context | Candidate-deferred | Verify narrow path in later issue | Prior root URL review left path too broad. |
| `cisa-secure-by-design-candidate` | CISA Secure by Design | CISA | Government / standards / regulator-adjacent authority | `https://www.cisa.gov/securebydesign` | `https://www.cisa.gov` | `/securebydesign` | Secure engineering comparison | Cybersecurity guidance only, not package authority | Before enablement, then periodic | CISA Secure by Design current/public context | Candidate-only | Candidate after NIST and OWASP security review | Existing reviewed candidate. |
| `cisa-ai-guidance-candidate` | CISA Artificial Intelligence | CISA | Government / standards / regulator-adjacent authority | `https://www.cisa.gov/ai` | `https://www.cisa.gov` | `/ai` | AI cybersecurity context | Cybersecurity guidance only, not package authority | Before enablement, then periodic | CISA AI current/public context | Candidate-only | Needs page-specific claim review | Existing reviewed candidate. |
| `uk-ncsc-ai-security-guidance-candidate-deferred` | UK NCSC AI/security guidance | UK NCSC | Government / standards / regulator-adjacent authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | AI/security public guidance | Government cybersecurity guidance only, not package authority | Verify exact URL before enablement | UK NCSC AI/security current/public context | Candidate-deferred | Later verification issue required | Exact public path not verified in repo. |
| `enisa-ai-cybersecurity-guidance-candidate-deferred` | ENISA AI/cybersecurity guidance | ENISA | Government / standards / regulator-adjacent authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | EU cybersecurity and AI risk context | Public agency guidance only, not package authority | Verify exact URL before enablement | ENISA AI/cybersecurity current/public context | Candidate-deferred | Later verification issue required | Exact public path not verified in repo. |
| `eu-ai-act-official-pages-candidate-deferred` | EU AI Act official pages | European Union official publication owner to be verified | Government / standards / regulator-adjacent authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Legal/regulatory public context | Official source context only, not company policy or package authority | Verify exact source and licensing before enablement | EU AI Act current/public context | Candidate-deferred | Later legal-source verification required | Must not be treated as legal advice. |
| `fda-21-cfr-part-11-candidate` | FDA / CFR Title 21 Part 11, Electronic Records; Electronic Signatures | FDA / CFR | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Electronic records, electronic signatures, Part 11 scope, record/signature controls | FDA regulatory context only, not company policy, validation approval, product approval, production approval, or package authority | Verify exact public source before enablement, then periodic regulatory review | FDA 21 CFR Part 11 current/public context | Candidate-deferred | Verify FDA CFR or eCFR source behavior in later issue | eCFR may block scraping; FDA CFR page or eCFR API may be safer for future retrieval. |
| `fda-part-11-scope-application-guidance-candidate` | FDA Guidance, Part 11, Scope and Application | FDA | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | FDA current-thinking guidance on Part 11 scope, predicate-rule framing, validation, audit trail, copies, and retention | FDA guidance/current thinking, nonbinding unless tied to applicable law, not package authority | Verify exact public source before enablement, then periodic guidance review | FDA Part 11 Scope and Application guidance current/public context | Candidate-deferred | Verify exact stable FDA guidance URL in later issue | Not company policy, not legal advice, and not validation approval. |
| `fda-computer-software-assurance-csa-candidate` | FDA Computer Software Assurance for Production and Quality System Software guidance | FDA | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | CSA, risk-based assurance, production and quality system software assurance | FDA guidance/current thinking, not approval of a specific assurance method or tool, not package authority | Verify exact public source before enablement, then periodic guidance review | FDA Computer Software Assurance guidance current/public context | Candidate-deferred | Verify exact stable FDA guidance URL in later issue | Not tool approval, not company policy, and not validation approval. |
| `fda-qmsr-21-cfr-820-candidate` | FDA Quality Management System Regulation / 21 CFR Part 820 | FDA | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Medical device QMS, ISO 13485 incorporation context, QMSR transition, inspection expectations | FDA medical device regulatory context only, not ISO certification substitute, not FDA compliance claim, not package authority | Verify exact public source before enablement, then periodic regulatory review | FDA QMSR / 21 CFR Part 820 current/public context | Candidate-deferred | Verify exact stable FDA source in later issue | Does not claim ISO 13485 certification replaces FDA inspection or compliance obligations. |
| `fda-ai-ml-enabled-medical-device-guidance-candidate` | FDA AI/ML-enabled medical device guidance and action-plan sources | FDA | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | AI-enabled device regulatory posture, software change control plan, SaMD/MLMD lifecycle expectations | FDA device guidance/current thinking, not approval for a particular AI/ML device or internal AI tool, not package authority | Verify exact stable FDA source before enablement, then time-sensitive guidance review | FDA AI/ML-enabled medical device current/public context | Candidate-deferred | Verify exact stable FDA source group in later issue | Not product approval and not internal AI tool approval. |
| `eu-gmp-annex-11-computerised-systems-candidate` | European Commission EudraLex Volume 4, Annex 11: Computerised Systems | European Commission EudraLex Volume 4 | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | GMP computerised systems, validation, data integrity, audit trails, security, business continuity, supplier/service-provider controls | EU GMP guidance for medicinal products, not global policy by itself, not package authority | Verify exact public source before enablement, then periodic GMP review | EU GMP Annex 11 current/public context | Candidate-deferred | Verify exact EudraLex URL in later issue | Not company SOP and not validation approval. |
| `eu-gmp-chapter-4-documentation-candidate` | EudraLex Volume 4 Chapter 4, Documentation | European Commission EudraLex Volume 4 | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | GMP documentation, records, data integrity, document control | EU GMP documentation context only, not company-specific GDP/GDocP SOP, not package authority | Verify exact public source before enablement, then periodic GMP review | EU GMP Chapter 4 Documentation current/public context | Candidate-deferred | Verify exact EudraLex URL in later issue | Not company policy and not validation approval. |
| `ema-computerised-systems-gcp-gxp-guidance-candidate` | EMA computerised systems / clinical systems / data integrity guidance | EMA | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Clinical and regulated computerized-system expectations where applicable | EMA guidance within stated scope only, not company policy, not validation approval, not package authority | Verify exact public source before enablement, then periodic guidance review | EMA computerised systems / GxP current/public context | Candidate-deferred | Verify exact EMA source in later issue | Exact source and scope require later verification. |
| `ich-q9-quality-risk-management-candidate` | ICH Q9(R1) Quality Risk Management | ICH | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Quality risk management principles, risk-based validation/assurance framing | ICH harmonized guidance only, not implementation approval, not package authority | Verify exact public source before enablement, then version-bound guideline review | ICH Q9(R1) current/public context | Candidate-deferred | Verify exact ICH URL in later issue | Not company policy and not validation approval. |
| `ich-q10-pharmaceutical-quality-system-candidate` | ICH Q10 Pharmaceutical Quality System | ICH | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Pharmaceutical quality system model, lifecycle, knowledge management, continual improvement | ICH harmonized guidance only, not company QMS approval, not package authority | Verify exact public source before enablement, then version-bound guideline review | ICH Q10 current/public context | Candidate-deferred | Verify exact ICH URL in later issue | Not company policy and not validation approval. |
| `ich-e6-good-clinical-practice-candidate` | ICH E6 Good Clinical Practice | ICH | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Clinical trial quality, sponsor/investigator responsibilities, essential documents, computerized clinical systems where relevant | Clinical research guidance only, not manufacturing or medical-device QMS authority, not package authority | Verify exact source and applicable revision before enablement, then version-bound guideline review | ICH E6 current/public context | Candidate-deferred | Verify exact ICH URL and applicable revision in later issue | Not manufacturing QMS authority and not medical-device QMS authority. |
| `iso-13485-standard-metadata-candidate` | ISO 13485:2016 official metadata / FDA QMSR IBR references / ANSI IBR portal references | ISO / FDA / ANSI metadata owners | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Medical device QMS standard identity and high-level applicability metadata | Standard metadata only, not full text, not a substitute for the standard, not package authority | Verify public metadata or legal access before enablement, then version-bound standard review | ISO 13485 metadata current/public context | Candidate-deferred | Verify public metadata or incorporated-by-reference access in later issue | Do not reproduce paywalled standard text. |
| `iso-14971-standard-metadata-candidate` | ISO 14971 official metadata / recognized standard references | ISO / recognized standards metadata owners | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Medical device risk management standard identity and scope metadata | Standard metadata only, not full text, not a substitute for the standard, not package authority | Verify public metadata or legal access before enablement, then version-bound standard review | ISO 14971 metadata current/public context | Candidate-deferred | Verify official public metadata in later issue | Do not reproduce paywalled standard text. |
| `iec-62304-standard-metadata-candidate` | IEC 62304 official metadata / recognized standard references | IEC / recognized standards metadata owners | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Medical device software lifecycle standard identity and scope metadata | Standard metadata only, not full text, not a substitute for the standard, not package authority | Verify public metadata or legal access before enablement, then version-bound standard review | IEC 62304 metadata current/public context | Candidate-deferred | Verify official public metadata in later issue | Do not reproduce paywalled standard text. |
| `iec-82304-1-health-software-standard-metadata-candidate` | IEC 82304-1 official metadata / recognized standard references | IEC / recognized standards metadata owners | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Standalone health software product safety/security lifecycle context and scope metadata | Standard metadata only, not full text, not a substitute for the standard, not package authority | Verify public metadata or legal access before enablement, then version-bound standard review | IEC 82304-1 metadata current/public context | Candidate-deferred | Verify official public metadata in later issue | Do not reproduce paywalled standard text. |
| `ispe-gamp5-candidate` | ISPE GAMP 5 and related public pages / metadata | ISPE | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Industry good-practice framing for computerized system validation/assurance, risk-based approach, supplier assessment, lifecycle controls | Industry guidance, not regulation, not company policy, not validation approval, not package authority | Verify public metadata or legal access before enablement, then periodic industry-guidance review | ISPE GAMP 5 metadata current/public context | Candidate-deferred | Verify public metadata or licensed access in later issue | Do not reproduce licensed text. |
| `pics-gmp-data-integrity-guidance-candidate` | PIC/S GMP data integrity guidance | PIC/S | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Data integrity, records, audit trails, governance expectations | PIC/S inspectorate/cooperation-scheme guidance within stated scope, not company policy, not validation approval, not package authority | Verify exact public source before enablement, then periodic GMP review | PIC/S GMP data integrity current/public context | Candidate-deferred | Verify exact stable URL in later issue | Scope and applicability require owner review. |
| `who-gmp-data-integrity-guidance-candidate` | WHO GMP / data integrity guidance | WHO | Regulated life sciences / GxP / medical device authority | `to_be_verified` | `to_be_verified` | `to_be_verified` | Global pharma GMP and data integrity reference where applicable | WHO guidance within stated scope, not company policy, not validation approval, not package authority | Verify exact public source before enablement, then periodic GMP review | WHO GMP / data integrity current/public context | Candidate-deferred | Verify exact stable WHO URL in later issue | Scope and applicability require owner review. |
| `microsoft-learn-azure-ai-docs-candidate-deferred` | Microsoft Learn Azure AI docs | Microsoft Learn | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Azure AI platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before feature-sensitive use | Microsoft Azure AI docs current/public context | Candidate-deferred | Later vendor-doc verification required | Exclude marketing pages. |
| `microsoft-copilot-studio-docs-candidate-deferred` | Microsoft Copilot Studio docs | Microsoft Learn | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Copilot Studio platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before feature-sensitive use | Microsoft Copilot Studio docs current/public context | Candidate-deferred | Later vendor-doc verification required | Exclude marketing pages. |
| `aws-bedrock-docs-candidate-deferred` | AWS Bedrock docs | AWS documentation | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Bedrock platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before feature-sensitive use | AWS Bedrock docs current/public context | Candidate-deferred | Later vendor-doc verification required | Exclude marketing pages. |
| `aws-well-architected-framework-candidate-deferred` | AWS Well-Architected Framework | AWS documentation | Reputable engineering practice source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Architecture and operational pattern comparison | Engineering guidance only, not package authority or production approval | Verify exact URL before enablement | AWS Well-Architected current/public context | Candidate-deferred | Later exact path review required | Vendor-published engineering material carries vendor posture. |
| `google-cloud-vertex-ai-docs-candidate-deferred` | Google Cloud Vertex AI docs | Google Cloud documentation | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Vertex AI platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before feature-sensitive use | Google Cloud Vertex AI docs current/public context | Candidate-deferred | Later vendor-doc verification required | Exclude marketing pages. |
| `google-sre-book-candidate` | Google Site Reliability Engineering Book | Google SRE | Reputable engineering practice source | `https://sre.google/sre-book/table-of-contents/` | `https://sre.google` | `/sre-book/table-of-contents/` | Reliability and operational practice comparison | Engineering guidance only, not policy or package authority | Before enablement, then periodic | Google SRE current/public context | Candidate-only | Lower priority than government and security sources | Existing reviewed candidate. |
| `openai-api-pricing-docs-candidate` | OpenAI API Pricing | OpenAI developer documentation | Official provider documentation | `https://developers.openai.com/api/docs/pricing` | `https://developers.openai.com` | `/api/docs/pricing` | Provider-specific pricing and token cost context | Provider-specific reference only, not neutral governance authority or package authority | Review before every pricing-sensitive use | OpenAI pricing current/public context | Candidate-only | Time-sensitive candidate only after owner review | Existing reviewed candidate. |
| `openai-official-docs-candidate-deferred` | OpenAI official docs | OpenAI | Official provider documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | API/runtime facts and documented capabilities | Provider-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before model-sensitive use | OpenAI docs current/public context | Candidate-deferred | Later provider-doc verification required | Use official docs only, not marketing pages. |
| `openai-safety-model-system-cards-candidate-deferred` | OpenAI safety/model/system-card pages | OpenAI | Official research lab / model provider documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Model behavior and safety self-claims | Provider self-claims only, caveated, not package authority | Verify exact stable URL before enablement | OpenAI safety/model current/public context | Candidate-deferred | Later provider-doc verification required | Benchmark claims require source-specific citation. |
| `anthropic-official-docs-candidate-deferred` | Anthropic official docs | Anthropic | Official provider documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | API/runtime facts and documented capabilities | Provider-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement and before model-sensitive use | Anthropic docs current/public context | Candidate-deferred | Later provider-doc verification required | Use official docs only, not marketing pages. |
| `anthropic-model-safety-pages-candidate-deferred` | Anthropic model/safety pages | Anthropic | Official research lab / model provider documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Model behavior and safety self-claims | Provider self-claims only, caveated, not package authority | Verify exact stable URL before enablement | Anthropic safety/model current/public context | Candidate-deferred | Later provider-doc verification required | Benchmark claims require source-specific citation. |
| `github-actions-copilot-security-docs-candidate-deferred` | GitHub Actions, Copilot, and security docs | GitHub Docs | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | GitHub platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement | GitHub Docs current/public context | Candidate-deferred | Later vendor-doc verification required | Scope to platform facts only. |
| `cloudflare-workers-limits-docs-candidate` | Cloudflare Workers Limits | Cloudflare developer documentation | Official vendor documentation | `https://developers.cloudflare.com/workers/platform/limits/` | `https://developers.cloudflare.com` | `/workers/platform/limits/` | Runtime platform limit context | Vendor-specific reference only, not neutral governance authority or package authority | Review before limit-sensitive use | Cloudflare Workers Limits current/public context | Candidate-only | Candidate only for platform-limit questions | Existing reviewed candidate. |
| `cloudflare-pages-workers-access-docs-candidate-deferred` | Cloudflare Pages, Workers, and Access docs | Cloudflare developer documentation | Official vendor documentation | `to_be_verified` | `to_be_verified` | `to_be_verified` | Deployment platform-specific facts | Vendor-specific facts only, not neutral governance authority or package authority | Verify exact URL before enablement | Cloudflare docs current/public context | Candidate-deferred | Later exact path review required | Access/WAF configuration remains external. |
| `microsoft-architecture-center-candidate-deferred` | Microsoft Architecture Center | Microsoft Learn | Reputable engineering practice source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Architecture pattern comparison | Vendor-published engineering guidance only, not policy or package authority | Verify exact URL before enablement | Microsoft Architecture Center current/public context | Candidate-deferred | Later exact path review required | Vendor-published engineering material carries vendor posture. |
| `cncf-kubernetes-official-docs-candidate-deferred` | CNCF/Kubernetes official docs | CNCF/Kubernetes documentation owners | Reputable engineering practice source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Platform operation and orchestration patterns | Engineering guidance only, not package authority or production approval | Verify exact URL before enablement | CNCF/Kubernetes docs current/public context | Candidate-deferred | Later exact path review required | Include only if directly relevant. |
| `thoughtworks-technology-radar-signal-deferred` | Thoughtworks Technology Radar | Thoughtworks | Reputable engineering practice source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Opinion and trend signal | Opinion/signal only, not authority or package authority | Verify exact URL and use only as signal | Thoughtworks Radar signal context | Deferred signal-only | Do not enable as authoritative source | Treat as opinion, not evidence. |
| `reddit-community-source-excluded` | Reddit forums | Reddit community contributors | Community and practitioner source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Weak signal only if ever separately approved | Not authority, not final evidence, not package authority | Excluded by default | Reddit weak-signal context | Excluded by default | Do not enable runtime source | Anecdotal and unverified. |
| `hacker-news-community-source-excluded` | Hacker News | Hacker News community contributors | Community and practitioner source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Weak signal only if ever separately approved | Not authority, not final evidence, not package authority | Excluded by default | Hacker News weak-signal context | Excluded by default | Do not enable runtime source | Anecdotal and unverified. |
| `stack-overflow-community-source-excluded` | Stack Overflow | Stack Overflow contributors | Community and practitioner source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Weak signal only if ever separately approved | Not authority, not final evidence, not package authority | Excluded by default | Stack Overflow weak-signal context | Excluded by default | Do not enable runtime source | May help find implementation pain points only. |
| `github-issues-discussions-community-source-deferred` | GitHub issues and discussions | Project-specific repository owners and community contributors | Community and practitioner source | `to_be_verified` | `to_be_verified` | `to_be_verified` | Weak signal or official project issue evidence only if narrowly approved later | Not authority, not final evidence, not package authority | Deferred by default | GitHub issue/discussion weak-signal context | Deferred by default | Use only with project-specific owner review | Official repo issue trackers need separate authorization. |

### Regulated Life Sciences / GxP / Medical Device Candidate Group

The v02 registry adds 18 regulated life sciences / GxP / medical device candidates:

- FDA / United States: 5
- European Union / EMA / EudraLex: 3
- ICH harmonized guidelines: 3
- standards metadata: 4
- industry best-practice, inspectorate, and global GMP guidance: 3

Every regulated life sciences / GxP / medical device candidate remains `approval_status: "candidate_only"` and `retrieval_enabled: false`.

Every regulated life sciences / GxP / medical device candidate keeps `url`, `allowed_origin`, and `allowed_path_prefix` at `to_be_verified` until a later source-verification issue confirms exact public/legal access, fetch behavior, allowed path scope, source-owner approval, and production smoke.

Standards metadata candidates are metadata-only unless public/legal full text access is verified. The catalog must not reproduce paywalled standard text or imply that paywalled standard text is fetchable.

Industry good-practice sources such as ISPE GAMP 5 must not be treated as regulation, company policy, validation approval, production approval, or package authority.

## Enablement Sequencing Recommendation

1. Keep NIST AI RMF as the only enabled current/public production source until a later owner-approved issue changes that.
2. Prefer same-family or standards/security sources before vendor or community sources.
3. Consider NIST SSDF before vendor implementation docs when the question is secure software development.
4. Consider NIST AI RMF Playbook only after freshness review because it is a living resource.
5. Consider OWASP GenAI / LLM Top 10 for LLM application security only with its community-maintained caveat.
6. Consider CISA sources for public cybersecurity posture only after exact claim review.
7. Treat regulated life sciences / GxP / medical device candidates as high-consequence regulatory, guidance, standard-metadata, or industry-good-practice context that requires source-owner review and exact URL verification before any runtime use.
8. Treat official vendor and provider docs as platform-specific fact sources, not governance sources.
9. Keep community sources excluded or deferred until a later issue defines a narrow weak-signal workflow.

## Validation Requirements

Validation must assert:

- no new source is enabled
- NIST remains the only enabled current/public production source
- all new sources are candidate-only
- all new sources have `retrieval_enabled: false`
- no wildcard domains
- no private or internal hostnames
- no login-gated URLs if a URL is present
- no broad root-domain-only vendor candidate without a path prefix
- source class or type is present
- claim boundary is present
- citation label is present
- allowed origin and path prefix are present for fetchable candidates
- community sources are excluded or deferred by default
- no community source is treated as authoritative
- vendor sources have vendor-specific claim boundaries
- regulated life sciences / GxP / medical device sources are candidate-only
- regulated life sciences / GxP / medical device sources have `retrieval_enabled: false`
- FDA, EU/EMA, ICH, standards metadata, and industry or global GMP sources have distinct claim boundaries
- standards metadata candidates do not imply full-text retrieval unless public/legal access is verified
- industry best-practice sources such as ISPE/GAMP are not treated as regulation
- no source is represented as package authority
- no source catalog inclusion is treated as runtime enablement

## Non-Goals

This ticket does not:

- enable any new production current/public source
- change Cloudflare env/config
- change Cloudflare Access/WAF
- change provider/model secrets or provider/model config
- change runtime source registry env vars
- add arbitrary web search
- add browser-side current-source fetches
- add user-provided URL retrieval
- add durable telemetry, database, vector store, Supabase, uploads, or session attachments
- expose secrets
- promote any current/public source into approved package authority
- copy paywalled standard text or treat paywalled standards as fetchable unless legally available public text is verified
- claim regulated life sciences, GxP, medical device, clinical, manufacturing, lab, validation, quality, or software systems are compliant
- treat vendor docs as neutral governance authority
- treat community/forum sources as authoritative
- apply `codex-automerge`
- start #196, #188, #198, #187, or #79

## Follow-Up Recommendations

- Create one later verification issue per source group before using exact URLs that are not already in repo-reviewed artifacts.
- Create a separate regulated life sciences / GxP / medical device URL-verification issue before runtime enablement for any FDA, EU/EMA, ICH, standards metadata, ISPE, PIC/S, or WHO candidate.
- Start with one non-NIST candidate at a time if production enablement is later approved.
- Require owner approval, production smoke, rollback evidence, and receipt updates for each enablement step.
- Add admin-source-management fields for source class, claim boundary, citation label, owner, approver, review cadence, enablement status, rollback status, and source-watch relationship.
- Keep source-watch and update-candidate work separate from runtime enablement.