Maintenance — inclusion, evidence, and review¶

Last updated: 2026-09 · owner: Youngjin · volatility: medium

L0 TL;DR: Separate relevance, release status, evidence, permitted use, and support. Automation detects missing/inconsistent records; people own factual review and customer-site approval.

Inclusion criteria (THE FILTER)¶

The old “2 of 4” rule is now only a relevance signal: customer demand, AWS mapping, release status, and site cases. AWS mapping plus a roadmap does not establish verification.

Inclusion requires all of: (1) a customer problem or R&D question, (2) exact primary source/check date/version, (3) evidence, limits, and permitted use, (4) an owner and actionable next step. Numbers need conditions, samples, and units. Items without primary-source checks stay in Radar.

Research can support hypothesis-driven R&D guidance, not operational performance promises. Expansion recommendations additionally need the pilot card and site gates.

Maturity, sources, and use¶

Dimension	Label	Interpretation
Release	GA / Preview / Research / not applicable	Per product; do not label principles, laws, or algorithms GA
Evidence	Vendor announcement / source comparison / reproduction / customer-site validation	Do not infer the next stage automatically
Use	Learning/R&D / PoC evaluation / operational expansion review	Record validated scope and limitations
Support	AWS service / model provider / partner-SI / sample maintainer	Separate contracts and site responsibilities

[1] official documentation/paper, [2] documented reproduction, [3] vendor announcement, [4] unverified are source types, not a ranking or official AWS endorsement. [2] requires operator, versions, environment, logs, and measurement conditions. Legacy [2] without logs is not reproduction evidence. An announcement is not GA; one run is not production validation.

Metadata and freshness¶

Keep page _owner: name · updated: YYYY-MM · volatility: high/medium/low_ metadata. This date describes the page edit/review scope; partial edits do not refresh unrelated claim dates. Page badges warn after high 1 / medium 3 / low 6 months.

Declared refresh paths. The metadata line names only who is responsible. Every nav page declares in the repository-root refresh.yml what triggers its refresh and who does it — mode (routine: scheduled automation / owner: periodic human review / event: on a specific change), by, trigger. Pages that follow an external source (e.g. News ← the AWS Physical AI blog RSS) declare source, and posts deliberately left out go into exclude with a reason. A missing declaration blocks deployment (check_refresh_paths.py), and GitHub Actions compares pages with their real sources daily, opening a source-drift issue for posts still missing 3 days after publication or for a stalled routine (check_source_drift.py). Badges watch dates; the watchdog watches sources — the 3-week News gap in 2026-10 prompted this rule. Owner-reviewed pages such as the technology pillars declare review_alert: true, so when the metadata updated passes its volatility deadline the watchdog raises it on the same source-drift issue instead of stopping at a badge. It reads the review month the owner wrote, not commit dates, so restructuring or translation commits do not count as a review — two months without pillar review in 2026-11 prompted this.

Add decision-critical claims to evidence records. checked_on is the source comparison date, review_after_days the claim review interval, and pages identifies affected summaries/pillars. Unmigrated legacy claims remain explicitly outside the register.

Standard template¶

Item / customer problem:
Release / evidence level / intended use / support owner:
L0: what it is and under which conditions it applies:
Alternatives / AWS mapping and prerequisites:
Evidence ID / exact source URL / version / check date:
Experiment: environment, sample, units, logs / reproducer:
Limitations / cost, success, and stop criteria:
Next action / execution asset / operating handover:
Owner / human reviewer or pending:

Keep L0 short; link or collapse details. Define unfamiliar terms with a first-use [^term] and 1–2 sentences under the final  marker. Preserve footnote IDs, URLs, and structure in translations. Executive summaries must retain pillar conditions/limits. Keep internal customer information and sales strategy out of public pages.

Playbook promotion pipeline¶

Record topic, primary source, and customer problem in Radar or the candidate form.
Owner checks inclusion requirements and assigns specialist review; scans cannot promote automatically.
Compare evidence, versions, dates, and measurement conditions; state R&D/PoC/site-validation scope.
Update Korean originals, affected summaries, and en/zh/ja together.
Render evidence, sync hashes, run checks, then review and integrate.

Roles and outstanding review¶

Role	Responsibility
Owner Youngjin	Assign reviews, decide inclusion, manage updates
Human specialists — unassigned	Licensing / AWS services-Regions / robotics-safety / reproduction
Automation/comparison tools	Candidate intake, assisted source comparison, metadata/link/sync checks

Naming one owner does not resolve review bottlenecks. Record specialist owners after they accept. Distinguish automated comparison from human approval; never invent reviewers.

Checks and limitations¶

python3 scripts/check_evidence.py
python3 scripts/check_translation_sync.py
python3 scripts/check_nav_index_sync.py
python3 scripts/check_refresh_paths.py
python3 scripts/check_staleness.py --check
mkdocs build --strict

Invalid evidence/rendering, nav drift, undeclared refresh paths, missing metadata, and internal document link/anchor errors block deployment. Overdue/human-pending review is reported; translation drift is currently warn-only in CI. Separately require zero translation drift before commit. Builds do not verify external reachability, facts, translation meaning, or robot execution.

➡️ Next action: assign pending evidence reviews by specialty and review the earliest-due sources with every affected page.

owner: Youngjin · updated: 2026-09 · volatility: medium