Week 19: Freeze the Capstone's Problem and Risk Contract

Direct answer: In Week 19, don't integrate more technology. Your job is to compress the business, frontline, and engineering evidence gathered over the first 18 weeks into a Capstone M0 contract that can be approved, approved with conditions, rejected, or revoked. The contract centers on "which business decision Week 24 will support, which frontline step it will change, and which risks must never happen" — not "I want to build a RAG + MCP project."

What M0 freezes, and what it doesn't

Title "What M0 freezes, and what it doesn't"

What M0 freezes is the problem and risk boundary that the next phase must jointly adhere to:

业务决定  ↕ 核对一线任务、异常与人工兜底  ↕ 约束数据、权限、安全、成本与参与者保护  → 第 20–24 周需要补齐的证据  → 继续 / 缩小 / 停止的条件

It does not freeze the technical implementation. If Week 20 reveals that the data boundary doesn't hold, you can narrow the scope or stop; you cannot rewrite the problem just to preserve an architecture you've already drawn.

First, attach an evidence label to every important statement:

Statements like "everyone needs this," "it will definitely improve efficiency," or "customers will use it" should be downgraded to assumption or unknown if they have no source.

Look at the finished product first: Beichen Capstone M0

Title "Look at the finished product first: Beichen Capstone M0"

The following company, process, roles, numbers, and approvals are all fixed synthetic course examples.

The decision Week 24 will support

Title "The decision Week 24 will support"

Whether it's worth continuing a restricted "customer service policy confirmation" pilot: ordinary customer service agents review current, authorized policy sources before replying to customers; they escalate when encountering conflicts, outdated content, or no answer; and only after the agent confirms each time can the system create a supervisor review ticket.

This is not a company-wide launch approval, nor "letting AI handle customer service automatically."

Scope and non-goals

Title "Scope and non-goals"

Knowns, assumptions, and unknowns

Title "Knowns, assumptions, and unknowns"

M0 decision

Title "M0 decision"

decision_id: northstar-m0-v1decision: course_simulation_approved_with_conditionsscope: one_role_one_task_one_exception_one_approved_effectconditions:  - M1_negative_access_matrix_passes  - no_missing_acl_document_enters_candidates  - all_external_effects_require_fresh_approvalreopen_if:  - role_or_data_scope_changes  - frontline_workload_increases_beyond_agreed_boundary  - a_forbidden_effect_or_access_leak_occursdoes_not_authorize:  - real_customer_data  - production_deployment  - autonomous_actions

This example passes because value is still labeled as an assumption, real adoption is still unknown, and the course's simulated approval has not been written as organizational authorization.

Step 1: Build evidence lineage, don't copy old documents

Title "Step 1: Build evidence lineage, don't copy old documents"

Create a table for the key artifacts from the first 18 weeks:

Each item can only have one primary decision:

• Reuse: scope and version still apply;
• Revise: the core can be kept, but roles, data, or risks have changed;
• Retire: conflicts with the new problem or is no longer valid;
• Incomplete: not enough evidence yet.

More old files doesn't mean stronger evidence. If evidence can't answer the current decision, don't force a citation just to make your portfolio feel complete.

Step 2: From the boss's goal to the frontline task

Title "Step 2: From the boss's goal to the frontline task"

Use these five questions to connect the two levels of conversation:

• What decision does the boss ultimately need to make, rather than what features do they hope to see?
• Which task of which frontline role affects this decision?
• What are the normal path, exception path, and human fallback respectively?
• Which step does the system change, and whose judgment must be preserved?
• Which observable outcome would support continuing, and which protective metric or hard risk would require stopping?

One-page problem and risk contract template

Title "One-page problem and risk contract template"

# Capstone M0 问题与风险合同 v1
## 决定第 24 周，谁要根据哪些证据决定继续、缩小还是停止什么？
## 当前一线任务- 主要角色：- 触发条件：- 正常步骤：- 一个关键异常：- 当前人工兜底与责任人：- 一线明确不愿失去的判断权：
## 范围- 一个任务：- 一个异常：- 一个允许的写效果（若有）：- 数据和角色边界：- 非目标：
## 指标与证据状态| 指标或主张 | 基线 | 类型：事实/推断/假设/未知 | 来源 | 第几周验证 || --- | --- | --- | --- | --- |
## 硬风险与停止条件| 风险 | 不可接受结果 | 检测证据 | 负责人 | 触发后的动作 || --- | --- | --- | --- | --- |
## 批准、异议与重开条件分别记录业务、一线、数据/安全和工程角色的结论；不要用一个统一签字代替不同责任。

Step 3: Write metrics as value mechanisms, not promises

Title "Step 3: Write metrics as value mechanisms, not promises"

Every candidate metric answers six things:

• Which decision the metric supports;
• Which roles and tasks it applies to;
• What the numerator, denominator, time window, and source are;
• Whether the current baseline is a fact, simulated, or genuinely unknown;
• What alternative explanations might affect it;
• Which protective metric prevents "optimizing the number while harming the frontline."

For example, "average handling time decreased" cannot stand alone. A more complete mechanism is:

当前查找步骤与等待时间（待真实测量）  → 有依据的政策候选减少部分查找  → 一线仍确认或升级  → 观察任务时长与返工同时保护：权限泄漏 = 硬停止；错误政策不得被更快地送达

Without authorized traffic, the baseline remains unknown. Course replays can only validate the calculation method or expose process gaps.

Step 4: Conduct a four-party readback and produce a decision record

Title "Step 4: Conduct a four-party readback and produce a decision record"

Have four responsibility perspectives read back the same M0:

When real roles are unreachable, role-playing is allowed, but every item must be marked as simulated. Recording dissenting opinions matters more than pursuing a table where "everything passes."

Five-day schedule

Title "Five-day schedule"

This Week's Acceptance

Title "This Week's Acceptance"

• The contract centers on business decisions and frontline tasks, not technical names;
• the normal path, one key exception, the human fallback, and the responsible person are clear;
• every major claim carries a fact, inference, assumption, or unknown label;
• data, permissions, security, cost, and participant protection enter the hard constraints;
• the judgment authority retained by the frontline and any new burden are explicitly recorded;
• every piece of legacy evidence is judged as reuse, revise, retire, or incomplete;
• M0 explicitly lists the evidence not yet completed for weeks 20–24;
• business, frontline, data/security, and engineering opinions are recorded separately;
• the decision includes scope of application, conditions, objections, review date, and reopening conditions;
• without real authorization, write only "course-simulated approval";
• M0 does not authorize real data, production deployment, or autonomous write operations.

Common Failures and Fixes

Title "Common Failures and Fixes"

Independent Migration: Supply Chain Exception M0

Title "Independent Migration: Supply Chain Exception M0"

Replace the Beichen customer service case with "supply chain exception confirmation," but keep only:

• one decision the boss must make, e.g., whether to continue a restricted exception-handling pilot;
• one frontline role, e.g., procurement operations;
• one task, e.g., verifying the basis for an exception and forming a recommendation;
• one exception, e.g., conflicting supplier status;
• one approval-per-step effect, e.g., submitting an expedited review request;
• one hard stop condition, e.g., cross-supplier data leakage or duplicate procurement effects.

Write M0 first, then judge whether RAG, MCP, or multi-tenancy is really needed. Technology is not the default answer.

Explaining the Same Evidence to Three Audiences

Title "Explaining the Same Evidence to Three Audiences"

• Boss version: What decision must be made in week 24, how value could be generated, and what the current facts, assumptions, unknowns, and stop signals are.
• Frontline version: Which step changes, which judgments are retained, who takes over when an exception occurs, and how to refuse, exit, or roll back.
• Engineering version: Which versions are reused, what is retired, what the hard boundaries are, and in which week each remaining risk is validated.

Next Steps

Title "Next Steps"

Only proceed to Week 20: Connecting Capstone Data and Access Boundaries once M0 has received the corresponding authorization or is explicitly marked as course-simulated approval. If the role, data scope, or risk changes, version it first and re-read M0.

Sources and Fact Boundaries

Title "Sources and Fact Boundaries"

• GOV.UK Service Manual — Understand users and their needs: A reference for starting research from user tasks and actual needs rather than preset solutions.
• NIST AI RMF Playbook: A reference framework for governing, mapping, measuring, and managing AI risks.
• Palantir — Forward Deployed Software Engineer: A reference for customer collaboration, problem decomposition, and end-to-end delivery responsibilities; the job page may change.

Verification date: 2026-08-25. M0, evidence labels, week numbers, and acceptance gates are the teaching structure of this course, not an industry-wide standard. The Beichen case, replays, metrics, and decisions are all synthetic material; without real organizational authorization, they must not be extrapolated into customer needs, adoption, financial value, or production approval.