# Current Source Registry Governance And Production Enablement Runbook

Issue: #221

Status: governance design and enablement runbook. This document does not enable production current retrieval.

## Purpose

This note defines the owner-approved registry model required before `allowlisted_public_fetch` can retrieve current/public sources in production.

The registry is a bounded source-control artifact for public current context. It is not package authority, policy approval, runtime permission by itself, or a general web search surface.

## Scope

In scope:

- source registry schema and template
- source owner and approver responsibilities
- source type, trust, freshness, and claim-boundary labels
- allowed origin and path-prefix model
- redirect handling expectations
- review cadence and removal criteria
- production configuration expectations
- validation, smoke, rollback, and evidence requirements
- expanded current/public source catalog and approval matrix relationship

Out of scope:

- enabling production current retrieval
- changing Cloudflare environment variables
- changing Cloudflare Access or WAF
- arbitrary web search
- browser-side current-source fetches
- user-provided URL retrieval
- durable telemetry, database, vector store, Supabase, uploads, or session attachments
- promotion of current/public sources into approved package authority

## Expanded Source Catalog Relationship

Issue #244 adds `expanded_current_public_source_catalog_v01.md` and `current_source_registry_candidates_v02.json` as governance catalog artifacts.

Catalog inclusion does not mean runtime enablement.

Current/public source inclusion does not mean package authority.

Every source listed by the expanded catalog remains candidate-only unless a later owner-approved issue explicitly changes that source status, supplies an external deployment registry, and records production smoke and rollback evidence.

Future Production current-source expansion is blocked unless the Access-authenticated Production runtime smoke gate in `access_authenticated_production_runtime_smoke_v01.md` exists and passes before activation continues.

NIST AI RMF plus NIST SSDF remain the only enabled current/public production sources until later owner-approved enablement work changes that set.

`non_nist_current_source_enablement_plan_v01.md` defines the first staged non-NIST-AI-RMF governance/security batch. That plan remains documentation and verification planning only. It does not provide owner authorization, runtime registry configuration, or production enablement.

The SSDF-only preparation record authorizes an unmerged PR for NIST SSDF SP 800-218 final v1.1 only. It does not authorize production activation, external Cloudflare env/config mutation, runtime registry configuration, OWASP enablement, CISA / NSA / NCSC enablement, regulated-source enablement, or package-authority promotion.

The remaining Option A source-specific owner authorization drafts for OWASP GenAI 2025 Top 10 and CISA / NSA / NCSC secure AI guidance are draft-only readiness records. They prefill source identity, exact URL, exact origin, exact path prefix, verification, extraction, citation, dependency, and sequence fields for later owner review. They do not authorize production use, set retrieval enabled in repo candidate registries, change runtime configuration, or promote any source to package authority.

## Source Registry Admin Layer Relationship

Issue #269 adds `source_registry_admin_layer_spec_v01.md` as an architecture/specification note for future steady-state administration of already-approved current/public sources.

The admin layer specification separates bootstrap activation ceremony from steady-state source administration. It defines future command contracts, guardrails, receipt generation, smoke orchestration, last-known-good rollback, emergency disable, and child implementation slices.

The #269 specification is documentation-only. It does not implement admin CLI commands, mutate Preview or Production source sets, enable sources, change runtime registry posture, create service tokens, change Cloudflare Access/WAF, change provider/model configuration, change package authority, add arbitrary web search, add user-provided URL retrieval, add browser-side source fetches, implement database/vector behavior, or implement MCP behavior.

## Registry Lifecycle

1. Candidate source proposed.
2. Source owner records the proposed public URL, allowed origin, allowed path prefix, expected claim boundary, query terms, and review notes.
3. Owner review confirms that the source is public, non-sensitive, HTTPS-only, credential-free, bounded to a stable host and path, and appropriate for current/public context.
4. Approver assigns trust and freshness labels, records approval status, approval date, and review due date.
5. Maintainer runs registry validation against the candidate template and any deployment-specific registry packet.
6. A separate production enablement issue configures the registry outside the repository only after explicit owner authorization.
7. Production smoke proves that package-only remains default, Package + current context remains explicit, current/public citations are separate, and browser direct current-source calls remain zero.
8. Source remains active only while review due date, trust posture, freshness posture, and source availability remain acceptable.
9. Retired sources are removed from production configuration and retained only in issue or receipt evidence when needed.

The expanded catalog adds one earlier step before production enablement: classify the source authority class, allowed use, claim boundary, citation boundary, freshness expectation, and exclusion posture.

## Approval Model

Each source entry must identify:

- `source_owner`: person or role accountable for source suitability and review cadence
- `approved_by`: person or role that approved production use
- `approval_status`: `candidate_only`, `owner_review_pending`, `approved_for_preview`, `approved_for_production_config`, or `retired`
- `approved_date`: ISO date for approved entries, or `not_approved` for candidate entries
- `review_due_date`: ISO date or `before_production_enablement`

Candidate examples in the repository must remain `candidate_only` and `retrieval_enabled: false`.

Production retrieval requires a later issue with explicit owner authorization. A registry template in this repository is not production configuration.

## Source Owner Responsibilities

The source owner must confirm:

- the source is public and non-sensitive
- the URL does not require cookies, credentials, session state, or private network access
- the source has a stable owner, maintenance posture, and expected update cadence
- the allowed origin and path prefix are narrow enough for the intended current/public claim
- redirects remain inside the allowed origin and path prefix
- source claims remain current/public context only
- source content does not approve tools, vendors, models, workflows, data classes, production use, or company policy
- the source remains separate from package, context-pack, CLM, and owner-validated internal authority

## Registry Schema

The runtime adapter expects `AICD_CURRENT_CONTEXT_SOURCE_REGISTRY_JSON` to contain a JSON array. Each entry must include these fields:

| Field | Required Meaning |
|---|---|
| `id` | Stable registry ID using lowercase letters, numbers, and hyphens. |
| `title` | Human-readable source title. |
| `url` | HTTPS URL for the public current source. |
| `allowed_origin` | Exact HTTPS origin allowed for retrieval. |
| `allowed_path_prefix` | Path prefix that the URL and redirects must stay under. |
| `source_type` | Source type label from the approved label set. |
| `trust_label` | Trust label from the approved label set. |
| `freshness_label` | Freshness label from the approved label set. |
| `claim_boundary` | Claim-boundary label that keeps the source outside package authority. |
| `source_owner` | Accountable source owner or role. |
| `approved_by` | Approver or `not_approved`. |
| `approval_status` | Lifecycle status. |
| `approved_date` | Approval date or `not_approved`. |
| `review_due_date` | Review due date or `before_production_enablement`. |
| `query_terms` | Terms used to match package-supported questions to the source. |
| `retrieval_enabled` | Must be `false` in repo examples. |
| `notes` | Review notes, boundary notes, and retirement notes. |

Additional fields may be added by a later issue only when they strengthen review evidence without weakening the runtime adapter contract.

## Retrieval Sizing Profiles

The runtime default for `allowlisted_public_fetch` remains a 120000 byte response cap and a 1200 character current/public snippet cap.

Oversized source repair must be source-specific, not a global cap increase. A source-specific retrieval profile may be added only when all of these remain true:

- the source ID is stable and owner-reviewed
- the URL is HTTPS only, credential-free, and already bound to an exact allowed origin and path prefix
- the profile does not authorize sibling pages, broad domain crawling, arbitrary web search, or user-provided URL retrieval
- the profile preserves a bounded byte cap and bounded snippet cap
- the profile fails closed when required source markers are missing
- the profile does not enable retrieval by itself and does not promote the source to package authority

`nist-ai-rmf-public-framework-candidate` uses source-specific profile `nist_ai_rmf_framework_bounded_html_extract_v01`. The profile is limited to `https://www.nist.gov` and `/itl/ai-risk-management-framework`, keeps the response cap at 120000 bytes, caps snippets at 4000 characters, starts HTML extraction at `Overview of the AI RMF`, and requires substantive markers including `The NIST AI Risk Management Framework (AI RMF)`, `voluntary use`, and `trustworthiness considerations`. This repairs NIST page chrome swamping the default 1200 character snippet. It does not change Preview or Production source sets, broaden NIST retrieval, authorize sibling pages, fetch PDFs, or promote NIST to package authority.

`owasp-genai-llm-top-10-2025-candidate` uses inactive repair profile `owasp_genai_2025_bounded_html_extract_v01`. The profile is limited to `https://genai.owasp.org` and `/llm-top-10/`, caps response bytes at 1048576, caps snippets at 4000 characters, and requires `LLM01:2025` through `LLM10:2025` to survive extraction. This repairs the sizing readiness failure without activating OWASP in Preview or Production.

## Label Sets

Source type labels:

- `candidate_public_documentation`
- `candidate_public_status_page`
- `public_official_documentation`
- `public_release_notes`
- `public_status_page`
- `public_standards_or_regulatory`
- `public_reference_index`

Trust labels:

- `candidate_owner_review_required`
- `owner_approved_authoritative`
- `owner_approved_primary`
- `owner_approved_reference`
- `retired_do_not_use`

Freshness labels:

- `review_required_before_use`
- `retrieved_at_runtime`
- `time_sensitive_review_required`
- `periodic_review_required`
- `stale_retired`

Claim-boundary labels:

- `current_public_context_only_not_package_authority`
- `current_public_status_only_not_package_authority`
- `current_public_reference_only_not_package_authority`
- `retired_not_package_authority`

## Expanded Source Classes

The expanded catalog uses these source classes for candidate review:

| Source class | Allowed use | Claim boundary |
|---|---|---|
| Government / standards / regulator-adjacent authority | Governance, risk, security, standards, framework alignment, and control expectations. | Authoritative for its own public material only. Not company policy and not package authority. |
| Regulated life sciences / GxP / medical device authority | Electronic records/signatures, computerized systems, GxP validation and assurance, audit trails, access control, data integrity, record retention, quality systems, risk management, supplier controls, medical device software lifecycle, clinical systems, manufacturing systems, lab systems, and global regulatory comparison. | Authoritative only within the source's jurisdiction, scope, and stated applicability. Not company policy, legal advice, validation approval, product approval, production approval, compliance proof, or package authority. |
| Official vendor documentation | Platform-specific facts, API behavior, supported features, limits, vendor-owned security posture claims, configuration guidance, and documented capabilities. | Vendor-specific facts only. Not neutral governance authority, not production approval, and not package authority. |
| Official research lab / model provider documentation | Model behavior, API/runtime facts, safety claims from the official source, capability caveats, and system-card interpretation. | Provider self-claims must be caveated. Benchmark and metric claims require source-specific citation and do not become package doctrine without review. |
| Reputable engineering practice sources | Reliability, architecture, operational patterns, software delivery, and platform operation. | Respected engineering guidance, not policy. Does not override package guidance. |
| Security and AI safety framework sources | Threat patterns, secure design, adversarial risk, controls, software supply chain, and AI-specific threat modeling. | Authoritative or respected only within its stated scope. Not a vendor or tool endorsement. |
| Community and practitioner sources | Weak signal, emerging issue discovery, practitioner pain points, and anecdotal patterns if ever separately approved. | Not authority, not final evidence, not package authority, and not valid for safety, security, regulatory, pricing, limits, or capability claims without independent authoritative confirmation. |
| Excluded by default | Arbitrary web search, news, social posts, marketing, press releases, SEO content, unaudited personal sites, login-gated sources, broad wildcard sources, private material, and user-provided URLs. | No answer authority and no runtime retrieval. |

## Claim-Boundary Matrix

| Claim type | Permitted source class | Required boundary |
|---|---|---|
| Governance or standards comparison | Government, standards, regulator-adjacent, security-framework, or approved package sources. | Current/public context only unless package text is updated through human approval. |
| Regulated life sciences / GxP / medical device comparison | FDA, EU/EMA/EudraLex, ICH, official standards metadata, PIC/S, WHO, ISPE public metadata, or approved package sources. | Current/public context only. Not company policy, legal advice, validation approval, product approval, production approval, compliance proof, or package authority. |
| Vendor feature, limit, API, or configuration fact | Official vendor or provider documentation. | Vendor-specific fact only. Not neutral governance authority. |
| Model behavior, safety, system-card, or benchmark claim | Official provider documentation or official model/safety pages. | Provider self-claim with caveat. No regulated-use approval. |
| Reliability or architecture pattern | Reputable engineering practice source. | Practice guidance only. Not policy. |
| Community pain point or emerging issue | Community source only after later owner approval. | Weak signal only. Requires independent authoritative confirmation. |
| Compliance, safety, security, pricing, limits, or capability claim from community content | None. | Excluded from authoritative answer use. |

## Vendor Source Policy

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

Vendor sources must not:

- approve a vendor, tool, model, data class, workflow, or production use
- serve as neutral governance authority
- serve as compliance evidence by themselves
- override package guidance
- become package authority

Vendor marketing pages, press releases, and broad product pages without narrow technical path constraints are excluded for technical claims.

## Community Source Policy

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

If a later owner-approved issue allows a community source, it can support weak signal only. It cannot support authoritative claims, final evidence, vendor facts, safety evidence, security evidence, regulatory evidence, pricing evidence, limits evidence, or capability evidence without independent authoritative confirmation.

## Exclusion Policy

The current/public registry model excludes arbitrary web search, browser-side current-source fetches, user-provided URLs, wildcard domains, private/internal hosts, login-gated URLs, paywalled sources, marketing pages for technical claims, and sources without stable public URLs or clear citation posture.

Paywalled standards and incorporated-by-reference standards may be represented only through official public metadata or legally accessible public text. The registry must not treat paywalled standard text as fetchable full text unless that access posture is verified by a later source-owner review.

No source with a broad root-domain-only vendor path can become a fetchable candidate. Vendor candidates must use a narrow path prefix tied to the specific documented fact family.

## Allowed Host And Path Model

The allowed model is intentionally narrow:

- HTTPS only
- no URL username or password
- no localhost, private IP, link-local, `.local`, or `.internal` hostnames
- no wildcards in URL, allowed origin, or path prefix
- URL origin must equal `allowed_origin`
- URL path must start with `allowed_path_prefix`
- redirects must stay inside the same allowed origin and path prefix
- GET only
- credentials omitted
- response size, timeout, snippet size, and content type limits enforced by the server-side adapter

The model does not permit broad host allowlists, arbitrary path traversal, browser-supplied URLs, or search-engine queries.

## Current/Public Citation Requirements

Every retrieved current/public citation must expose:

- title
- source URL or stable reader target
- retrieval timestamp
- source type
- trust label
- freshness label
- claim boundary

Current/public citations must be visually and semantically distinct from package citations. They must not be merged into package citation counts, context-pack authority, CLM authority, or owner-validated internal evidence.

## Claim Boundary Requirements

Current/public source claims may support only the bounded current context they actually state.

They must not:

- approve a tool, model, vendor, data class, workflow, or production use
- resolve package/current conflicts by themselves
- override approved package guidance
- become package authority
- become enterprise policy
- stand in for owner validation of internal claims
- hide retrieval, freshness, trust, or source boundary metadata

When package and current/public sources conflict, the answer must label the conflict and preserve both source lanes.

## Environment And Configuration Model

Production configuration must happen outside the repository through the deployment environment.

Expected server-side names:

- `AICD_CURRENT_CONTEXT_ADAPTER`
- `AICD_CURRENT_CONTEXT_SOURCE_REGISTRY_JSON`
- `AICD_CURRENT_CONTEXT_MAX_REFS`
- `AICD_CURRENT_CONTEXT_RESPONSE_BYTE_LIMIT`
- `AICD_CURRENT_CONTEXT_SNIPPET_CHAR_LIMIT`
- `AICD_CURRENT_CONTEXT_TIMEOUT_MS`

The repository may document these names, but it must not store production values, tokens, cookies, source credentials, private URLs, internal hostnames, or deployment-specific registry JSON.

Production enablement requires setting `AICD_CURRENT_CONTEXT_ADAPTER` to `allowlisted_public_fetch` outside the repository and supplying an owner-approved registry outside the repository. This issue does not do that.

## Production Enablement Checklist

Before production retrieval can be enabled, a later issue must provide evidence that:

- owner-approved registry entries exist outside the repo
- every entry passes the registry validator
- every entry is HTTPS-only, credential-free, and bounded by exact origin and path prefix
- every entry has source owner, approver, approval date, review due date, trust label, freshness label, and claim boundary
- every entry preserves `not_package_authority` claim boundary
- an Access-authenticated Production runtime smoke receipt passes for the current AI RMF plus NIST SSDF baseline before any source expansion
- Access and WAF posture is reviewed separately without repo-side changes unless explicitly scoped
- package-only remains default
- Package + current context remains explicit
- no-package prompts refuse before current retrieval and provider execution
- disabled or unconfigured retrieval still returns the Not retrieved path
- rollback can remove the adapter setting or registry value without code changes

## Smoke Test Checklist

Production smoke must include:

- Controlled unauthenticated Cloudflare Access denial for `/api/source-grounded-chat`.
- Access-authenticated provider-backed `/api/source-grounded-chat` execution before activation continues.
- Package-only remains default.
- Package-only supported prompt routes through `/api/source-grounded-chat`.
- Package + current context remains explicit.
- With retrieval disabled, Package + current context returns a visible `Current/public source says` not-retrieved diagnostic.
- External retrieval count remains `0` while disabled.
- Current/public citation count remains `0` while disabled.
- Unsupported or no-package prompt blocks current retrieval and provider execution.
- Direct browser provider calls remain `0`.
- Direct browser current-source calls remain `0`.
- No secrets are rendered.
- After a later approved enablement, current/public citations show retrieval timestamp, source type, trust label, freshness label, and claim boundary.
- After a later approved enablement, redirects outside allowed origin or path fail closed.

## Rollback Checklist

Rollback must be possible without code changes:

1. Set the current-context adapter back to disabled or remove the adapter setting in the deployment environment.
2. Remove or clear the deployment registry value.
3. Redeploy or refresh the environment according to the deployment platform.
4. Smoke Package + current context and confirm the `Current/public source says` lane reports that current/public context was not retrieved.
5. Confirm external retrieval count `0`.
6. Confirm current/public citation count `0`.
7. Confirm direct browser current-source calls `0`.
8. Record rollback evidence in the production enablement issue or receipt.

## Retirement And Removal Criteria

Remove or retire a source when:

- review due date passes without owner review
- source ownership is unclear
- source changes ownership, URL shape, access posture, or publication policy
- source adds credentials, cookies, private routing, or unacceptable tracking requirements
- source starts redirecting outside the approved origin or path prefix
- source becomes stale for the claim it supports
- source content drifts into vendor approval, production approval, policy approval, or internal-source claims
- source returns unsafe content type, oversized content, or repeated errors

Retired sources must not remain in production configuration.

## Residual Risks

- Public sources can change after review.
- Freshness labels do not prove that a source is current at answer time unless retrieval timestamp and source content support the claim.
- The adapter can prove bounded retrieval behavior, but it cannot prove semantic truth by itself.
- Owner approval can become stale if review cadence is missed.
- Current/public citations may be mistaken for package authority unless answer rendering preserves source-lane separation.
- Production smoke can miss later redirect or content drift.

## Explicit Non-Goals

This runbook does not:

- enable production current retrieval
- modify Cloudflare configuration
- modify Cloudflare Access or WAF
- add arbitrary web search
- add browser-side current-source calls
- add user-provided URL retrieval
- add durable telemetry, database, vector store, Supabase, uploads, or session attachments
- expose secrets
- approve any specific public source for production
- promote current/public sources into approved package authority
- bypass the Access-authenticated Production runtime smoke gate
- authorize `codex-automerge`