Week 24: Complete the controlled pilot, handover, and graduation defense

Direct answer: Week 24 closes Capstone M6 and M7 into one honest delivery loop: first, based on the Week 23 decision, choose a "real authorized pilot" or a "course-controlled simulation," recording tasks, failures, safe end states, and human burden one by one; then have someone who did not participate in development complete deployment, random re-verification, on-call duty, and rollback using only the handover package; finally, defend with the same set of evidence to three audiences — the boss, frontline staff, and engineers. Without real authorization, take the simulation track and state clearly that it cannot prove user adoption or ROI; if there is a hard technical NO-GO, the author must rescue things on-site, or prohibited effects occur, the graduation date cannot serve as a green light.

Which segment of the evidence chain is completed this week

Heading "Which segment of the evidence chain is completed this week"

Week 24 is not about adding more features, but about checking whether the evidence from the previous 23 weeks can be consumed by a real or credibly simulated delivery process:

业务决定与价值机制  → 一线任务、例外、保护与替代路径  → 数据、权限、RAG 与 MCP 边界  → 第 23 周发布决定  → 真实授权试点 或 课程受控模拟  → 任务结果、失败、人工负担与产品反馈  → 非作者部署、值守、降级、回滚  → 老板 / 一线 / 工程三听众答辩  → 毕业、补证、缩小或停止

The earlier evidence must not be "polished into a nicer story" in this week. When new contradictions are found, keep the original records, update the judgment, and clearly explain why it changed.

What is the difference between a real authorized pilot and a course-controlled simulation?

Heading "What is the difference between a real authorized pilot and a course-controlled simulation?"

Both tracks can train an FDE in the full delivery process, but they support different conclusions:

Real authorization must be written as a decision

Heading "Real authorization must be written as a decision"

At minimum, record:

[D] 授权角色、日期与适用组织→ 候选版本和允许任务→ 参与人数上限、时间窗与环境→ 允许的数据、外部效果和人工支持→ 监测、停止、回滚与通知条件→ 谁可以暂停，谁可以重新批准

Verbally saying "you can give it a try," getting a system account, or receiving a dataset does not equal full pilot authorization.

Frontline participant protection remains a hard gate

Heading "Frontline participant protection remains a hard gate"

Whether it is a real pilot or a simulation with peer participants, you must explain in advance the purpose, recording method, scope of visibility, and use; allow participants to skip, correct, stop, and withdraw; direct supervisors must not observe research targeted at individuals; do not pass identifiable quotes to management without consent; records must not be used for personal performance reviews or disciplinary action. Without data authorization, use only synthetic, sandboxed, or anonymized replays, and do not ask participants to bypass permissions or take on extra work they did not consent to.

When conditions are not met, the correct record is "pilot not conducted due to insufficient authorization or protection," then move to the course simulation — rather than quietly lowering the standard.

Mental model: look at the task, the system, and the handover capability at the same time

Heading "Mental model: look at the task, the system, and the handover capability at the same time"

Week 24 must answer three different questions:

• Task layer: Does the goal the person needs to accomplish reach the correct end state? Refusal, escalation, or manual substitution is sometimes a safe success, but it does not mean the business task is complete.
• System layer: Are quality, safety, latency, cost, and recovery signals still within the approved boundaries? Stop immediately if prohibited effects occur.
• Handover layer: Without the original author, can another operator deploy, judge, mitigate, recover, and roll back?

Therefore, do not just count "how many answers were given." An honest task ledger must at least separate:

任务目标是否完成≠ 系统是否进入正确安全终态≠ 用户是否选择采用≠ 业务是否产生因果改善

Look at the finished product first: the Beichen course simulation loop

Heading "Look at the finished product first: the Beichen course simulation loop"

The following is a course-fixed synthetic completion example. It demonstrates how to complete a high-quality Capstone without real enterprise authorization, without faking a pilot. Beichen, the candidate version, peer roles, tasks, times, and all numbers are scenario values designed by the author, not results run from this repository. Your submission must replace them with your own real rehearsal records.

1. Track and entry decision

Heading "1. Track and entry decision"

In the Week 23 example, rc3 was NO-GO due to a prohibited effect from one approval reuse. This example assumes the learner later formed rc4 according to the recovery rules and re-passed the Week 23 technical hard gate using another sealed final blind newly created by an independent custodian; to demonstrate the Week 24 fill-in, the course scenario subsequently allowed only a controlled simulation because there was no real authorization. All of the above are scenario inputs, not claims about real fixes, blind tests, or authorization.

capstone_version: northstar-capstone-rc4track: controlled_course_simulationreason: no_real_customer_or_data_authorizationtechnical_release_gates: passed_in_this_synthetic_scenarioallowed:  - synthetic_policy_corpus  - simulated_ticket_service  - informed_peer_role_play  - isolated_fault_and_rollback_drillsnot_allowed:  - real_employee_data  - production_connections  - claims_of_adoption_or_roistop_conditions:  - any_forbidden_fact_or_effect  - participant_withdrawal  - rollback_cannot_restore_task_contractgraduation_claim_scope: course_capstone_evidence_only

2. Task, failure, and human burden ledger

Heading "2. Task, failure, and human burden ledger"

The simulation is driven by fixed role cards, with 12 scripted tasks in total. The table below shows representative per-case records:

When aggregating, keep different denominators at the same time:

window: one_90_minute_course_simulationscripted_task_attempts: 12scripted_role_goal_completed: 8scripted_role_goal_completion_rate: 8/12expected_safe_terminal_state_matched: 12safe_contract_match_rate: 12/12tasks_with_human_steps: 6/12manual_fallback_tasks: 3/12operator_intervention_tasks: 2/12total_human_minutes: 36human_minutes_per_scripted_task: 36/12forbidden_effects: 0/5_adversarial_stepsevidence_scope: synthetic_role_play_only

The 8 / 12 here is "scripted role goal achieved," not a user adoption rate; the 36 minutes is the total of all human confirmations, manual substitutions, and operator interventions across the 12 tasks, and is not a real employee burden baseline.

manual_fallback_tasks

Counting only tasks that went through the existing manual substitution process,

operator_intervention_tasks

counting fault and reconciliation interventions, which may overlap; normal protective steps such as preview confirmation only count toward

tasks_with_human_steps

. The representative table does not list all 12 tasks, so the summary must be able to link back to the complete task ledger; the denominator cannot be guessed from the few visible rows.

3. Non-author deployment, on-call duty, and rollback

Heading "3. Non-author deployment, on-call duty, and rollback"

The synthetic handover record uses the codename

peer-operator-02

to represent a course peer who did not participate in the implementation. The codename is just an example; learners must obtain informed participation from real peers, keep verifiable records, and respect their privacy choices.

The rollback target must be a "known-good version"; you cannot go back to rc3 from Week 23, which had a security block. If the author must stand by and verbally tell the other party hidden steps, this handover round is judged a failure; first write the missing content into the runbook, then have a non-author redo it from scratch.

4. Synthetic Rubric Scoring and Evidence Mapping

Heading "4. Synthetic Rubric Scoring and Evidence Mapping"

The task ledger and handover records alone cannot yet justify "graduation." The synthetic teaching scorecard below links each of the eight scoring items of the project contract back to evidence; the scores are designed to demonstrate the calculation, and are not the real grades of this repository or any learner:

The five individual gates must also be calculated separately: RAG 12 / 15, MCP 12 / 15, security 12 / 15, evals 13 / 15, operations 8 / 10 — each no lower than 60% of its full score. In the synthetic scenario, cross-tenant leakage, unauthorized writes, real secrets entering the repository, duplicate external effects, and inability to execute rollback are all 0; if any of these is not 0, graduation is impossible even with a total score of 82.

5. Simulated Conclusion and Permitted Portfolio Statements

Heading "5. Simulated Conclusion and Permitted Portfolio Statements"

## 毕业决定
- 课程 Capstone：合成计分 82 / 100，五个关键项均过单项门，项目硬阻断为 0；通过受控模拟轨的技能与交接门槛- 真实试点：[U] 未进行，原因是没有客户、数据和系统授权- 已证明：固定合成任务中的行为合同；隔离环境中的部署、值守、降级和回滚可由非作者执行- 未证明：真实用户采用、生产可靠性、客户业务改善、长期人工负担和 ROI- 允许表述：完成企业 RAG + MCP 助手的受控模拟交付，并由非作者复验部署与回滚- 禁止表述：已为某企业上线、获得用户采用、降低成本或产生 ROI

This is a qualified course graduation boundary. An honest simulation proves FDE judgment better than a fabricated "successful customer pilot."

Can you enter a pilot after a NO-GO?

Heading "Can you enter a pilot after a NO-GO?"

No. Only candidates and scopes explicitly permitted in Week 23 may enter a real pilot; when evidence is insufficient or invalid, "failure not yet proven" must not be interpreted as a GO either. Isolation exercises can train shutdown and handover, but cannot substitute for pilot authorization or graduation evidence.

First triage by decision:

If what is being fixed is a hard technical NO-GO, you must return to Week 23 to generate a new candidate and a new final blind sealed by an independent custodian, then form release evidence. For an evidence-type NO-GO, if only the evidence index or independent verification is missing, fill it in and re-decide; if the blind test has leaked or the fix changed the candidate, a new sealed set is also required. The calendar moving from Week 24 to Week 25 does not change this requirement. If the technical gate has passed but the real pilot was stopped due to insufficient value, authorization or protection, do not fabricate a pilot; an honest simulation and shutdown handover can demonstrate course capability, but still cannot produce launch, adoption or ROI claims.

Once Week 24 substantially modifies code, model/prompts, corpus/index, ACL, policies, tools, MCP Server, schema or deployment package, the current activity is immediately paused: generate a new candidate and return to Week 23 to re-gather evidence. A real pilot also requires a role with authority to re-bind the authorization to the new candidate; authorization for the old version cannot be inherited automatically.

Step 2: Write the track and authorization card

Heading "Step 2: Write the track and authorization card"

Choose one of the two input types below; you cannot mix them.

A. Real authorized pilot card

Heading "A. Real authorized pilot card"

# 真实授权试点- [D] 授权角色、范围与日期：- 候选版本与发布决定：- 参与角色、人数上限和招募方式：- 任务、时间窗、数据与外部效果：- 目的、记录、可见范围和用途说明：- 跳过、纠正、停止和撤回方式：- 非参与者与主管隔离方式：- 成功、保护、人工负担和停止指标：- 值守、通知、降级与回滚负责人：- 试点结束后的保留、删除和复查：

The following is only a fictional field-filling example, not a real authorization. Beichen, roles and dates are all synthetic scenarios; the real track must be re-signed by an actual role with authority for an actual candidate, and this card cannot be copied to obtain permission:

record_type: fictional_filled_authorization_example_onlyorganization: 北辰培训情景（虚构）authorized_by: 试点业务负责人（虚构角色）decision_date: 2026-09-12candidate: northstar-capstone-rc5release_decision: limited_go_exampleparticipants: 最多6名自愿参加的A业务单元客服；直属主管不旁听个人任务window: 5个工作日；每天09:00-17:00allowed_tasks: 查询当前退款政策；预览并逐次批准一张主管复核工单allowed_data_and_effects: A单元获准政策；隔离试点队列；每次最多一张可取消工单participant_controls: 任务前说明记录与用途；可跳过、纠正、停止、撤回approved_degradation_recovery_gate:  version: fictional-pilot-recovery-gate-v1  safe_state_within: 2_minutes  recover_or_enter_approved_degraded_state_within: 30_minutes  approved_by: 虚构业务、安全与技术角色  approved_at: 2026-09-12stop_conditions: 任一禁止事实或效果；参与者撤回；未满足approved_degradation_recovery_gateoperators: 虚构运营负责人值守；虚构安全负责人可立即暂停retention: 情景任务记录14天后删除；脱敏汇总由虚构决定人复查claim_boundary: 仅示范卡片结构，不证明存在组织、授权、参与者或试点结果

B. Course simulation card

Heading "B. Course simulation card"

# 课程受控模拟- 使用合成材料的原因：- 候选版本与隔离环境：- 角色卡和脚本任务：- 模拟服务与明确禁止的真实连接：- 同伴知情参与与退出方式：- 要演练的失败、人工路径和回滚：- 能证明什么：- 不能证明采用、生产结果或 ROI：

Checkpoint: After removing the heading, have a peer look only at the content. If they cannot tell whether it is a real pilot or a course simulation, the boundary is still not qualified.

Step 3: Pre-define the task ledger

Heading "Step 3: Pre-define the task ledger"

For each task, write out before execution:

task_id→ 角色与场景→ 目标角色要完成的目标；模拟轨必须写“脚本角色目标”→ 当前替代流程或基线→ 使用的数据与权限→ 预期回答 / 拒答 / 升级 / 预览 / 写入终态→ 禁止事实与禁止效果→ 允许的人工帮助→ 停止条件

After execution, append the actual final state, failure category, human minutes, operational intervention, links,

run_id

and next action. Do not delete failed tasks, and do not count a "security refusal" as "role goal completed" at the same time.

Denominator discipline for the real track

Heading "Denominator discipline for the real track"

If you need to describe usage behavior, record at least separately:

• the number of people meeting pilot eligibility;
• the number invited and giving informed consent;
• the number who actually initiated at least one task;
• the number of task attempts;
• the number of tasks reaching the target final state;
• the numbers of abandonments, refusals, escalations, failures and human takeovers;
• the observation time window and data sources.

Even if someone keeps using the system in a real pilot, you may only describe observations within this sample and window. Without a control and causal design, do not attribute changes to the system; without a full-scope cost accounting, do not calculate or promote ROI.

Denominator discipline for the simulation track

Heading "Denominator discipline for the simulation track"

Use "scripted tasks," "role-play steps" and "drill operators"; do not write "users," "adoption rate" or "production tasks." Human time is simulated execution time, not the real burden of target employees.

Step 4: Turn failures and human burden into product feedback

Heading "Step 4: Turn failures and human burden into product feedback"

Classify the task ledger item by item into:

Lower human burden is not always better. Some high-risk steps should inherently require human approval; what to judge is whether the burden is necessary, acceptable, visible, and who bears it — not deleting protections for the sake of automation rate.

Product feedback is not a license to change features mid-activity. Once code, model/prompts, corpus/index, ACLs, policies, tools, Server/schema, or the deployment package changes substantively, stop the current activity, generate a new candidate, and return to Week 23 to re-gather evidence; the real track must also re-bind authorization.

Step 5: Let a non-author take over using only the handoff package

Heading "Step 5: Let a non-author take over using only the handoff package"

The handoff recipient must not have participated in the implementation. You can ask a peer, mentor, or open-source reviewer to do this in a synthetic environment; if you can't find a second person, you may self-test first, but you must not record the self-test as a passed non-author handoff.

Week 18 already taught how to write runbooks and design rollbacks; this week is not about rewriting them, but about having a non-author consume the complete Capstone handoff package. The reviewer should draw normal, refusal, permission, and write tasks from the versioned handoff random re-verification pool, and randomly inject one fault into the model, index, or MCP, checking whether the old documentation can truly guide a new maintainer.

This re-verification pool is not the Week 21–23 final blind. The final blind was unblinded after its first run in Week 23 and can only continue to serve as regression; the handoff random draw only proves that a non-author can operate and re-verify, and does not produce a new blind-test conclusion. If a new blind test is still needed, it must be built and sealed by an independent custodian.

The handoff package must contain at least:

范围、非目标、负责人和升级路径→ 架构、数据、权限与版本 manifest→ 部署前检查和明确部署步骤→ 正常 / 拒答 / 升级 / 受控写入冒烟任务→ 仪表盘、告警、开关和 runbook→ 数据迁移、索引、策略、MCP 与外部状态回滚→ 结果不明时的对账→ 回滚后的任务级复验→ 当前 NO-GO、未知和已接受风险

Handoff test rules

Heading "Handoff test rules"

• The author hands over the package first; the operator reads it independently first;
• The operator deploys in a clean environment and records every blocking point;
• The author must not use verbal hints to paper over documentation gaps before the record is made;
• The operator draws cases from the versioned handoff random re-verification pool, then does one on-call session for an authorized fault drill whose type and timing they did not know in advance; this random pool does not masquerade as the final blind;
• The operator performs a full versioned package rollback;
• After the rollback, re-run normal, refusal, escalation, and controlled writes, and reconcile external state;
• If it fails, fix the package and have a non-author re-execute; do not manually change the result to pass in the table.

"The non-author understood the documentation" is not evidence; the state changes they actually completed and the re-verification are.

Step 6: Use the same evidence for a three-audience defense

Heading "Step 6: Use the same evidence for a three-audience defense"

Don't prepare three unrelated success stories. Build an evidence index first, then adjust the framing:

Three framings of the Beichen completion example

Heading "Three framings of the Beichen completion example"

Boss version

What this course simulation supports is "whether it's worth applying for a restricted policy-confirmation pilot," not a company-wide rollout. Of the 12 scripted tasks, 8 completed the scripted role's goal, all 12 reached the expected safe terminal state, and all human steps totaled 36 minutes. Since there was no real authorization, these numbers cannot prove adoption, efficiency, or ROI; a real pilot next would require re-approving participants, data, systems, and observation metrics.

Frontline version

The system only answers based on current, visible, and sourced policies. When evidence is insufficient, outdated, or unauthorized, it explains why and hands off to a human; before creating a ticket it shows a preview, and after parameters change it requires re-confirmation. Participants in drills can skip, correct, or stop at any time, and records are not used for performance evaluation.

Engineering version

rc4 binds the corpus, retrieval, prompts, policies, MCP, evals, and deployment versions. In the isolated simulation, approval changes, cross-role actions, and unclear results all entered predefined states; a non-author, using the handoff package, completed a clean deployment, an on-call index fault, and a rollback from the faulty configuration to a known-good version, then re-ran the four task types after the rollback.

All three passages cite the same track card, 12 tasks, rc4 manifest, and handoff records. The boss version doesn't dress the simulation up as real value, the frontline version doesn't hide failures, and the engineering version doesn't pass the role card off as actual production.

Step 7: Build the graduation evidence index

Heading "Step 7: Build the graduation evidence index"

Graduation is not about file counts; it's about a stranger reviewer being able to trace from a decision back to the original evidence:

M0 问题与风险合同├─ 业务决定、价值机制、一线任务、保护与非目标M1 数据与访问├─ 语料、ACL、候选隔离与缓存M2 有引用问答├─ 回答、拒答、冲突、过期与失败分类M3 受控 MCP├─ 预览、逐次审批、写入、幂等、对账与审计M4–M5 发布证据├─ 冻结候选、盲测、安全、负载成本、故障与决定M6–M7 试点 / 模拟与交接└─ 任务、失败、人工负担、非作者运营、答辩与复盘

The final decision can only be one of:

• Graduate: the technical hard gates and project Rubric have passed, all applicable thresholds for the current track have verifiable evidence, and the conclusion's boundaries are honestly stated;
• Supplement evidence: the implementation may be correct, but non-author reproduction, denominator, authorization, or sources are incomplete;
• Shrink: only a narrower task, data, tools, or population can pass;
• Stop: the problem, protection conditions, or hard risks do not support continuing.

"Project Rubric passed" here follows the explicit thresholds of the Capstone contract:

• Total score of at least 80 / 100;
• Each of the five areas — RAG, MCP, security, evals, and operations — must reach at least 60% of that area's full score; high scores elsewhere cannot compensate;
• If any one of the following exists — cross-tenant leakage, unauthorized writes, real secrets entering storage, duplicate external effects, or an unexecutable rollback — the Capstone fails outright.

When business value is insufficient, real authorization is missing, or protection conditions don't hold, a correct NO-GO or scope reduction can still demonstrate decision-making ability; as long as the technical hard gates and project Rubric have passed, the course can still be completed with an explicit simulation. A hard technical NO-GO caused by cross-scope leakage, unauthorized effects, duplicate effects, real secrets, or an impossible rollback means the Capstone has not passed and must be fixed and re-evidenced. Hiding blockers, tampering with thresholds, or faking a pilot is disqualifying on any track.

Five-day schedule

Heading "Five-day schedule"

This week's deliverables

Heading "This week's deliverables"

Recommended to produce in your own Capstone:

docs/pilot-or-simulation-contract.mddocs/task-ledger.*docs/failure-and-human-burden-report.mddocs/product-feedback.mddocs/handoff.mddocs/graduation-decision.mdops/handoff/deployment-record.*ops/handoff/on-call-record.*ops/handoff/rollback-record.*evidence/final-index.mddemo/executive-outline.mddemo/frontline-outline.mddemo/engineering-outline.md

The public portfolio should only contain synthetic or publicly permitted, de-identified evidence; private authorizations, participant information, sensitive source material, and credentials must not enter the repository on the grounds of "needed for graduation."

This week's acceptance

Heading "This week's acceptance"

Common gates for all tracks

Heading "Common gates for all tracks"

• The Week 23 decision permits the current activity; a NO-GO has not been bypassed by the calendar;
• If Week 23 was a hard technical NO-GO, the current activity is only labeled as an isolated exercise or a shutdown handover, not masquerading as M6 or graduation;
• If Week 23 evidence is invalid or insufficient, first complete re-review, denominators, or a new sealed blind test, without writing "unknown" as a pass;
• Track, candidate, tasks, data, external effects, window, owner, and stop conditions are explicit;
• Each task separately records the real-role goal or scripted-role goal and the safety end state, linked to verifiable evidence;
• Failures, refusals, escalations, human takeovers, and abandonments have not been removed from the denominator;
• Human burden states total minutes, task denominator, roles borne, and data sources;
• Any prohibited fact or effect stops the activity and reopens the decision;
• Any material change to the candidate pauses the activity, generates a new version, and returns to Week 23; a real pilot authorization re-binds the version;
• A non-author completes deployment from a clean environment, and the author's ad-hoc prompts have not been hidden;
• A non-author completes on-call, loss mitigation, recovery or degradation, full rollback, and task-level re-verification;
• Rollback covers the applicable parts of code, configuration, corpus/index, policies, tool schemas, migrations, and external state;
• The three defenses—boss, frontline, and engineering—cite the same evidence chain;
• The graduation card distinguishes proven, unproven, unknown, limitations, and next review conditions;
• The project total score is at least 80 / 100, and each of the five items—RAG, MCP, security, evals, and operations—reaches 60% of that item;
• Cross-tenant leakage, unauthorized writes, real secrets entering the repository, duplicate external effects, and non-rollbackable states are all 0;
• Public materials contain no real secrets, non-consented participant information, or customer data.

Additional gates for a real authorized pilot

Heading "Additional gates for a real authorized pilot"

• An empowered role has explicitly authorized with dates, scope, and candidate version;
• Participants know the purpose, recording, use, and visibility scope, and can skip, correct, stop, and withdraw;
• The direct supervisor does not observe personal research, and records are not used for performance or disciplinary action;
• Adoption or usage behavior has qualifying denominators such as conditions, invitations, consent, attempts, and tasks, plus a time window;
• Conclusions are limited to the current sample and window, with no unfounded extrapolation or causal ROI.

Additional gates for the course-controlled simulation

Heading "Additional gates for the course-controlled simulation"

• Only synthetic corpora, isolated services, and approved tools are connected;
• Participating peers know this is a course exercise and are not described as customers or target employees;
• Reports use accurate names such as "scripted tasks, role-play, simulated environment";
• No claims of user adoption, customer satisfaction, production reliability, business improvement, or ROI.

Common failures and recovery

Heading "Common failures and recovery"

Independent migration: supply chain material-shortage coordination

Heading "Independent migration: supply chain material-shortage coordination"

Migrate the Beichen policy confirmation to "a supply chain planner queries supplier lead times and substitute-material rules, and after per-instance approval creates a material-shortage escalation ticket." Independently complete:

• Decide whether it is a real authorized procurement-team pilot or a synthetic supply chain role simulation;
• Design 10–15 tasks covering normal queries, contract conflicts, expired lead times, unauthorized factories, parameter changes, unclear supplier API results, and stale indexes;
• Separately record task completion, safety end states, human verification, escalation, and reconciliation burden;
• Have someone not involved in the implementation deploy and run on-call once through a supplier API failure;
• Roll back from the failed candidate to a known-good version and confirm no duplicate escalation tickets;
• Defend separately to the supply chain lead, planners, and platform engineers.

Without real enterprise authorization, use synthetic suppliers, orders, factories, and escalation tickets. You may claim "completed a controlled supply chain simulation," but not claims of reducing line stoppages, improving supplier fulfillment, gaining adoption, or generating ROI.

Final check of the three-layer explanation

Heading "Final check of the three-layer explanation"

• Boss version: Explain the supported decision, the value-realization mechanism, alternatives, current evidence, cost and human burden, hard risks, and continue-or-stop conditions; do not package simulations or short-term observations as ROI.
• Frontline version: Explain which step of the work changes, how sources are verified, when it must refuse, re-approve, hand over to a human, or stop; how participants and feedback can exit, without treating guardrails as resistance.
• Engineering version: Explain how a candidate version, data and permissions, evals, security, traces, load, failures, reconciliation, deployment, rollback, and non-author handover can be reproduced.

If any layer needs to hide facts from the other two to hold up, the evidence chain still hasn't graduated.

Where to go after the course

Heading "Where to go after the course"

This standard track ends at week 24 and does not invent a mandatory week 25. Continue based on your next goal:

Your portfolio may omit sensitive details, but it cannot omit key failures, simulation boundaries, or NO-GO decisions. Your interview narrative can be shorter, but it cannot be more confident than the evidence.

Adjacent weeks

Heading "Adjacent weeks"

• Previous week: Week 23: Making the Capstone release decision with evidence
• Course index: 24-week FDE learning track

Sources and factual boundaries

Heading "Sources and factual boundaries"

• NIST AI RMF Generative AI Profile: a reference for generative AI risk governance, measurement, and ongoing management.
• Google SRE: Monitoring Distributed Systems: a reference for user-symptom-oriented monitoring and operational judgment.
• Palantir: Forward Deployed Software Engineer: a reference for customer collaboration, engineering implementation, and end-to-end delivery responsibilities.

This page was fact-checked on 2026-09-12. Beichen, rc4, the 12 script tasks, peer codenames, all minutes, and conclusions are synthetic teaching completion examples, not actual customers, users, authorizations, operations, or business results. This week's course threshold is not any employer's uniform graduation or hiring standard; completing the simulation does not prove production safety, adoption, efficiency, customer value, employment outcomes, or ROI. The item-by-item verification status of the Google SRE links can be found on the sources page.