8. Audit and review cycle

Local snapshot only. The workspace page is authoritative.

8.1 Component-health record

Every Core component has one component-health record covering:

• layer and maturity;
• accountable owners and delegates;
• design source and Figma parity;
• code, package, dependency, and test state;
• documentation completeness;
• accessibility evidence;
• localization evidence;
• installation evidence;
• version, deprecation, and replacement state;
• known consumers and product evidence;
• unresolved gaps and linked remediation work;
• last review date.
  Each dimension is recorded as pass, partial, fail, unknown, or not applicable, with an evidence link and owner. Unknown is not pass.
  The structured Jira component-health record is the authoritative operational audit artifact. Governed Markdown, documentation badges, dashboards, quarterly reports, and machine-readable status output are generated from or linked to that record rather than maintained as independent status copies. This adapts Pajamas’ issue-based component-health matrix to PDS’s existing work-management context. (Pajamas)

8.2 Baseline and recurring review

FY27 completes one full baseline assessment of the current library. After the baseline:

• an affected health dimension is updated whenever a component changes or releases;
• the standing working group performs lightweight triage every two weeks;
• the full portfolio receives a quarterly review;
• public accessibility status and other time-sensitive statements are reviewed at least every six months.
  The fortnightly review covers new gaps, lifecycle changes, blocked evidence, deprecations, owner changes, and priority decisions. The standing working group remains the Design Ops Lead and Design Ops Product Designer. Engineering, QA/SDET, DevOps, and product owners provide or review domain evidence only for affected items.

8.3 Extended-component visibility

Every known Extended component is registered with:

• owning team and contact;
• source links;
• known products and consumers;
• Core dependencies;
• support and lifecycle warning;
• known gaps;
• last confirmation date.
  Owners reconfirm the record quarterly. A stale or ownerless entry is flagged for review, not automatically removed. The Design Ops Lead may initiate Core assessment when repeated use or duplication indicates system value, but registration does not imply Core candidacy.

8.4 Findings and remediation

Every failed or partial audit dimension links to a remediation item containing:

• component and failed dimension;
• evidence;
• severity or lifecycle impact when known;
• accountable owner;
• support level;
• target release or review date;
• dependencies;
• current status.
  The Design Ops Lead prioritizes governance, design-system value, and backlog placement. The Design Ops Product Designer owns design remediation evidence. The PDP engineering lead owns technical remediation evidence and release impact. Product teams own findings in their local implementations. Borrowed QA/SDET owns only the evidence or finding it accepts.
  Audit findings may trigger a bug, readiness gap, ownership escalation, migration task, maturity change, support change, or deprecation review. No status change occurs without the required domain gates.

8.5 Inner-source contribution review

The fortnightly review includes the contribution pipeline without treating voluntary effort as committed delivery capacity. It reviews:

• Ready-for-contribution items with no claimant;
• claimed items with no current progress or check-in;
• open pull requests awaiting contributor changes, maintainer review, or domain evidence;
• Danielle’s technical review queue and any resulting delivery bottleneck;
• failed or bypassed repository checks;
• merged work awaiting a governed release;
• ownership or maintenance obligations created by accepted contributions;
• work that should be returned, reassigned, split, deprioritized, or moved into protected capacity.
  The Design Ops Lead decides backlog action. The PDS Lead Maintainer decides technical review, reassignment feasibility, merge readiness, and whether a maintainer delegate is appropriate. Contributor count, pull-request count, and lines of code are operational observations, not FY27 success targets.

8.6 Deprecation review

The audit initiates deprecation review when an asset has a supported replacement, conflicts with current standards, duplicates a healthier pattern, lacks a maintainable owner, or has risk PDS cannot support.
The Design Ops Lead owns final deprecation governance. The Design Ops Product Designer owns the design-quality gate. The PDP engineering lead confirms consumer impact, replacement feasibility, migration, and removal release. Borrowed QA/SDET provides an accessibility gate when the deprecation is based on or affects its evidence. All required domains must say go; no majority vote is used.
The published decision includes the reason, alternative, migration guidance, notice, and intended removal version or date.