Source metadata and tooling verification dispositions.

This launch-readiness review decides how frontmatter, templates, compatibility row states, review-note pages, search and status source data, doc icons, generated metadata, validation scripts, and automation fixtures keep or bound Verification Required before final launch acceptance.

Decision Snapshot

Tooling groups: 9
Customer defaults kept: 5
Validation checks: 7
P0/P1 blockers: 0
Open lanes: 1

Tooling Dispositions

source metadata and tooling Verification Required decisions
Surface	Current exposure	Disposition	Rationale	Review basis
Maturity label metadata	The shared metadata defines Verification Required, description text, and search facet value.	Accept with limits	The label is needed by reviewed pages and should weaken claims by requiring evidence or reviewer approval before publication.	Review records
Markdown frontmatter schema	Frontmatter schema and metadata validation allow Verification Required while rejecting publishable TODO values.	Accept with limits	Review-bound pages need the label, but publishable docs must carry exact owner, audience, evidence, and last-reviewed values.	Review record
Page templates	Authoring templates include Verification Required in TODO maturity, evidence, source-status, and row-status examples.	Accept with authoring limits	Templates are not public promises; they require writers to replace placeholders and explain maturity before a page ships.	Review records
Compatibility model	Compatibility rows keep verification-required as a status and allow item-level Verification Required maturity.	Accept with row-level limits	Status and maturity stay separate so active partial or unsupported behavior is not confused with an approved support claim.	Review records
Reference and review-note models	Reference schema and review-note pages allow verification-required source status, pending records, and item-level maturity.	Accept with evidence limits	Review records should block stronger public wording until the owning reviewer accepts the exact claim.	Review records
Search and status models	Search facets, status records, and maturity filters expose the label where accepted pages or product surfaces need review visibility.	Accept with entry-point limits	Search and status help readers find review-bound content, while home and primary navigation avoid making the label the first product message.	Review records
Doc icons and fallbacks	The icon taxonomy includes a verification-required icon and VR fallback for status and compatibility surfaces.	Accept with visual limits	Icons improve scanning but never prove support, security, compliance, or maturity; local fallbacks keep the UI readable.	Review record
LLM and SEO generated metadata	Generated route manifests infer conservative maturity strings and include Verification Required in public-route summaries.	Accept with export limits	Machine-readable exports use public URLs only and require readers to confirm exact behavior on canonical pages.	Review records
Validation scripts and automation	Validators count label exposure, block deprecated aliases, require disposition rows, and test entry-point behavior.	Accept with QA limits	Automation should prove taxonomy and customer-entry behavior without turning fixtures into product commitments.	Review records

Customer-Facing Exposure Rules

Rules for keeping source metadata and generated surfaces clear
Rule	Required behavior before launch
Keep labels useful, not evasive	Verification Required must point to a limit, review-note path, owner, reviewer, or unresolved boundary.
Keep defaults reader-safe	Home, primary navigation, and generic entry points should not lead with the label unless the page body explains the reader task and boundary.
Keep generated metadata conservative	LLM and search summaries may expose the label, but they must use public routes and send readers to canonical pages for exact behavior.
Keep templates out of production copy	Template TODO values are allowed only inside templates; publishable docs must replace them with exact maturity, owner, evidence, and last-reviewed values.
Keep row and page maturity separate	Compatibility rows can carry their own status and maturity when the page explains the split.

Launch Blocking Rules

Source metadata and tooling blocker rules
Severity	Condition	Required action
P0	Tooling or generated metadata exposes private source paths, credentials, customer data, internal systems, raw support review details, or private topology.	Remove the exposure before launch review continues.
P1	A default template, generated summary, search/status record, icon, validation fixture, or compatibility taxonomy makes Verification Required sound like approved support, security, legal, durability, availability, performance, scale, compliance, GA, or contract posture.	Review record
P2	Source metadata or tooling keeps Verification Required as an allowed value while nearby copy, route dispositions, or validators keep customer-facing scope bounded.	Accept with limits and keep the owner or review-note path visible.
P3	README, project-management, audit, generated manifest, or automation text mentions the label as taxonomy, tracking, or validation process.	Review record

Remaining Boundary

Final launch acceptance

Still owns

Exact release commit, final validation command output, reviewer signoffs, unresolved risks, launch watch samples, environment evidence, and go/no-go decision.