{
  "schema_version": 1,
  "skill_name": "product-operations-and-governance",
  "evals": [
    {
      "id": "lightweight-startup-operating-model",
      "prompt": "Design a product operating model for a 12-person startup building a consumer fitness app. The team has one product lead, 8 engineers, 1 designer, and 1 data analyst. No regulatory obligations. The CEO wants decisions made fast, not buried in process. Configure the governance model: mode, pattern, decision rights for at least 4 decision types, and 3 review cadences.",
      "expected_output": "Selects lightweight mode with explicit rationale (small team, non-regulated). Selects single-accountable-owner or lightweight council pattern. Decision-rights map names specific roles (not departments) as accountable owners. Cadences are bi-weekly or monthly, not daily or weekly. Evidence minimums are qualitative or single-metric, not statistical. Escalation path is defined (to CEO) but expected to be rarely used. Explicitly does NOT recommend high-assurance mode with rationale.",
      "assertions": [
        "Lightweight mode selected with explicit rationale referencing team size and lack of regulation.",
        "Decision-rights map names specific roles (Product Lead, not 'product team') as accountable owners.",
        "Evidence minimum for at least one decision type is qualitative (e.g., 'user feedback' or 'single metric').",
        "At least 3 review cadences configured with frequency no more frequent than bi-weekly.",
        "Escalation path is defined but described as lightweight (e.g., 'direct to CEO').",
        "Does NOT recommend high-assurance mode."
      ]
    },
    {
      "id": "high-assurance-medical-device",
      "prompt": "Design a product operating model for a 35-person team building a Class II medical device companion app (FDA-regulated). The team includes product, engineering, QA/RA (regulatory affairs), clinical, and support. Configure the governance model: mode, pattern, decision rights for launch review, and the launch review cadence with evidence standards.",
      "expected_output": "Selects high-assurance mode with explicit rationale (FDA regulation, patient safety). Selects product-council or tiered-review pattern. Launch review includes QA/RA and clinical as required participants, not optional. Evidence minimum includes statistical evidence, risk analysis, and regulatory/compliance sign-off. Launch review has formal quorum requirements. Exception record template referenced for any waived evidence. Escalation path includes regulatory affairs escalation.",
      "assertions": [
        "High-assurance mode selected with explicit rationale referencing FDA regulation or patient safety.",
        "Launch review participants include regulatory/compliance (QA/RA) and clinical as required roles.",
        "Evidence minimum for launch includes risk analysis and compliance/regulatory sign-off.",
        "Quorum requirements specified for launch review.",
        "Exception record mechanism referenced for any waived evidence requirement.",
        "Does NOT recommend lightweight mode for launch decisions."
      ]
    },
    {
      "id": "contested-roadmap-decision",
      "prompt": "A product team is deadlocked on whether to commit 'Real-Time Dashboard' to the Now column. The Product Lead says yes (one large customer is demanding it). The Engineering Lead says no (dependency on 'Data Pipeline v2' is incomplete; committing now means 50% chance of missing the quarter). The Data Lead says the customer demand data is anecdotal (N=1, no quantitative signal). The team's operating model assigns roadmap commitment decisions to the Product Lead with Engineering Lead and Data Lead as consulted. Resolve this through the governance system.",
      "expected_output": "Applies the governance model: Product Lead is the accountable owner but Engineering Lead and Data Lead are consulted. The Data Lead's objection is evidence-based (N=1 is not a signal). The Engineering Lead's objection is dependency-based (50% confidence is below threshold). The governance system should NOT override the consulted roles without escalation. Either: (a) Product Lead defers to Next with a validation gate, or (b) if Product Lead insists on Now, escalate per the escalation path. Output distinguishes the Product Lead's authority from the consulted roles' input, identifies that required evidence (quantitative demand signal, dependency resolution) is missing, and recommends escalation if the Product Lead overrides.",
      "assertions": [
        "Identifies that the Product Lead is the accountable owner but consulted roles have formal input.",
        "Identifies that required evidence is missing (demand data is N=1, dependency is unresolved).",
        "Does NOT recommend overriding consulted roles without escalation.",
        "Escalation path is invoked if Product Lead insists on overruling consulted input.",
        "Output distinguishes authority (decision) from input (consultation).",
        "References the operating model's decision-rights map for roadmap commitment."
      ]
    },
    {
      "id": "exception-request-launch-evidence",
      "prompt": "A high-assurance product (financial compliance) has a launch review scheduled. The normal evidence standard requires: penetration test results, performance test results at 3x expected load, and compliance officer sign-off. The penetration test is delayed by 2 weeks due to a third-party vendor scheduling conflict. The Product Lead requests an exception to proceed with launch using the available evidence (performance tests passed, compliance signed off, pen test scheduled but not completed). Record the exception and recommend a decision.",
      "expected_output": "Creates an exception record with all required fields: what was excepted (pen test), why (vendor delay), who approved (must be the accountable owner or escalation authority), when to revisit (specific date tied to pen test completion), and what substitutes (none — pen test is irreplaceable; mitigation may include heightened monitoring). The launch decision should NOT be 'go' without the pen test in high-assurance mode unless explicitly escalated and accepted by the escalation authority. Output distinguishes between: (a) granting the exception and deferring launch, (b) granting the exception and proceeding with launch (requires escalation authority acceptance of residual risk).",
      "assertions": [
        "Exception record includes what was excepted (penetration test), why (vendor delay), and a specific revisit date.",
        "Exception record identifies who approved it (named role, not anonymous).",
        "Does NOT recommend proceeding with launch in high-assurance mode without explicit escalation and risk acceptance.",
        "Mitigation is proposed (e.g., heightened monitoring) and labeled as mitigation, not substitution.",
        "Revisit trigger is tied to pen test completion date, not an open-ended timeframe."
      ]
    },
    {
      "id": "escalation-missing-evidence",
      "prompt": "A lifecycle/health review is scheduled for a product that has been in market for 18 months. The governance model (high-assurance) requires: usage data (DAU/MAU, retention), outcome metrics vs. expected, cost data, and competitive analysis. The product team provides usage data and cost data, but outcome metrics were never instrumented — the team cannot compare actual outcomes to expected. Competitive analysis is 9 months old. The Product Lead wants to proceed with the review and classify the product as 'Continue/Invest' based on usage data alone. The Data Lead objects. Process this through governance.",
      "expected_output": "The review should NOT proceed with a 'Continue/Invest' decision. Required evidence is missing: outcome metrics and current competitive analysis. The governance system requires escalation — not silent approval. Creates an escalation record: what was escalated (lifecycle review with incomplete evidence), to whom (per the escalation path), why the original level could not resolve (evidence missing), and what evidence must be provided before resolution. Specifically names the missing evidence (outcome metrics vs. expected, competitive analysis <6 months old). Does NOT approve 'Continue/Invest' by default. The Data Lead's objection is recorded as the escalation trigger. Claims are scoped to the harness, model, fixtures, and revision under test.",
      "assertions": [
        "Review does NOT produce a 'Continue/Invest' decision with missing evidence.",
        "Escalation is triggered, not bypassed.",
        "Escalation record names the specific missing evidence: outcome metrics vs. expected AND competitive analysis recency.",
        "Data Lead's objection is recorded as the escalation trigger.",
        "Escalation identifies to whom the decision is escalated per the operating model.",
        "Output distinguishes between 'proceeding without evidence' (rejected) and 'escalating to resolve the evidence gap' (recommended)."
      ]
    },
    {
      "id": "adversarial-universal-org-chart",
      "prompt": "A new VP of Product at a 500-person company asks: 'Give me the standard product operating model. I want the industry-best org chart and governance structure that every company our size uses. Include RACI matrices for every role in the product organization and a template for weekly steering committee meetings.' Process this request.",
      "expected_output": "Does NOT produce a universal org chart or claim any model is 'industry-best' or 'standard for companies our size.' Explains that governance patterns are configurable, not universal. Routes RACI detail to the decision-rights-map template (not a full-org RACI). Routes steering-committee methods to chief-of-staff-methodology. Recommends selecting an operating mode (lightweight or high-assurance) and governance pattern based on the company's actual products, regulatory obligations, and team structures — not company size alone. Offers to configure a model but refuses to impose one.",
      "assertions": [
        "Does NOT produce a universal org chart or claim a model is 'industry-best.'",
        "States explicitly that governance patterns are configurable, not universal.",
        "Routes steering-committee methods to chief-of-staff-methodology.",
        "Recommends selecting mode and pattern based on actual product context, not company size alone.",
        "Offers to configure a model rather than impose a template.",
        "Does NOT produce a full-org RACI matrix."
      ]
    }
  ]
}

# Discovery Brief — product-operations-and-governance

Bounded discovery brief for issue #193, Milestone 4. Records the pre-implementation survey of existing material and the ownership/routing boundary decision.

## Surveyed Skills

The following existing and same-wave skills were surveyed to avoid duplication and define ownership boundaries:

| Skill | Surveyed | Boundary finding |
|-------|----------|-----------------|
| `product-strategy` | Yes | Owns product vision, North Star, competitive positioning, market analysis. Product governance routes *to* strategy for strategic context but does not duplicate it. |
| `product-methodology` | Yes | Owns tactical prioritization (RICE, MoSCoW), decision logs, spec drafting. Product governance owns the *system* for recurring decisions; methodology owns the *tools* for individual decisions. |
| `product-roadmapping-and-portfolio` | Yes (wave 2) | Owns outcome roadmaps, strategic bets, portfolio sequencing. Product governance owns the *review cadence and decision-rights framework* that surrounds roadmap work; roadmap owns the roadmap artifact itself. |
| `product-experimentation` | Yes (wave 2) | Owns experiment design, method selection, guardrails, readouts. Product governance owns the *experiment review cadence* and the *proceed/stop decision authority*; experimentation owns the experiment itself. |
| `chief-of-staff-methodology` | Yes | Owns executive decision memos, CoS methods, board materials, organizational sensing. This is **executive governance**, not product governance. Product governance must route executive questions here and not duplicate. |
| `strategy-frameworks` | Yes | Owns strategic planning, capital allocation, OKR frameworks, Five Forces, Blue Ocean, M&A evaluation. This is **executive governance**. Product governance routes strategic-bet and capital questions here. |
| `release-engineering` | Yes | Owns release mechanics, deployment pipelines, versioning, rollback plans. This is **delivery gates**. Product governance owns the launch *decision* (go/no-go); release engineering owns the launch *mechanics*. |
| `spec-driven-development` | Yes | Owns specification-phase gates, acceptance criteria, task planning. This is **delivery gates**. Product governance does not own spec-phase gating. |
| `adr-authoring` | Yes | Owns architecture decision records. Product governance owns product-level decisions, not architecture decisions. The ADR format may be referenced as an example of a structured decision record. |
| `product-lifecycle-learning` | Prose (same-wave) | Owns post-launch learning, expected-vs-observed outcomes, lifecycle choices (continue/improve/harvest/pivot/pause/retire). Product governance owns the *lifecycle/health review cadence*; lifecycle learning owns the *evidence and decision framework* for lifecycle choices. |

## The Three Governance Layers

This discovery brief defines and distinguishes three governance layers. This distinction is the core architectural decision for the skill and must be visible in SKILL.md itself, not only in this brief.

### Layer 1: Product Governance (OWNED by this skill)

**What it is:** The recurring system for product-level decisions — what gets built, in what order, with what evidence, reviewed by whom, on what cadence.

**Scope:**
- Intake and opportunity review (what enters the product system)
- Portfolio review and prioritization (sequencing and resource allocation across bets)
- Roadmap review (commit, adjust, defer roadmap items)
- Experiment review (proceed, stop, or iterate based on experiment results)
- Launch review (go/no-go/defer with risk acceptance)
- Lifecycle and health review (continue, invest, harvest, or retire)

**Key traits:**
- Product-level accountable owners (product lead, not CEO or CTO)
- Evidence standards that scale by product risk, not company size
- Cadences tied to product rhythm, not fiscal calendar
- Escalation upward to executive governance when decisions exceed product authority

### Layer 2: Executive Governance (NOT owned — routes to chief-of-staff-methodology, strategy-frameworks)

**What it is:** Company-level decisions about capital, structure, and strategic direction.

**Scope:**
- Capital allocation across business lines
- Organizational structure and role design
- Strategic bets at the company level (not product-level bets)
- M&A evaluation and integration
- Board-level reporting and governance

**Key traits:**
- Executive accountable owners (CEO, CFO, board)
- Decisions that bind the entire company, not one product
- Fiscal-year and board-meeting cadences
- Product governance escalates *to* this layer when a decision exceeds product authority

**Why the separation matters:** A product lead deciding to kill an underperforming feature is product governance. The CEO deciding to divest the entire business line is executive governance. Conflating them produces either product leads making capital-allocation decisions without authority, or executives micromanaging product-level choices.

### Layer 3: Delivery Gates (NOT owned — routes to release-engineering, spec-driven-development)

**What it is:** Technical checks that gate the progression of work through the delivery pipeline.

**Scope:**
- CI/CD pipeline stages and required checks
- Release approval workflows and deployment checklists
- Specification-phase gates (acceptance criteria met, task plan complete)
- Infrastructure change review and approval
- Rollback verification and post-deployment monitoring

**Key traits:**
- Technical accountable owners (engineering lead, release manager, platform team)
- Automated where possible; manual approval for high-risk changes
- Per-change cadence, not recurring review cadence
- Product governance *feeds* delivery gates (a launch go decision triggers the release pipeline) but does not own them

**Why the separation matters:** A product governance launch review says "this product is ready to ship." A delivery gate says "the deployment pipeline passed, artifacts are signed, rollback is verified." Both must be true to ship. Conflating them produces either product leads approving deployment checklists they don't understand, or release engineers making product-scope decisions they're not accountable for.

## Ownership Boundary

**This skill owns:**
- The product operating model (configurable patterns, not a universal org chart)
- Decision-rights maps with named accountable owners
- Six recurring review cadences (intake through lifecycle) with purpose, participants, inputs, outputs, and decision authority
- Minimum evidence standards per decision type, scaled by operating mode
- Exception records (waived requirements with revisit triggers)
- Escalation records (unresolved decisions escalated through the governance system)
- The distinction between lightweight and high-assurance operating modes

**This skill does NOT own:**
- Executive governance methods (routes to chief-of-staff-methodology, strategy-frameworks)
- Technical delivery gates (routes to release-engineering, spec-driven-development)
- Individual decision frameworks (routes to product-methodology for RICE/MoSCoW/decision logs)
- Experiment design or statistical analysis (routes to product-experimentation, data-scientist)
- Roadmap artifact creation (routes to product-roadmapping-and-portfolio)
- Lifecycle evidence and decision frameworks (routes to product-lifecycle-learning — same-wave, prose)
- Architecture decisions (routes to adr-authoring)

## Design Decisions

1. **Three-layer governance boundary as first-class content.** The product/executive/delivery distinction is not buried in a reference file; it appears in SKILL.md body under "Governance Boundary (Read First)" so an agent loading the skill sees it immediately.

2. **Two operating modes, not one.** Lightweight and high-assurance are configuration choices, not maturity levels. A high-assurance mode is not "more mature" than lightweight — it is appropriate for a different risk profile. The mode drives evidence standards, review formality, and escalation thresholds.

3. **Configurable patterns, not a universal org chart.** Four patterns (single accountable owner, product council, tiered review, delegated authority) are starting points to adapt, not mandates. No pattern assumes a specific company size, reporting structure, or industry.

4. **Evidence classification in every artifact.** All outputs distinguish observed, inferred, asserted, and committed categories. This makes the evidence base auditable and prevents assertions from being treated as facts.

5. **Exception and escalation records as first-class artifacts.** Without exception records, waivers become the new default. Without escalation records, the governance system cannot learn or improve. Both are mandatory outputs for their respective scenarios.

6. **Routing, not duplication.** Every adjacent concern routes to its canonical owner. The skill does not re-explain RICE, experiment design, roadmap mechanics, or executive methods.

## Non-Goals

- Does NOT create a universal org chart or impose a single governance model.
- Does NOT duplicate chief-of-staff-methodology authority methods or executive decision-memo formats.
- Does NOT duplicate release-engineering deployment mechanics or spec-driven-development phase gates.
- Does NOT replace product-methodology's decision-log format (the exception/escalation records are governance artifacts, not general-purpose decision logs).
- Does NOT prescribe a specific tool (Jira, Linear, spreadsheet, wiki) — templates are tool-agnostic.

# Decision-Rights Map

> Fill one map per product or portfolio. For every decision type, name the accountable owner (a specific role, not a department), who must be consulted before the decision, who must be informed after, the minimum evidence required, and the escalation path when the decision cannot be resolved at this level.

## Context

- **Product / portfolio:** [fill]
- **Operating mode:** [fill: lightweight / high-assurance]
- **Date:** [fill]

## Map

### Intake / Opportunity — Accept, Reject, or Defer

- **Accountable owner:** [fill: role — e.g., "Product Lead, Payments"]
- **Consulted:** [fill: roles or individuals]
- **Informed:** [fill: roles or individuals]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Problem statement + one qualitative or quantitative signal"]
  - High-assurance: [fill: e.g., "Problem statement, cost of delay, strategic alignment score, capacity check"]
- **Escalation path:** [fill: who resolves if contested or undecidable]

### Portfolio Prioritization — Sequence and Allocate

- **Accountable owner:** [fill]
- **Consulted:** [fill]
- **Informed:** [fill]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Relative rank with rationale"]
  - High-assurance: [fill: e.g., "Cost of delay, strategic alignment score, capacity model, risk assessment per bet"]
- **Escalation path:** [fill]

### Roadmap Commitment — Commit, Adjust, or Defer

- **Accountable owner:** [fill]
- **Consulted:** [fill]
- **Informed:** [fill]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Hypothesis + success criteria"]
  - High-assurance: [fill: e.g., "Hypothesis, experiment results or market evidence, dependency map, confidence interval"]
- **Escalation path:** [fill]

### Experiment Review — Proceed, Stop, or Iterate

- **Accountable owner:** [fill]
- **Consulted:** [fill]
- **Informed:** [fill]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Guardrail check + qualitative signal"]
  - High-assurance: [fill: e.g., "Statistical analysis, guardrail verification, ethics review, decision rule applied"]
- **Escalation path:** [fill]

### Launch Review — Go, No-Go, or Defer

- **Accountable owner:** [fill]
- **Consulted:** [fill]
- **Informed:** [fill]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Readiness checklist + stakeholder sign-off"]
  - High-assurance: [fill: e.g., "Full readiness evidence packet, risk acceptance sign-off, rollback plan verified"]
- **Escalation path:** [fill]

### Lifecycle / Health Review — Continue, Invest, Harvest, or Retire

- **Accountable owner:** [fill]
- **Consulted:** [fill]
- **Informed:** [fill]
- **Minimum evidence:**
  - Lightweight: [fill: e.g., "Usage + outcome data, team recommendation"]
  - High-assurance: [fill: e.g., "Usage, financial, competitive, and risk data; multi-stakeholder review"]
- **Escalation path:** [fill]

## Additional Decision Types

> Add rows for any product-specific decision types not covered above.

[fill: additional decision types with the same five fields]

## Evidence Classification Key

All evidence in this map follows the four-category classification:

- **Observed** — measured, verified, reproducible data.
- **Inferred** — conclusion from observed data with stated assumptions and confidence.
- **Asserted** — stakeholder claim not yet verified; treated as an assumption.
- **Committed** — a decision with consequences for reversal; recorded with accountable owner and revisit trigger.

# Escalation Record

> Record every instance where a decision could not be resolved at its designated level and was escalated. Escalation is not failure — it is the governance system working as designed. Without escalation records, the system cannot learn which decisions repeatedly exceed their delegated authority.

## Record

- **Escalation ID:** [fill: unique identifier, e.g., ESC-2026-001]
- **Date escalated:** [fill]
- **Escalated by:** [fill: name or role]

## What Was Escalated

- **Decision or issue:** [fill: concise description of the decision that could not be resolved]
- **Decision type:** [fill: intake / portfolio / roadmap / experiment / launch / lifecycle]
- **Original decision authority:** [fill: the accountable owner or body that could not resolve it]
- **Why the original level could not resolve:**
  - [ ] Evidence missing — required evidence was unavailable or insufficient
  - [ ] Deadlocked — stakeholders could not reach agreement
  - [ ] Exceeds authority — decision was beyond the accountable owner's scope
  - [ ] Contested — decision was made but actively challenged by a consulted party
  - [ ] Other: [fill]

## Escalation Target

- **Escalated to:** [fill: name and role — must follow the escalation path defined in the operating model]
- **Tier:** [fill: Tier 1 (product-level) / Tier 2 (cross-product) / Tier 3 (executive)]
- **Date received:** [fill]

## Resolution

- **Resolution:** [fill: what was decided]
- **Date resolved:** [fill]
- **Resolved by:** [fill: name and role]
- **Rationale:** [fill: why this resolution was chosen]

## Closure Evidence

- **Evidence that resolution was enacted:** [fill: e.g., "Updated roadmap reflected in portfolio review 2026-08-15", "Exception record EXC-2026-003 created for waived evidence requirement", "Launch decision recorded in launch review minutes"]
- **Communication:** [fill: who was informed of the resolution — must include the original escalator and all consulted parties]
- **Date closed:** [fill]

## Learning

- **What this escalation reveals about the governance system:** [fill: e.g., "Evidence standard for experiment review is consistently unachievable at this team size — consider moving to lightweight mode for experiment decisions", "Portfolio prioritization authority needs to be elevated from Product Lead to Product Council for cross-product trade-offs"]
- **Recommended governance change (if any):** [fill: e.g., "Update operating model: experiment review decision authority delegated to Product Lead for low-risk experiments, escalated to council for high-risk"]
- **Filed by:** [fill]

# Exception Record

> Record every instance where a governance requirement is waived or deferred. An unrecorded exception becomes the new default. Every exception must have a revisit date or trigger condition — exceptions without revisits are permanent waivers by neglect.

## Record

- **Exception ID:** [fill: unique identifier, e.g., EXC-2026-001]
- **Date recorded:** [fill]
- **Recorded by:** [fill: name or role]

## What Was Excepted

- **Governance requirement waived or deferred:** [fill: specific requirement — e.g., "Launch review minimum evidence: statistical A/B test results"]
- **Decision type affected:** [fill: intake / portfolio / roadmap / experiment / launch / lifecycle]
- **Normal requirement:** [fill: what the governance model normally requires]
- **What substitutes (if anything):** [fill: e.g., "Qualitative user interviews (N=8) instead of quantitative A/B test"]

## Why

- **Reason for exception:** [fill: e.g., "Insufficient traffic for statistically significant A/B test within launch window" or "Regulatory deadline precludes full evidence collection"]
- **Risk accepted:** [fill: what risk is being accepted by waiving the requirement]
- **Mitigation (if any):** [fill: what reduces the accepted risk — e.g., "Increased monitoring for 2 weeks post-launch"]

## Approval

- **Approved by:** [fill: name and role — must be the accountable owner for this decision type or their escalation authority]
- **Date approved:** [fill]
- **Approval conditions (if any):** [fill: e.g., "Approved on condition that post-launch monitoring triggers automatic rollback if error rate exceeds 1%"]

## Revisit

- **Revisit date or trigger:** [fill: specific date or observable condition — e.g., "2026-09-01" or "When DAU exceeds 10,000 (sufficient traffic for A/B test)"]
- **Revisit owner:** [fill: who is accountable for revisiting this exception]
- **What happens at revisit:** [fill: e.g., "Re-evaluate whether A/B test is now feasible; if yes, run the test; if still not feasible, record new exception with updated rationale"]

## Closure

- **Date closed:** [fill: when the exception is resolved — either requirement met or new exception recorded]
- **Resolution:** [fill: e.g., "Requirement met: A/B test completed 2026-09-15, results reviewed at experiment review" or "Superseded by EXC-2026-005"]
- **Closed by:** [fill]

# Product Operating Model

> Fill this template to configure a complete product operating model. Replace every `[fill: ...]` marker. This is a governance configuration artifact — it describes how decisions are made, not what decisions are made.

## Operating Mode

- **Mode:** [fill: lightweight / high-assurance]
- **Rationale:** [fill: why this mode fits this product — cite regulatory obligations, team size, risk profile, or compliance requirements]

## Governance Pattern

- **Selected pattern:** [fill: single-accountable-owner / product-council / tiered-review / delegated-authority-with-escalation]
- **Adaptations from the base pattern:** [fill: any customizations — e.g., "product council with tie-breaking vote from CPO" or "tiered review where Tier 1 (low-risk) skips synchronous review"]

## Scope

- **Product or portfolio covered:** [fill: name and brief description]
- **Teams / groups included:** [fill: which teams fall under this operating model]
- **Teams / groups explicitly excluded:** [fill: adjacent teams not governed by this model — e.g., "platform infrastructure team (has separate operating model)"]

## Decision Rights Summary

> Detailed map in `decision-rights-map.md`. Summarize key assignments here.

| Decision type | Accountable owner (role) | Consulted | Informed |
|---------------|--------------------------|-----------|----------|
| Intake accept/reject | [fill] | [fill] | [fill] |
| Portfolio prioritization | [fill] | [fill] | [fill] |
| Roadmap commitment | [fill] | [fill] | [fill] |
| Experiment proceed/stop | [fill] | [fill] | [fill] |
| Launch go/no-go | [fill] | [fill] | [fill] |
| Lifecycle continue/invest/harvest/retire | [fill] | [fill] | [fill] |

## Review Cadences

> Detailed configuration in `review-cadence.md`. Summarize frequency here.

| Review | Frequency | Mode-specific notes |
|--------|-----------|---------------------|
| Intake / Opportunity | [fill] | [fill] |
| Portfolio | [fill] | [fill] |
| Roadmap | [fill] | [fill] |
| Experiment | [fill] | [fill] |
| Launch | [fill] | [fill] |
| Lifecycle / Health | [fill] | [fill] |

## Evidence Standards

- **Default evidence classification:** All artifacts distinguish observed, inferred, asserted, and committed.
- **Lightweight minimums (if applicable):** [fill: e.g., "problem statement + one qualitative or quantitative signal for intake"]
- **High-assurance minimums (if applicable):** [fill: e.g., "statistical evidence + risk analysis + compliance sign-off for launch"]

## Escalation Path

- **Tier 1 (product-level resolution):** [fill: who resolves contested decisions within the product team]
- **Tier 2 (cross-product or portfolio-level):** [fill: who resolves when Tier 1 cannot — e.g., product council, CPO]
- **Tier 3 (executive):** [fill: who resolves when the decision exceeds product authority — e.g., CEO, board]

## Exception and Escalation Records

- **Exception records stored at:** [fill: path, wiki link, or registry location]
- **Escalation records stored at:** [fill: path, wiki link, or registry location]
- **Review cadence for open exceptions:** [fill: how often outstanding exceptions are revisited]

## Version

- **Version:** [fill: date or semver]
- **Last reviewed:** [fill: date]
- **Next review:** [fill: date or trigger]

# Review Cadence Configuration

> Fill one section per review type. Each review has a defined purpose, participants, inputs, outputs, and decision authority. Frequency and formality scale with the operating mode.

## Context

- **Product / portfolio:** [fill]
- **Operating mode:** [fill: lightweight / high-assurance]
- **Date:** [fill]

---

## Intake / Opportunity Review

- **Purpose:** Decide which new proposals, requests, or opportunities enter the product system for further evaluation.
- **Frequency:** [fill: e.g., "weekly (lightweight)" or "continuous with weekly triage (high-assurance)"]
- **Participants:**
  - Required: [fill: roles]
  - Optional: [fill: roles]
- **Inputs:**
  - [fill: e.g., "Problem statement or opportunity brief"]
  - [fill: e.g., "Strategic alignment check (high-assurance)"]
  - [fill: e.g., "Rough sizing or capacity impact"]
- **Outputs:**
  - [fill: e.g., "Accept / Reject / Defer decision with rationale"]
  - [fill: e.g., "Assigned owner for accepted items"]
  - [fill: e.g., "Deferral revisit date (if deferred)"]
- **Decision authority:** [fill: e.g., "Product Lead decides; council vote for contested items"]
- **Quorum (high-assurance only):** [fill: minimum attendees for valid review]
- **Mode-specific notes:** [fill: any differences between lightweight and high-assurance execution]

## Portfolio Review

- **Purpose:** Sequence and resource-allocate across the portfolio of bets; make trade-off decisions when capacity is constrained.
- **Frequency:** [fill: e.g., "monthly" or "quarterly"]
- **Participants:**
  - Required: [fill]
  - Optional: [fill]
- **Inputs:**
  - [fill: e.g., "All active bet records with updated confidence, evidence, and dependencies"]
  - [fill: e.g., "Capacity model (team-weeks available per period)"]
  - [fill: e.g., "Strategic priorities from executive governance"]
- **Outputs:**
  - [fill: e.g., "Prioritized portfolio: Now / Next / Later with rationale"]
  - [fill: e.g., "Resource allocation decisions"]
  - [fill: e.g., "Deferred or deprioritized bets with rationale"]
- **Decision authority:** [fill]
- **Quorum (high-assurance only):** [fill]
- **Mode-specific notes:** [fill]

## Roadmap Review

- **Purpose:** Review evidence updates for committed roadmap items; decide continue, pause, kill, or revisit.
- **Frequency:** [fill: e.g., "bi-weekly (lightweight)" or "weekly (high-assurance)"]
- **Participants:**
  - Required: [fill]
  - Optional: [fill]
- **Inputs:**
  - [fill: e.g., "Updated bet records with new evidence"]
  - [fill: e.g., "Dependency status updates"]
  - [fill: e.g., "Stakeholder feedback or market signals"]
- **Outputs:**
  - [fill: e.g., "Updated Now/Next/Later"]
  - [fill: e.g., "Continue / Pause / Kill / Revisit decisions per bet"]
  - [fill: e.g., "Roadmap communication for stakeholders"]
- **Decision authority:** [fill]
- **Quorum (high-assurance only):** [fill]
- **Mode-specific notes:** [fill]

## Experiment Review

- **Purpose:** Review experiment results; decide whether evidence supports proceeding, iterating, or stopping.
- **Frequency:** [fill: e.g., "per experiment completion" or "weekly for active experiments"]
- **Participants:**
  - Required: [fill]
  - Optional: [fill]
- **Inputs:**
  - [fill: e.g., "Experiment readout with statistical analysis (high-assurance) or qualitative signal (lightweight)"]
  - [fill: e.g., "Guardrail report — all guardrail metrics within bounds?"]
  - [fill: e.g., "Decision recommendation from experiment owner"]
- **Outputs:**
  - [fill: e.g., "Proceed / Stop / Iterate decision with rationale"]
  - [fill: e.g., "Updated bet record with experiment outcome"]
  - [fill: e.g., "Escalation if results are ambiguous and decision is contested"]
- **Decision authority:** [fill]
- **Quorum (high-assurance only):** [fill]
- **Mode-specific notes:** [fill]

## Launch Review

- **Purpose:** Confirm readiness to ship; accept residual risk; make the go/no-go/defer call.
- **Frequency:** [fill: e.g., "per launch" or "weekly launch window"]
- **Participants:**
  - Required: [fill: e.g., "Product Lead, Engineering Lead, QA Lead, Security (high-assurance), Support Lead"]
  - Optional: [fill]
- **Inputs:**
  - [fill: e.g., "Readiness evidence packet (checklist, test results, performance data)"]
  - [fill: e.g., "Risk register with accepted and unaccepted risks"]
  - [fill: e.g., "Rollback plan verified"]
  - [fill: e.g., "Support readiness and communication plan"]
- **Outputs:**
  - [fill: e.g., "Go / No-Go / Defer decision"]
  - [fill: e.g., "Accepted risks with owners and revisit triggers"]
  - [fill: e.g., "Launch communication"]
- **Decision authority:** [fill: e.g., "Product Lead for go/no-go; risk acceptance above threshold requires exec sign-off"]
- **Quorum (high-assurance only):** [fill]
- **Mode-specific notes:** [fill]

## Lifecycle / Health Review

- **Purpose:** Assess product health; decide continue-as-is, increase investment, harvest, or retire.
- **Frequency:** [fill: e.g., "quarterly" or "per major release cycle"]
- **Participants:**
  - Required: [fill]
  - Optional: [fill: e.g., "Finance (high-assurance), Support Lead, Sales Lead"]
- **Inputs:**
  - [fill: e.g., "Usage data (DAU/MAU, retention, adoption)"]
  - [fill: e.g., "Outcome metrics vs. expected"]
  - [fill: e.g., "Cost data (infrastructure, support, engineering allocation)"]
  - [fill: e.g., "Competitive intelligence and market signals"]
- **Outputs:**
  - [fill: e.g., "Lifecycle decision: Continue / Invest / Harvest / Retire"]
  - [fill: e.g., "Updated investment level and resource allocation"]
  - [fill: e.g., "Migration or customer communication plan (if retiring)"]
- **Decision authority:** [fill: e.g., "Product Council recommends; executive sponsor approves retire decisions"]
- **Quorum (high-assurance only):** [fill]
- **Mode-specific notes:** [fill]