2. Component lifecycle

Local snapshot only. The workspace page is authoritative.

Draft for core working team validation: The proposed Alpha, Beta, and Stable maturity model in this section has not been approved. The core working team must validate the maturity names, definitions, evidence thresholds, and relationship to package versions and release channels before they become governed PDS policy.

2.1 Core and Extended ownership

PDS separates shared-system work from reusable product-owned work.
Core contains shared-system work that PDS governs and intends to support as common infrastructure.
Extended contains reusable product-owned work that may serve more than one screen or team but remains owned and maintained by the contributing product team.
A product-owned component may enter Core assessment before or after production use. Existing use provides adoption and consumer evidence. It does not automatically make the component Core, establish its maturity, transfer ownership to PDS, or create a PDS delivery commitment.
Core classification follows the governance and decision-gate model in section 1. The Design Ops Lead and Design Ops Product Designer jointly assess Core need and classification. The Design Ops Lead resolves a tie.
When a product-owned component is accepted for Core development:

• the work must become an approved PDS backlog item;
• its scope, priority, ownership, required evidence, and delivery capacity must be recorded;
• the PDS Lead Maintainer must confirm that the technical work and required review can be supported;
• any contributor allocation must follow the capacity and forecasting controls in section 1.8.
  Acceptance into Core does not mean that implementation starts at once. Delivery depends on backlog priority, confirmed capacity, technical sequencing, and maintainer review capacity.
  PDS assumes responsibility for developing and maintaining the new shared PDS component. The product team continues to own its existing local implementation until:

1. PDS publishes a suitable shared component;
2. the product team decides that migration is suitable;
3. product-team and PDS capacity support the migration; and
4. any required migration work is prioritized and assigned.
   There is no automatic migration deadline. Local implementation debt, defects, support, accessibility, and maintenance remain with the product team until it migrates.

2.2 Separate lifecycle dimensions

Every tracked component must record these dimensions separately:

1. Layer: Core or Extended.
2. Maturity: proposed Alpha, Beta, or Stable state for Core PDS components.
3. Readiness evidence: pass, partial, fail, unknown, or not applicable for each required gate.
4. Support level: guidance, review, joint contribution, or PDS-owned implementation.
5. Production adoption: known product use, consumers, and adoption evidence.
6. Package and version state: current published version, package location, and release state when known.
7. Delivery state: backlog, assigned, active, in review, paused, released, or another state approved by the core working team.
   These dimensions must not be treated as interchangeable.
   Core membership does not mean Stable. A Core component may be Alpha, Beta, or Stable under the proposed model.

• Layer states who owns and governs the shared work.
• Maturity states what evidence supports its use.
• Readiness shows the status of each required gate.
• Support level states the type of help PDS has agreed to provide.
• Adoption records where and how the component is used.
• Package state records how the component is distributed.
• Delivery state records its current place in the work process.
  A component’s assignment to a contributor, pull-request status, merge status, publication, package version, or production use does not automatically change its layer or maturity.
  Until the maturity model is approved, current components should be recorded as Assessment incomplete, with known evidence, gaps, ownership, consumers, support level, package state, and linked backlog work made visible.

2.3 Proposed Alpha contract

Alpha is proposed as a state for discovery, evaluation, controlled prototyping, and early technical validation.
Alpha is not recommended or supported for general production use as a PDS component.
Alpha would require:

• a name and stated purpose;
• an accountable PDS owner;
• a visible Alpha or Assessment incomplete warning;
• a design or Storybook artifact sufficient for evaluation;
• preliminary anatomy, behaviour, or API information;
• known gaps, risks, and constraints;
• baseline automated checks that are currently available and applicable;
• accessibility and localization evidence completed to date;
• known consumers or test contexts, when any exist;
• a feedback route;
• linked backlog work for known gaps that PDS intends to address.
  Alpha APIs and behaviour may change incompatibly until the core working team approves the relationship between maturity, package versions, and release channels.
  Consumers must not infer compatibility, package stability, production readiness, or future support from Alpha status.
  Each current component that has not been assessed should be marked Assessment incomplete. Its record should list missing design, engineering, accessibility, localization, documentation, installation, consumer, ownership, and package evidence.

2.4 Proposed Beta contract

Beta is proposed as a state permitted for limited production use by informed product teams.
Beta would require:

• design-quality and technical go decisions;
• documented behaviour, API, dependencies, usage, and known limits;
• automated tests appropriate to the component;
• baseline automated accessibility checks;
• keyboard, focus, semantic-markup, and contrast review;
• no known critical accessibility defect;
• a named maintenance owner and support route;
• at least one pilot or realistic production-equivalent integration;
• known consumer and package information;
• a clear list of evidence still required for Stable;
• disclosure of any incomplete manual QA, accessibility, localization, responsive, or adoption evidence.
  The affected domain owners determine which gates are required for a specific component. Each required owner reviews and approves only the evidence within its accountable area.
  Beta approval does not grant merge, release, deployment, or publication authority. Those actions remain with the PDS Lead Maintainer and the release controls defined elsewhere in this operating model.
  The core working team must decide how breaking changes to Beta components relate to SemVer, prerelease versions, package channels, and consumer notice requirements.

2.5 Proposed Stable contract

Stable is proposed as PDS’s fully production-ready maturity state.
Stable would require recorded approval for every applicable domain and evidence of:

• approved design behaviour, variants, states, content, and Figma parity;
• engineering review of architecture, API, dependencies, maintainability, tests, and package safety;
• automated accessibility checks;
• qualified manual accessibility evidence where required;
• keyboard and focus behaviour;
• semantics, names, roles, states, and values;
• contrast, reflow, zoom, and flexible-content behaviour;
• supported assistive-technology behaviour where applicable;
• visual regression testing;
• responsive behaviour across supported viewports;
• applicable fr-CA localization and accessibility checks defined in section 7;
• complete Stable documentation;
• installation and use through the supported shared library;
• a named maintenance owner and support route;
• a declared package version and compatibility impact;
• evidence from at least one consuming application or realistic production-equivalent pilot;
• no unresolved defect or risk that prevents supported production use.
  The Design Ops Product Designer provides the design-quality decision. The PDS Lead Maintainer provides the technical decision and confirms package and release safety. QA/SDET or another qualified owner provides assigned manual quality or accessibility evidence when that evidence is required.
  Unavailable QA/SDET support does not count as approval. When required evidence cannot be produced, the component remains in its current maturity state until the work is scheduled and completed.
  Multi-team use may strengthen Core priority, reuse evidence, and confidence in maintenance value. It is not proposed as a requirement for Stable. Adoption remains separate from maturity.
  Stable status does not guarantee that every product team must adopt the component or migrate by a fixed date.

2.6 Assessment, promotion, and handoff

The component-health record is the source for lifecycle assessment and maturity promotion. It must link the applicable:

• design evidence;
• code and technical evidence;
• documentation;
• accessibility evidence;
• localization evidence;
• installation and package evidence;
• consumer and adoption evidence;
• ownership and support information;
• version and compatibility information;
• defects, risks, and linked backlog work;
• required domain decisions.
  The Design Ops Lead identifies the required decision gates with input from the affected domain owners.
  Each domain owner issues its own go or no-go decision. A domain owner may not approve evidence outside its accountable area or overrule another domain’s no-go.
  The Product Manager maintains the lifecycle record, decision results, owners, dependencies, and follow-up work. Each domain owner remains accountable for the accuracy of its evidence and approval.
  The Design Ops Lead confirms the maturity governance outcome only after every required gate has passed.
  A no-go leaves the component in its current state. The accountable domain owner must record the unmet condition and evidence needed for reconsideration.
  Contributor implementation, pull-request approval, merge, publication, package distribution, and production use may provide evidence. None automatically changes a component’s layer, maturity, support level, or governance status.
  Promotion does not itself authorize merge, publication, or release. The PDS Lead Maintainer retains technical-review, merge, package, and release authority.
  When a product-owned component is accepted for Core development, the handoff record must include:
• the user, product, or system need;
• reuse and consumer evidence;
• source and design files;
• component behaviour and variants;
• API and dependencies;
• tests;
• accessibility and localization results;
• documentation;
• known defects, gaps, and risks;
• known consumers;
• version and release history;
• expected maintenance and review cost;
• current local owner;
• intended PDS owner;
• proposed support level;
• migration assumptions;
• linked PDS backlog item.
  The PDS Lead Maintainer assesses technical fitness, review demand, and the work needed to convert the local implementation into supported shared infrastructure.
  The handoff transfers responsibility for developing the new shared PDS component only after PDS accepts and prioritizes that work. It does not transfer responsibility for the product team’s existing local instance.
  A voluntary contributor may help complete approved handoff or implementation work only through an assigned PDS backlog item. The assignment does not change lifecycle ownership or create committed delivery capacity unless a formal allocation is recorded.
  Components that remain incomplete at the end of FY27 retain their recorded state, unmet gates, owner, support level, known consumer exposure, package state, and linked backlog work.
  FY27 closure records completed evidence and remaining work. It does not create an FY28 delivery promise unless priority, capacity, maintainer review, and any required specialist support are confirmed.

2.7 Deprecation and removal

Under the proposed lifecycle model, PDS uses these states:

1. Stable
2. Caution or intent to deprecate: New adoption is discouraged. The reason, risk, and supported alternative are named.
3. Deprecated: Normal feature development ends. The replacement, migration guidance, support limits, and intended removal version or date are published.
4. Removed: The asset is no longer distributed in the supported package line.
   Deprecation status is separate from Alpha, Beta, and Stable maturity. A component does not become less mature when it is deprecated. Deprecation records whether PDS intends to continue supporting and distributing it.
   An asset enters deprecation review when it:

• has a supported replacement;
• conflicts with current standards;
• duplicates a healthier pattern;
• lacks a maintainable owner;
• has low value compared with its maintenance cost;
• carries unresolved risk that PDS cannot support; or
• depends on technology or packages that can no longer be maintained safely.
  Lack of an owner triggers review rather than automatic removal.
  The Design Ops Lead owns the deprecation governance decision and confirms the required gates.
  The Design Ops Product Designer provides the design-quality decision when design behaviour, guidance, content, or replacement suitability is affected.
  The PDS Lead Maintainer confirms consumer impact, technical risk, replacement feasibility, package impact, release impact, and removal safety.
  QA/SDET or another qualified domain owner provides quality or accessibility evidence when that evidence is required for the decision. Lack of available support is not approval by silence.
  The Product Manager maintains the decision record, migration dependencies, consumer notice plan, target dates, and follow-up work.
  The decision follows the domain go or no-go model in section 1.5. It is not made through majority voting.
  Removal may occur only after the applicable migration, notice, compatibility, and release requirements in section 4 have been met. Whether removal requires a major release remains subject to the package and maturity mapping decision in section 2.8.

2.8 Open decision: package and maturity mapping

The core working team must decide how the proposed Alpha, Beta, and Stable states map to package versions and release channels, including:

• 0.x and 1.x+ versions;
• prerelease tags;
• separate packages;
• component-level metadata;
• existing engineering release channels;
• breaking changes during Alpha and Beta;
• consumer notice requirements;
• the release treatment of deprecation and removal.
  The PDS Lead Maintainer should first document the package versions, distribution methods, release channels, prerelease methods, and compatibility rules already in use.
  The core working team can then assess whether the proposed maturity model fits the current technical model or needs to change.
  Until this mapping is approved:
• maturity labels must not be used to infer SemVer compatibility;
• package versions must not be used to infer maturity;
• Alpha, Beta, Stable, Deprecated, and Removed must be recorded as governance metadata separate from package state;
• removal must follow the safest applicable release and consumer-notice process confirmed by the PDS Lead Maintainer.