Skip to main content

Product-Scale Planning + Cross-Consistency Review

In one line: Detail the next executable slice, expose cross-milestone dependencies, and replan when evidence changes.

Use the approved product intent and existing enterprise records as the starting point. A PRD, decision register, roadmap and evidence record may already exist; link their authoritative versions instead of creating duplicate masters. Neither a particular six-document package nor a scheduler is required.

Planning outputs retain source confidentiality. Verify their actual destination audience and sharing authority; summarizing private evidence or labelling a report public does not authorize broader disclosure.

Four load-bearing rules:

  1. Resolution follows uncertainty and distance. The current milestone has reviewed tasks and acceptance evidence; nearby milestones define contracts and dependencies; distant work stays as hypotheses/sketches. Future open decisions identify an owner and resolution trigger. Dependent execution remains blocked until its required decisions and contracts are ready; independent work can continue.
  2. Review cross-consistency before dependent work. The seven concerns are: (a) exact existing decisions and effective schema, including later renames/drops; (b) capability handoffs from the verified baseline or explicit producer tasks, not just new files; (c) contradictions assessed within the same domain/version/environment; (d) precise existing migration references versus purpose/ordering for not-yet-created migrations; (e) effective nullability/constraints and business predicates; (f) existing or explicitly planned scaffold prerequisites; (g) valid test-data shapes with nonempty selection and correct expected outcomes. Record source revisions, observations, unknowns and affected tasks. Search discovers candidates; it is not semantic proof.
  3. Checkpoints preserve authority. Before the next dependent milestone, review delivered outcomes, gaps, discoveries, priority, capacity and the next plan revision with the accountable owner. Pause affected work immediately when a controlling assumption, business meaning, permission, integration or safety policy changes; do not defer that decision to milestone end. A reviewed plan or an “all clear” report is not itself a grant to commit, publish, deploy or change real data.
  4. Tests prove membership and outcomes. Required scenarios must actually be selected/executed and compared with expected results; empty all(...) and truthy state labels are insufficient. Exact counts are appropriate when the count is the intended contract, not when incidental. Recovery tests use actual starting/target revisions in authorized disposable environments; an explicit revision ID does not guarantee future downgrade compatibility or reverse external effects.

The operational skill additionally checks the adopted profile and executable roadmap, including capacity and the host's real continuation capabilities. Existing and legacy behavior is mined as evidence, reviewed by the BA and accepted by its business owner where meaning is involved. An urgent legacy fix triggers proportionate affected-scope reconciliation; it does not require continuous mining of a system that barely changes.

Evidence: the general cross-plan validators described in earlier editions are not shipped. A file's existence, text match, planned provider or growing test count cannot prove readiness. Use actual manual and executable evidence within its scope. The interface schemas validate record structure, not the approvals, current permissions or runtime transitions those records describe.

Operational procedure: skill:s4u-product-scale-planning. Review record, diagram and synthetic legacy example: Appendix L.