Mission
- Measurable outcome: By the end, you can lead a simulated technical review that distinguishes verification from validation, closes or assigns every blocking gap, and produces a defensible proceed/hold recommendation.
- Prerequisites: Chapters 3.1–3.3 and the Module 2 system model.
- Work product: A design-review evidence pack and decision record.
- Time: 75–100 minutes.
Before you read: Predict → Commit → Connect
Meridian’s teams show passing unit, contract, load, and security tests. Operators have not rehearsed a regional failback, and Finance Operations has not confirmed that the new exception workflow supports month-end settlement. Is the design verified, validated, ready, all three, or none? Commit and state what remains.
A review is an evidence-based decision mechanism
Verification asks whether the built result satisfies specified requirements and design intent: did we build it according to the defined requirements? Validation asks whether the result works for intended users and operations in the intended context: did we build a suitable system for the need? Readiness asks whether the integrated technical and organizational system can enter the proposed next lifecycle state with understood residual risk.
The phrases “built right” and “right thing” are helpful compression, not complete definitions. Validation includes operational use, not only Product preference. Readiness includes people, procedures, monitoring, support, suppliers, compliance, rollback, and decision authority.
Accessible diagram label: Verification compares the result to requirements and design, validation compares it to operational need, and readiness integrates both with operational and risk evidence.
A useful technical review has a decision purpose, entry criteria, evidence owners, reviewers with relevant authority, pre-reading, explicit gaps, and exit decisions. A slide presentation is not the review; the decision and learning mechanism is.
For Meridian’s regional traffic gate, the review question is: “May the program route 10% of eligible Canadian traffic while preserving defined payment, settlement, security, and recovery guardrails?” Evidence should trace from scenarios and requirements to results. A green checkbox without a link, environment, version, owner, or limitation is weak evidence.
Accessible diagram label: Meridian’s traffic decision draws on five evidence streams that converge in a visible gap and residual-risk register before authority decides.
Review packet
Keep the packet decision-sized:
- outcome, gate, and decision authority;
- ConOps scenarios and material changes since last review;
- system context and critical interfaces;
- requirement-to-evidence trace for guardrails;
- alternatives and unresolved decisions;
- maturity, security, privacy, reliability, and operational evidence;
- known gaps, waivers, conditions, rollback, and residual risk;
- recommendation and exact next state.
Evidence challenge
For every material claim, ask: What requirement or risk does this address? Which version and environment produced it? Is the condition representative? Who reviewed it? What failed? What was excluded? Can another team reproduce or interpret it? Does it validate actual operation, or only verify a component?
Do not weaponize review questions. Send entry criteria early and conduct working reviews before the gate. A late surprise may reveal withheld evidence, but it may also reveal a broken review mechanism. The TPM creates candor by making “not yet known” actionable and protecting the integrity of the decision.
Simulation evidence
Meridian presents:
- passing service functional and contract tests;
- load test at 1.3× forecast peak, but without the bank’s production latency profile;
- security review for the service, but not the new operations dashboard role;
- 24-hour shadow reconciliation with two unexplained discrepancies;
- routing rollback demonstrated in nine minutes;
- ledger-schema rollback not demonstrated;
- runbooks drafted; no overnight operator game day;
- Finance Operations says exception handling is unvalidated.
A defensible recommendation is hold traffic expansion, continue shadow operation, and close the discrepancy, access-control, schema rollback, and operational-validation gaps. The evidence supports component progress, not the proposed lifecycle transition. A constrained proceed could be legitimate only if named authorities show the gaps do not threaten the gate’s guardrails and policy permits conditional acceptance.
Decision rights: Who owns what?
Engineering and Architecture own design claims and technical evidence. Product and operational users own or contribute validation of intended use. Security, Privacy, Compliance, SRE, Quality, and Operations own their reviews according to policy. The named gate or launch authority decides. The TPM owns review design, traceability, evidence integration, gap closure, decision recording, and consequence propagation.
The TPM may recommend hold. The TPM does not manufacture approval through a meeting or silently convert a blocker into a follow-up.
I do
I open the Meridian review with the decision question and guardrails, not the schedule. I separate verified evidence from unvalidated operation. I show four blockers and their consequences, invite owners to challenge the classification, and ask the launch authority for an explicit hold/proceed/conditional decision. I update the integrated plan and schedule the next gate only after owners accept closure evidence.
We do
Run a 15-minute review. Assign Product, Engineering, SRE, Compliance, Finance Operations, and TPM. One person plays launch authority. Each participant gets one evidence item from the simulation. Decide which items are verification, validation, readiness, or gaps.
Show the model answer
Model answer
Functional, contract, and bounded load results provide verification, with environment limitations. Shadow reconciliation contributes integrated verification and validation but its discrepancies remain unexplained. Finance Operations’ unvalidated exception path is a validation gap. Missing overnight game day and schema rollback are operational-readiness gaps. Dashboard access is a security/readiness gap. Recommendation: hold 10% customer traffic, continue noncustomer shadow evidence where approved, close named blockers, and reconvene with versioned proof. The authority records the decision; the TPM propagates it.
Scoring rubric (0–4)
- 0: Proceeds because most tests are green or holds without explaining evidence.
- 1: Lists gaps but confuses verification, validation, and readiness.
- 2: Correctly classifies evidence and names a recommendation.
- 3: Traces blockers to guardrails, owners, closure evidence, and authority.
- 4: Also challenges environment relevance, records residual risk and dissent, defines the exact next state, and propagates plan effects.
You do
Prepare a 20-minute review for a real or fictional gate. Give the packet to a skeptical engineer and an operator 24 hours early. Ask each to identify the weakest evidence. Run the review; end with a named decision, conditions, owners, dates, and communication audience. Score yourself with the rubric.
Pause & Recall
From Chapter 3.1, retrieve the trace from need to evidence. From Chapter 3.2, explain how an alternative and revisit trigger improve a gate. From Chapter 3.3, name the six maturity dimensions. From Chapter 1.3, distinguish meeting owner from decision owner.
Production lens
After a gate, bind approvals to a version, scope, environment, and validity window. A new architecture, model, dependency, country, supplier, or traffic assumption may invalidate evidence. Conditional approval needs automated or governed limits and a named authority who can stop progression.
Workplace artifact: technical review record
Review / date / lifecycle gate:
Exact decision question and authority:
Outcome, ConOps scenarios, and guardrails:
Scope, version, environment, and changes:
Entry criteria met / exceptions:
Requirement or risk -> evidence -> owner -> limitation:
Verification conclusion:
Validation conclusion:
Operational and organizational readiness conclusion:
Security / privacy / compliance conclusion:
Open gaps, severity, owner, closure evidence, date:
Alternatives and rollback:
Dissent and unresolved uncertainty:
Recommendation:
Decision: proceed / conditional / hold:
Conditions, residual risk, and accepter:
Next state, actions, and communication audience:
Evidence expiry / revisit triggers:Chapter compression
Verification checks defined requirements and design; validation checks intended use and context; readiness integrates both with operational and organizational evidence. Reviews exist to make accountable lifecycle decisions, not to perform confidence. The TPM protects evidence integrity and decision closure without taking design authority.
Retrieval deck
- Q: What does verification ask? A: Whether the result satisfies specified requirements and design intent.
- Q: What does validation ask? A: Whether the result is suitable for intended users and operations in context.
- Q: What does readiness add? A: Integrated people, process, policy, support, recovery, and residual-risk evidence for the next state.
- Q: What is a review’s product? A: A recorded decision, conditions, gaps, owners, and consequence propagation.
- Q: When does evidence expire? A: When material version, scope, environment, dependency, or assumptions change, or its validity window ends.
Spaced review
- Now: Classify three Meridian evidence items as verification, validation, or readiness.
- 1 day: Classify three new evidence examples without notes.
- 3 days: Challenge one test’s version, environment, or limitation.
- 7 days: Rerun the review after one blocker closes and one assumption changes.
- 14 days: Inspect whether conditional approval limits remained enforced in production.