Mission
- Measurable outcome: By the end, you can assess a program across component, integration, operational, and evidence maturity; design one feasibility probe; and expose at least three hidden integration risks.
- Prerequisites: Chapters 3.1–3.2 and Module 2.
- Work product: A maturity-and-integration evidence map.
- Time: 65–85 minutes.
Before you read: Predict → Commit → Connect
Every Meridian component passed its team test. No region has yet processed a complete payment through bank response, ledger, settlement, reconciliation, rollback, and operator recovery. Is the program 90% ready? Predict a more honest statement. Commit to the next evidence-producing action. Connect this to Chapter 1.1’s “all projects green” trap.
Component progress is not integrated maturity
Feasibility asks whether an approach can satisfy the need within relevant technical, operational, cost, schedule, legal, and organizational constraints. Maturity is the strength of evidence that a technology or system can perform in its intended context. Technical debt is a design or implementation condition that increases the cost, risk, or delay of future change. Integration risk is uncertainty or exposure created when parts, owners, or lifecycle activities must work together.
Technology Readiness Levels provide a disciplined maturity language in some government and engineering contexts, but they are not a universal software completion percentage. The GAO warns that readiness should be assessed in relevant environments with evidence. A mature component can still be embedded in an immature system.
Accessible diagram label: Readiness progresses through component, interface, integrated-system, operational, and outcome evidence; strength at one level does not guarantee the next.
Assess multiple dimensions separately:
- Technical: architecture, performance, failure behavior, security, and scalability.
- Integration: contract compatibility, shared state, environments, sequencing, and end-to-end tests.
- Operational: observability, staffing, runbooks, capacity, recovery, support, and change control.
- Evidence: relevance of environment, test coverage, data quality, recency, and independent challenge.
- Organizational: stable ownership, decision capacity, supplier readiness, and training.
- External: regulatory, certification, vendor, and customer constraints.
An average maturity score can hide a fatal zero. Show dimensions and blocking evidence individually.
Use confidence language alongside maturity. “Demonstrated repeatedly in a representative environment” is stronger than “team believes feasible,” even if both receive the same dashboard color. State what has been observed, under which conditions, and what remains an inference. This makes uncertainty reviewable instead of embedding it in a percentage.
Accessible diagram label: Feasibility claims are decomposed into consequential unknowns, each addressed by a targeted evidence-producing probe before updating the decision.
A good feasibility probe reduces a specific decision uncertainty. It is not a demo optimized to impress. Define the claim, hardest unknown, representative environment, success and stop conditions, timebox, owner, and how the result changes the decision. A prototype may demonstrate technical possibility but not operability, scale, security, or total cost.
Technical debt matters to the program when it crosses boundaries or constrains options. Examples include a shared library that prevents independent upgrades, undocumented data semantics that block migration, manual certificate renewal that threatens launch regions, or a test environment that cannot reproduce production identity. Do not label every disliked code choice “debt.” Record the future consequence, triggering change, probability or uncertainty, and remediation or containment option.
Hidden integration risk concentrates at:
- ownership seams where no team controls the end-to-end behavior;
- late-arriving environments, test data, devices, certificates, or vendor access;
- version coexistence and rollback paths;
- manual operational or compliance handoffs;
- assumptions that each team interprets differently;
- dependencies whose schedule shows delivery but not qualification;
- retirement work omitted from the “new system” plan.
At Meridian, a vendor sandbox is “available,” but it uses synthetic identifiers and cannot demonstrate settlement behavior. That milestone is an output, not evidence of production-relevant integration maturity.
Decision rights: Who owns what?
Engineering owners assess component feasibility and debt. Architects assess system consequences. SRE, Security, Quality, Compliance, and Operations assess their readiness dimensions. Finance and business owners assess affordability and value. The TPM integrates claims, evidence relevance, cross-team probes, blockers, and decision effects.
The TPM should not assign a maturity level by intuition. Domain owners supply evidence; governance defines required acceptance.
I do
I replace “90% complete” with: “All three regional components passed isolated functional tests; end-to-end settlement, failure recovery, and operator readiness remain unverified in a production-relevant environment. Traffic expansion is blocked on shadow reconciliation and a timed rollback rehearsal.” This is less comforting and more decision-useful.
We do
Helios has a model that passes offline evaluation, but retrieval uses sanitized data, tool permissions are mocked, and support agents have not rehearsed escalation. Together assess maturity dimensions and select the first probe.
Show the model answer
Model answer
Model-component evidence exists, but integrated, security, operational, and outcome maturity are weak. The next probe should target the highest-consequence uncertain path: a production-like, permission-aware end-to-end scenario using approved representative data, real retrieval controls, constrained tools, human approval, audit logs, and failure injection. Offline model quality remains useful but cannot support a launch claim by itself. Privacy and Security approve test-data and access conditions; Engineering owns implementation; Operations validates workflow; the TPM integrates evidence and gate consequences.
Scoring rubric (0–4)
- 0: Calls the system ready because the model passed.
- 1: Lists missing tasks without maturity or evidence reasoning.
- 2: Separates component, integration, and operational maturity.
- 3: Prioritizes a decision-relevant probe with owners and conditions.
- 4: Also assesses evidence relevance, stop criteria, residual debt, and how results alter the launch decision.
You do
Choose a program labeled 70–90% complete. Ban percentages for one review. Ask each owner to state claims and evidence. Map maturity dimensions and identify the weakest necessary link. Design a timeboxed probe that could disconfirm the favored plan.
Pause & Recall
From Chapter 3.2, what makes an experiment decision-relevant? From Chapter 2.2, name two coexistence risks. From Chapter 2.4, explain why feedback speed changes feasibility strategy. Recall the distinction between output and outcome evidence.
Production lens
Maturity can regress when scope, environment, model, supplier, traffic, team, or dependency changes. Attach evidence to versions and conditions. Revalidate after material changes. Track debt service and retirement work in the integrated plan rather than a someday backlog.
Workplace artifact: maturity and feasibility map
Decision / feasibility claim:
Intended environment and use:
Technical maturity evidence:
Interface / integration evidence:
Operational and recovery evidence:
Security / privacy / quality / regulatory evidence:
Organizational and supplier readiness:
Evidence limitations, version, and date:
Weakest necessary link:
Debt item and future consequence:
Highest-consequence unknown:
Probe, environment, success/stop criteria, and timebox:
Owner / reviewers / decision changed by result:
Blocking gap and residual-risk authority:Chapter compression
Component maturity is not system readiness. Assess technical, integration, operational, evidence, organizational, and external dimensions. Use targeted probes to reduce decision uncertainty. Treat debt as a future consequence and make seams, coexistence, and retirement visible.
Retrieval deck
- Q: What does feasibility ask? A: Whether an approach can meet the need within relevant constraints.
- Q: Why not average maturity dimensions? A: A blocking zero can disappear inside an attractive average.
- Q: What makes a probe useful? A: It targets a consequential unknown under relevant conditions and changes a decision.
- Q: When is debt program-level? A: When it constrains cross-team options, timing, risk, cost, or operation.
- Q: Can maturity regress? A: Yes; material context, version, dependency, or organization changes can invalidate evidence.
Spaced review
- Now: Replace one percentage-complete claim with evidence language.
- 1 day: List the six maturity dimensions without notes.
- 3 days: Design a probe for the weakest necessary link.
- 7 days: Inspect whether one “done” milestone includes qualification evidence.
- 14 days: Revisit a probe result after the system or environment changes.