Local snapshot only. The workspace page is authoritative.
Purpose
This document extracts the governance choices embedded in the Proposed Operating Model and governance draft.
The register is ordered by dependency. Later decisions should not be finalized until the earlier decisions they depend on are sufficiently clear. A decision may be piloted before final approval, but the pilot must identify what is being tested and must not be represented as settled governance.
Domain labels
The proposed lead identifies the discipline best positioned to prepare the decision. It does not grant approval authority.
Label
Meaning
Design Ops
System purpose, experience quality, design governance, Core scope, priority, service model, and design evidence
Development
Architecture, implementation, repository, API, package, compatibility, automation, merge, distribution, and technical support
Joint
A decision that changes both the governed experience and its technical contract; Design Ops and Development must align
QA / accessibility
Manual quality, assistive-technology, regression, evidence quality, and defect consequences
Program / capacity
Staffing, protected allocation, planning, dependencies, recordkeeping, and escalation
Product teams
Product evidence, local implementation, adoption, migration, and consumer responsibilities
## Decision sequence
1. Acknowledge the established mandate and PDS 1.0 direction; resolve questions of understanding only.
2. Confirm the team, authority, decision method, and capacity.
3. Inventory the system that already exists.
4. Establish intake, Core assessment, priority, and service levels.
5. Establish component ownership, maturity, promotion, and retirement.
6. Establish inner-source contribution and repository governance.
7. Establish technical compatibility, release, distribution, and support.
8. Establish documentation and source-of-truth governance.
9. Establish token and naming governance.
10. Establish accessibility, localization, and QA assurance.
11. Establish health reviews, telemetry, remediation, and success measures.
12. Pilot the model, resolve remaining decisions, and ratify the operating baseline.
---
## 1. Established mandate and PDS 1.0 direction
This section is context for the Core team. These items are not Core-team decisions and should not be placed on the alignment agenda for approval.
ID
Established direction the Core team must understand
CTX-01
PDS exists to reduce duplicated UI work, inconsistent experiences, fragmented accessibility confidence, and unmanaged adoption risk by providing governed shared design and coded infrastructure.
CTX-02
PDS covers the shared coded component library, design assets, tokens, documentation, contribution process, and operational records.
CTX-03
Product feature design, journeys, local delivery, and accessibility of the assembled product remain product-team responsibilities except where a team proposes, consumes, extends, or contributes PDS work.
CTX-04
PDS 1.0 is the path toward a stable, versioned and supportable PDS release with a validated installation method, initial self-serve documentation, and components assessed against production-readiness criteria. It does not require every current component to become Stable at the same time.
CTX-05
FY27 success is readiness and enablement. Adoption, downloads, migrations, and component-use counts are contextual observations rather than performance targets.
CTX-06
PDS is recommended and voluntary in FY27. Any later move to a default standard for new work requires a separate future governance decision.
CTX-07
PDS is an internal the company inner-source initiative. Repositories, packages, documentation, and contributions remain limited to authorized the company access.
**Comprehension check:** Does any Core-team participant need clarification about these established boundaries before the team begins making the decisions in section 2? Questions are recorded and clarified; these items are not reopened for approval.
## 2. Confirm the team, authority, decision method, and capacity
These decisions must precede any lifecycle or release gate because every later control depends on a named accountable role.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
TEAM-01
What is the distinction among the **Core team**, **standing working group**, **delivery team**, and people who participate only when their domain is affected?
Design Ops
Program, Development
Team topology and glossary
TEAM-02
Who attends the recurring FY27 forum: Tyler Skrabek, Laura Vo, Thomas Petitjean, Scott Yu, Danielle Perazzolo, and/or other roles?
Design Ops
Program, Development
Named membership and attendance model
TEAM-03
Which members hold governance or domain go/no-go authority, and which members coordinate planning, staffing, records, or evidence without a gate?
Design Ops
Development, Program, QA
Decision-rights matrix
TEAM-04
What final-governance responsibilities belong to the Design Ops Lead, and which design-quality decisions belong to the Design Ops Product Designer?
Design Ops
Development
Design Ops authority boundary
TEAM-05
How are individual Core-need and Core-classification decisions made, and what does the Design Ops Lead’s tie-breaking authority apply to?
Design Ops
Development
Core-classification decision rule
TEAM-06
Which technical decisions belong to Danielle as PDS Lead Maintainer, and which remain with a Software Development Manager, PDP engineering leadership, DevOps, or another maintainer?
Development
Program, Design Ops
Engineering authority and escalation map
TEAM-07
How are responsibilities divided between the Product Manager and Software Development Manager for planning, capacity, staffing, commitments, dependencies, risks, and decision records?
Program / capacity
Design Ops, Development
PM/SDM responsibility matrix
TEAM-08
Who protects the equivalent of two developers’ FY27 capacity, who assigns people, and whether Danielle represents all or only part of that allocation?
Program / capacity
Development, Design Ops
Named FY27 capacity agreement
TEAM-09
Which QA/SDET, accessibility, and DevOps judgments are binding domain gates, and when are those roles advisory or evidence-producing only?
Joint
QA, Development
QA/DevOps authority map
TEAM-10
How does the Core team determine which domains are affected by a decision or release?
Joint
QA, Product teams
Domain-applicability checklist
TEAM-11
Does an outcome require unanimous go decisions from every affected domain, and what precisely happens after a no-go?
Joint
QA, Program
Go/no-go procedure and remediation state
TEAM-12
Which decisions may be delegated, to whom, for how long, and which responsibilities must wait for the accountable owner?
Joint
Program, QA
Delegation template and non-delegable-authority list
TEAM-13
Who may act when Tyler, Laura, Danielle, QA/SDET, DevOps, the PM, or the SDM is unavailable?
Joint
Program
Role-specific continuity plan
TEAM-14
What is the recurring meeting cadence, agenda, chair, quorum or required attendance, and path for decisions that cannot wait?
Design Ops
Program, Development
Core-team operating calendar and agenda
TEAM-15
Who creates, maintains, corrects, and approves decision records, the backlog, delivery plan, roadmap, and risk/dependency log?
Program / capacity
Design Ops, Development
Record stewardship matrix
TEAM-16
What information is the company-visible, what remains restricted, and how are decisions and roadmap changes communicated?
Design Ops
Program, security
Visibility and communication policy
## 3. Inventory the system that already exists
The Core team should document current reality before choosing future package, lifecycle, token, support, or audit rules.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
INV-01
What components, patterns, design assets, tokens, packages, repositories, Storybooks, documentation sites, and pipelines currently exist?
Joint
Product teams, DevOps
Baseline system inventory
INV-02
Who currently owns and maintains each asset, and which assets have no credible owner?
Design Ops
Development, Product teams
Ownership register
INV-03
Which package versions, tags, channels, registries, credentials, build pipelines, and install paths operate today?
Development
DevOps, Product teams
Current distribution map
INV-04
Which product teams consume which components, tokens, packages, or local forks, and how reliable is that evidence?
Product teams
Development, Design Ops
Declared-consumer register with confidence level
INV-05
Which current components have design, engineering, documentation, accessibility, localization, installation, and production evidence?
Joint
QA, Product teams
Component-health baseline
INV-06
What current token categories, aliases, modes, identifiers, breakpoints, outputs, duplicates, literals, and platform targets exist?
Joint
Development
Token inventory
INV-07
Which local reusable components should be registered as Extended, and what information must each product team supply?
Design Ops
Product teams, Development
Extended-component registry
INV-08
Which current claims cannot be verified and must be marked unknown rather than treated as passing evidence?
Joint
QA, Program
Evidence-gap and discovery backlog
## 4. Establish intake, Core assessment, priority, and service levels
These decisions determine how work becomes eligible for PDS attention before anyone designs or codes it.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
INT-01
Will PDS operate one intake and one ordered backlog, and which system will hold them?
Design Ops
Program, Development
Intake form and authoritative backlog
INT-02
Which request types must intake support: defects, new reusable work, modifications, documentation, tokens, accessibility/localization findings, adoption support, AI findings, and Core assessment?
Design Ops
Development, QA, Product teams
Request taxonomy and routing rules
INT-03
What minimum evidence must accompany a new or changed reusable-component proposal?
Design Ops
Development, QA, Product teams
Proposal template
INT-04
What happens to incomplete submissions: discovery, missing-evidence status, return to requester, or another route?
Design Ops
Program
Intake state model
INT-05
What criteria establish a Core need, and how is system fit kept separate from technical feasibility and maturity?
Design Ops
Development
Core-assessment rubric
INT-06
What technical feasibility, dependency, package-fit, implementation, and maintenance evidence is required before a proposal becomes a Core candidate?
Development
Design Ops
Technical feasibility checklist
INT-07
Which factors determine backlog priority: system value, evidence, risk, demand, accessibility, duplication, consumer impact, and protected capacity?
Design Ops
Program, Development
Prioritization rubric
INT-08
What support levels will PDS offer—guidance, review, joint contribution, and PDS-owned implementation—and what does each include or exclude?
Design Ops
Development, Program
Service catalogue and support-level contracts
INT-09
Who may make dated delivery commitments, and how are support level, priority, and delivery date kept separate?
Program / capacity
Design Ops, Development
Commitment and forecasting rule
INT-10
What may a product team build locally when PDS cannot meet its timeline, and what registration or evidence is still required?
Design Ops
Product teams, Development
Local-solution and Extended-registration policy
INT-11
What acknowledgement and classification response expectations can PDS credibly support?
Design Ops
Program, Development
Intake service expectations
INT-12
What role do office hours and informal conversations play without replacing intake or decision records?
Design Ops
Program
Office-hours charter
## 5. Establish component ownership, maturity, promotion, and retirement
These decisions create the component lifecycle independently of package versioning.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
LIFE-01
Will PDS track layer, maturity, readiness evidence, support level, production adoption, and package/version state as separate dimensions?
Joint
QA, Product teams
Component state model
LIFE-02
What exactly makes an asset Core versus Extended, and what ownership or support commitment follows each classification?
Design Ops
Development, Product teams
Core/Extended contract
LIFE-03
Can a product-owned implementation enter Core assessment while already in production, and what transfers to PDS at classification?
Joint
Product teams
Core-candidate handoff policy
LIFE-04
Who maintains the product team’s existing implementation while PDS develops and publishes a shared Core component?
Product teams
Design Ops, Development
Local/shared ownership record
LIFE-05
What Alpha, Beta, and Stable mean for production use, compatibility, support, evidence, and consumer risk?
Joint
QA, Product teams
Published maturity contracts
LIFE-06
What minimum design, engineering, documentation, accessibility, localization, installation, ownership, and pilot evidence gates each maturity state?
Joint
QA
Maturity checklists
LIFE-07
How are existing unassessed components represented without implying readiness?
Joint
Product teams
Initial-assessment status and warning
LIFE-08
What evidence and go/no-go results are required for promotion, and who records the final maturity state?
Joint
QA, Program
Promotion record and workflow
LIFE-09
How are no-go findings linked to remediation while preserving the current maturity state?
Joint
Program
Blocked-promotion/remediation workflow
LIFE-10
What must a product team provide when handing a candidate to PDS, including source, tests, defects, consumers, history, and maintenance cost?
Joint
Product teams
Core handoff template
LIFE-11
When and how may a product team migrate from its local implementation to the published PDS component, and is any deadline ever required?
Product teams
Design Ops, Development
Migration ownership policy
LIFE-12
What states and triggers govern caution, deprecation, and removal?
Design Ops
Development, QA, Product teams
Deprecation lifecycle
LIFE-13
What notice, replacement, migration guidance, consumer evidence, and release conditions are required before removal?
Joint
Product teams
Removal gate
LIFE-14
How are incomplete FY27 components and evidence carried into FY28 without implying a delivery promise?
Design Ops
Program, Development
Carryover rule and backlog fields
## 6. Establish inner-source contribution and repository governance
These decisions open implementation participation without automatically opening governance or release authority.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
CONT-01
Who may contribute, what authorization is required, and does contribution confer any governance, maintainer, merge, release, or support authority?
Joint
Program, security
Contributor eligibility and authority policy
CONT-02
What makes a backlog item **Ready for contribution**?
Joint
QA, Product teams
Ready-for-contribution checklist
CONT-03
Who decides which ordered backlog items are offered for contribution and who may return or split an item?
Joint
Program
Contribution-offering workflow
CONT-04
How does a developer claim work, who confirms assignment, and what must the assignment record contain?
Development
Program, Design Ops
Claim and assignment workflow
CONT-05
How are side-of-desk contributions distinguished from protected delivery capacity and excluded from unsupported forecasts?
Program / capacity
Development, Design Ops
Capacity-accounting rule
CONT-06
When is inactive work returned, reassigned, split, or moved into protected capacity?
Joint
Program
Stale-assignment rule
CONT-07
What may a contributor change without renewed Design Ops or technical approval, and how are scope changes handled?
Joint
Program
Contribution scope-change rule
CONT-08
Which code, tests, Storybook examples, Markdown, accessibility, localization, release-impact, and health evidence must accompany a contribution?
Development
Design Ops, QA
Pull-request evidence checklist
CONT-09
Who reviews code and each nontechnical domain, and how is self-approval prevented?
Joint
QA
Review and domain-approval matrix
CONT-10
What conditions permit merge, and how are merge, maturity promotion, and publication kept separate?
Development
Design Ops, QA
Merge-readiness gate
CONT-11
Who owns and maintains accepted shared code, and when can a contributor or home team accept an ongoing maintenance commitment?
Joint
Program, Product teams
Post-merge ownership agreement
CONT-12
What code-owner, branch-protection, access, automated-check, exception, traceability, and private-security-reporting controls must the repository enforce?
Development
Security, QA, Design Ops
Repository ruleset and security route
CONT-13
What review expectation can Danielle and any delegates support, and how is maintainer-review load escalated?
Development
Program, Design Ops
Review service expectation and capacity signal
CONT-14
Which contribution and maintainer documents must exist before the contribution path is opened?
Joint
Security, QA
README, contribution guide, templates, code ownership, technical setup, and definition of done
## 7. Establish technical compatibility, release, distribution, and support
These decisions require the current-state engineering inventory before the Core team can declare a PDS 1.0 release contract.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
REL-01
What is PDS’s public API: component APIs, token identifiers and meanings, generated assets, package entry points, or other documented contracts?
Development
Design Ops
Public-API inventory
REL-02
Will PDS use Semantic Versioning, and what qualifies as patch, minor, or major for components, tokens, behavior, generated assets, and documentation?
Development
Design Ops, Product teams
SemVer policy and change classifier
REL-03
How do Alpha, Beta, and Stable map—or deliberately not map—to `0.x`, `1.x+`, prerelease tags, packages, channels, or component metadata?
Development
Design Ops
Maturity/package/channel mapping
REL-04
What must be true before the first PDS 1.0 package or equivalent supported release is declared?
Joint
QA, Product teams, Program
PDS 1.0 release-readiness gate
REL-05
What are the target repositories, build pipelines, registries, credentials, publication permissions, artifacts, and consumer install paths?
Development
DevOps, security
Distribution architecture and ownership map
REL-06
Who owns technical change classification, required-domain identification, merge, publication, verification, and rollback?
Development
Design Ops, QA, DevOps
Release RACI and runbook
REL-07
Which domain gates apply to each release type, and how is inclusion or exclusion of a domain recorded?
Joint
QA
Release-gate matrix
REL-08
Which technical, merge, and release responsibilities may Danielle delegate, and which engineering gate remains with the accountable lead?
Development
Program
Maintainer-delegation policy
REL-09
What qualifies for an emergency engineering patch, who may declare it, which checks must pass first, and which review may occur afterward?
Development
Design Ops, QA, security
Emergency-release runbook
REL-10
What happens when an emergency affects design, content, accessibility, localization, tokens, or another domain?
Joint
QA
Cross-domain incident path
REL-11
How many versions are supported concurrently, when does support end, and what fixes are backported?
Development
Product teams, Program
Supported-version policy
REL-12
Who upgrades consuming products, what migration assistance does PDS provide, and what notice or support period applies?
Joint
Product teams
Consumer upgrade and migration contract
REL-13
Will changes ship continuously, on a recurring cadence, at readiness checkpoints, or through another model?
Development
Design Ops, Program
Release calendar and cut-off rules
REL-14
What response expectations apply to urgent defects, ordinary defects, security findings, and accessibility regressions?
Joint
QA, security, Program
Severity and release service expectations
REL-15
What is the authoritative release record and what fields must it contain?
Development
Design Ops, Program
Changelog/release-note template
REL-16
Which channel announces releases, who owns the message, who receives it, and how does the message point back to the authoritative record?
Design Ops
Development, Program
Release communication plan
REL-17
What compatibility does PDS promise registered Extended consumers, and what does it not promise unregistered private implementations?
Joint
Product teams
Extended-consumer compatibility policy
## 8. Establish documentation and source-of-truth governance
Documentation decisions must establish authority before component pages and coding-agent outputs are built.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
DOC-01
Will people and coding agents use one governed Markdown documentation source rather than separately maintained human and machine corpora?
Joint
Program
Documentation-source policy
DOC-02
What is authoritative in Markdown, Figma, the code repository, Storybook, Jira, and generated views?
Joint
Program, QA
Artifact-authority matrix
DOC-03
Which structured facts are stored once and generated elsewhere, and which judgment-heavy guidance remains reviewed prose?
Joint
Program
Documentation data model
DOC-04
Who owns editorial governance, design guidance, technical guidance, accessibility evidence, localization content, and product-use evidence?
Joint
QA, Product teams
Documentation approval matrix
DOC-05
What documentation is required at Alpha, Beta, and Stable?
Design Ops
Development, QA
Maturity documentation templates
DOC-06
What minimum documentation is required for an Extended component without implying PDS support?
Design Ops
Product teams
Extended record template
DOC-07
Which README, contribution, security, ownership, setup, architecture, validation, definition-of-done, and maintainer documents must the repository contain?
Joint
Security, QA
Contributor documentation set
DOC-08
What change events require the component-health record and governed Markdown to update together?
Joint
Program
Documentation drift-control workflow
DOC-09
What constitutes FY27 documentation completion, and how will the coding-agent context pilot be validated?
Design Ops
Development, Program
FY27 documentation definition of done
DOC-10
What is the boundary among English guidance, French built-in strings, localized examples, translation ownership, fallback, update triggers, and parity validation?
Design Ops
Development, QA
English/French documentation and localization policy
## 9. Establish token and naming governance
The current token files are evidence for this discussion, not automatic proof of a complete future policy.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
TOK-01
Which existing JSON, vocabulary, and type-scale artifacts are authoritative today, and for exactly which decisions?
Joint
Program
Token and naming authority map
TOK-02
Are product teams and contributors required to use an existing PDS token when it covers the need?
Design Ops
Development, Product teams
Token-use policy
TOK-03
What evidence must a missing-token request include, and who prioritizes it?
Design Ops
Development, QA
Token request template and routing
TOK-04
What may a product team use temporarily while a request is pending, and who owns migration from that temporary value?
Design Ops
Product teams, Development
Temporary-token/literal policy
TOK-05
Which token decisions belong to design semantics, taxonomy, public naming, and breakpoint intent, and which belong to schema, aliases, serialization, output, stability, and agent consumption?
Joint
—
Design/development token authority split
TOK-06
What requires joint design and engineering go decisions, including public-token and breakpoint changes?
Joint
QA
Token gate matrix
TOK-07
What naming grammar, namespaces, categories, primitives, aliases, layers, modes, state/scale terms, and component-token boundaries will PDS support?
Joint
—
Token taxonomy and naming specification
TOK-08
Which platforms and generated outputs are supported, and what validation, linting, and build controls are mandatory?
Development
Design Ops
Token build and validation contract
TOK-09
Which identifiers must remain stable for product consumers and coding agents?
Joint
Product teams
Stable-token API declaration
TOK-10
How are token additions, value changes, deprecations, aliases, renames, semantic changes, and removals versioned and migrated?
Development
Design Ops, QA, Product teams
Token compatibility and migration policy
TOK-11
How are duplicates, gaps, unresolved literals, and breakpoint misalignment inventoried and remediated?
Joint
Product teams
Token remediation backlog
TOK-12
Is locale behavior handled without a separate `fr-CA` token set, and which locale-sensitive concerns belong elsewhere?
Joint
QA
Token/localization boundary
## 10. Establish accessibility, localization, and QA assurance
These decisions define what evidence supports PDS maturity without implying certification of an assembled product.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
A11Y-01
What WCAG baseline applies in FY27, and what event or approval changes it in FY28?
Design Ops
QA, Development, Program
Accessibility baseline statement
A11Y-02
Which semantics, interactions, defaults, and documented responsibilities PDS guarantees, and which assembled-product responsibilities remain with product teams?
Joint
QA, Product teams
Component/product accessibility boundary
A11Y-03
Which automated and manual checks are required before Alpha, Beta, Stable, and different release types?
QA / accessibility
Design Ops, Development
Maturity accessibility matrix
A11Y-04
Which checks may the assigned developer and Design Ops Product Designer perform in FY27, and which require qualified QA/SDET or an accessibility specialist?
QA / accessibility
Development, Design Ops
Reviewer qualification matrix
A11Y-05
Can a component become Stable without qualified manual evidence, and how is missing assurance represented to consumers?
Joint
QA, Product teams
Stable-assurance rule and warning
A11Y-06
How is borrowed FY27 QA requested, prioritized, scheduled, protected, and handled when unavailable?
Program / capacity
QA, Design Ops, Development
Borrowed-QA service and escalation process
A11Y-07
Where is accessibility evidence stored, what fields are mandatory, who may approve it, when is it refreshed, and how long is it retained?
QA / accessibility
Program, Development
Accessibility evidence schema and repository
A11Y-08
What defect-severity taxonomy controls maturity, release urgency, support, deprecation, and consumer notification?
QA / accessibility
Design Ops, Development, Product teams
Accessibility/quality severity policy
A11Y-09
Which `fr-CA` checks apply to built-in strings, accessible names, language metadata, localized formatting, and assistive-technology output?
Design Ops
Development, QA
Localization and accessibility checklist
A11Y-10
What evidence must an Extended component carry before it can enter Core Beta or Stable assessment?
Joint
Product teams, QA
Extended-to-Core assurance gate
A11Y-11
What dedicated QA and accessibility capability should FY28 fund, and which gates would it own?
Program / capacity
QA, Design Ops, Development
FY28 QA capability request
## 11. Establish health reviews, telemetry, remediation, and success measures
These decisions allow the Core team to detect drift, manage maintenance, and learn whether the operating model works.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
AUD-01
Will Jira hold the authoritative component-health record, and which dimensions, states, owners, and evidence links must it contain?
Design Ops
Development, QA, Program
Component-health schema and Jira configuration
AUD-02
What must the FY27 baseline assessment cover and when is it considered complete?
Joint
QA, Product teams
Baseline plan and completion criteria
AUD-03
Which health dimensions update on every change or release, and which are reviewed fortnightly, quarterly, or every six months?
Joint
Program, QA
Review calendar and trigger matrix
AUD-04
Who must participate in baseline, fortnightly, quarterly, accessibility, contribution, and deprecation reviews, with what protected capacity and absence coverage?
Program / capacity
All domains
Review participation agreement
AUD-05
How often must Extended owners reconfirm ownership, consumers, dependencies, gaps, and lifespan, and what happens when a record becomes stale or ownerless?
Design Ops
Product teams
Extended-review workflow
AUD-06
What fields must remediation work contain, and who sets severity, lifecycle impact, owner, support level, target release, and review date?
Joint
QA, Program
Remediation template and routing
AUD-07
Which findings trigger a bug, readiness gap, ownership escalation, migration, maturity change, support change, or deprecation review?
Joint
QA, Product teams
Finding-to-action decision tree
AUD-08
How will the Core team monitor Ready-for-contribution work, inactive assignments, open reviews, Danielle’s review queue, failed checks, unreleased merges, and new maintenance obligations?
Joint
Program
Contribution health view
AUD-09
What evidence triggers deprecation review, who owns each gate, and what must the published decision include?
Joint
QA, Product teams
Deprecation review record
AUD-10
Which authorized data sources identify versions, component use, consumers, applications, duplication, and migration progress?
Development
Product teams, security, Design Ops
Telemetry source and access map
AUD-11
Who collects telemetry, how often is it refreshed, and how are privacy, access, accuracy, and incomplete coverage disclosed?
Program / capacity
Development, security
Telemetry governance policy
AUD-12
Which FY27 measures are formal readiness outcomes and which—adoption, downloads, contributor count, pull-request count, or lines of code—are context only?
Design Ops
Program, Development
Measurement dictionary and dashboard rules
AUD-13
How are FY27 learning, unresolved gaps, and maintenance obligations converted into a prioritized FY28 request without becoming an unsupported promise?
Design Ops
Program, Development, QA
FY28 carryover and investment proposal
## 12. Pilot, resolve, and ratify
The Core team should not attempt to settle every detail in one governance meeting. It should use bounded pilots to test whether the proposed controls produce usable evidence and sustainable work.
ID
Decision to align on
Proposed lead
Required alignment
Control or artifact to build
RAT-01
Which existing component will pilot the complete intake-to-release and health-record process?
Design Ops
Development, QA, Product teams
Named lifecycle pilot
RAT-02
Which backlog items will pilot inner-source contribution without making voluntary capacity a delivery dependency?
Joint
Program
Named contribution pilot
RAT-03
Which consuming application or test integration will validate installation, package behavior, documentation, and upgrade assumptions?
Development
Product teams, QA
Representative consumer pilot
RAT-04
Which Markdown-to-human-view and coding-agent workflow will validate the one-source documentation proposal?
Joint
Program
Documentation and agent-context pilot
RAT-05
What evidence will determine whether a proposed rule is accepted, revised, or rejected?
Design Ops
All affected domains
Pilot evaluation rubric
RAT-06
Where are unresolved decisions kept, who prepares them, and how are dependencies and due dates tracked?
Program / capacity
Design Ops
Open-decision register
RAT-07
Who ratifies the FY27 operating baseline after affected domains have approved their portions, and how are later amendments governed?
Design Ops
Development, QA, Program
Ratification and amendment procedure
## Per-work-item sequence the Core team must validate
The decisions above should ultimately produce one coherent path for an individual request:
1. A need enters the authoritative intake.
2. The request is typed, checked for evidence, and routed.
3. Design Ops assesses system need and Core fit.
4. Development assesses feasibility, architecture, package fit, and maintenance cost.
5. The Design Ops Lead assigns priority and a support level within confirmed capacity.
6. The item is either retained as product-owned/Extended, accepted for PDS work, or returned for discovery.
7. Accepted work receives a target layer, proposed maturity, accountable owner, evidence requirements, and required domains.
8. If offered to other developers, it passes the Ready-for-contribution gate and is assigned through the governed workflow.
9. Design, implementation, tests, documentation, accessibility, localization, and consumer evidence are produced.
10. Each affected domain records go or no-go only for its own evidence.
11. A no-go pauses the affected outcome and creates or links remediation.
12. A code contribution may merge only after its merge gates pass.
13. Merge does not automatically promote maturity or publish a release.
14. Maturity changes only after the lifecycle evidence and required domain gates pass.
15. Publication follows the approved version, package, distribution, and release process.
16. Consumers receive the authoritative release record and applicable migration guidance.
17. Component health, ownership, evidence, consumers, and known gaps remain current after release.
18. Audit findings create remediation, support changes, migration work, or deprecation review.
19. Deprecation and removal follow their approved notice, replacement, migration, and release gates.
## Suggested Core-team working sessions
This is a sequencing aid, not a meeting commitment.
Session
Decisions to address
Expected outcome
Pre-read orientation
CTX-01 through CTX-07
Shared understanding of the established mandate; clarification only, with no approval decision
2. Team and authority
TEAM-01 through TEAM-16
Named forums, role boundaries, gates, delegation, and capacity ownership
3. Current-state inventory
INV-01 through INV-08
Evidence baseline and discovery backlog
4. Intake and lifecycle
INT-01 through LIFE-14
Request, Core, ownership, maturity, and retirement model
5. Contribution
CONT-01 through CONT-14
Inner-source workflow, repository controls, and maintainer capacity model
6. Release and support
REL-01 through REL-17
1.0 technical contract, distribution, versioning, release, and support
7. Documentation and tokens
DOC-01 through TOK-12
Source authority, documentation model, and token governance
8. Accessibility and QA
A11Y-01 through A11Y-11
Evidence, qualifications, QA service, localization, and defect consequences
9. Audit and measures
AUD-01 through AUD-13
Health record, reviews, telemetry, remediation, and FY27 measures
10. Pilot and ratification
RAT-01 through RAT-07
Bounded pilots, evaluation criteria, and amendment process
## Decision-record minimum
When the Core team resolves any item, the record should contain:
- decision ID and question;
- decision and effective date;
- affected scope and exclusions;
- accountable owner;
- affected domains and their go/no-go results;
- evidence and assumptions;
- dependencies;
- control, workflow, template, automation, or documentation to build;
- implementation owner and target review point;
- unresolved consequences or follow-up decisions;
- amendment or reopening condition.