Cost as a security concern, not a separate one CORE
A pipeline that quietly consumes $200 of cloud spend before the student notices is a security failure of the same type as a leaked key: an unexpected cost caused by a missing rail, and a loss the student did not authorize and did not benefit from. Module 9 treats cost as part of the posture, not as a separate operational concern, for one reason: the same rail-making discipline that prevents secret leakage prevents cost runaway, and splitting the two topics into separate frames gives the student two lists to maintain instead of one.
The three horizons at which AI cost can run away:
The three cost horizons
| Horizon | What it controls | Where it lives | What happens when it hits |
|---|---|---|---|
| Single invocation | One pipeline run that costs 40× what it should — retry loop with no stop, wider-than-expected prompt, more workers than anticipated. | Pre-flight cost estimate (Module 8). Per-pipeline dollar and wall-clock budget on the blueprint. | The estimate falls outside the budget — you cut scope, swap a model, or raise the budget with a written reason before invoking. |
| Month | A series of individually-reasonable runs adds up to a monthly bill twice what the student budgeted. Each run was fine; the cadence was not. | Monthly AI-spend budget in Section 5 of the posture document. Provider-side alert at 70% of the budget. | The provider emails you. You open the console, read the real number, and decide: reduce cadence, or revisit the budget at the 90-day review. |
| Catastrophe | A bug, an injection-driven runaway, or a forgotten scheduled task produces a two- or three-orders-of-magnitude cost anomaly over hours or days. | Provider hard cap, set 2–3× above the monthly budget, in the provider’s billing console. | The provider refuses to serve past the cap. You open the incident loop — step 1, stop — before the bill moves further. |
The rails compose. Pre-flight catches the invocation-horizon runaway; budget-and-alert catches the month-horizon drift; the hard cap catches the catastrophe. A posture document without all three has a hole at one of the three horizons, and the horizon without a rail is the one the next incident will find.
The ethical layer of this framing: a cost the student cannot afford is a cost that affects someone else. A teen running their AI spend on their parents’ credit card has a stakeholder in the cost posture. An adult running it on their own card has a household budget that other expenses live inside. The monthly budget is not just a financial prudence knob; it is a commitment to the other humans whose money or attention the student is drawing on. Module 9 says this out loud because students under-acknowledge it.
Picking the monthly AI-spend budget CORE
The budget is a number you pick deliberately, once, and revisit at every 90-day review. Most Module 9 students will pick a number between $10/month and $60/month depending on pipeline intensity, provider, and who is paying. The specific number matters less than the fact that it was picked deliberately, which is the step most students skip.
Three honest questions to help land the number:
1. What did I actually spend in the last 30 days? Open the provider’s usage dashboard and read the actual bill — not your estimate, not your memory, the bill. Most students’ estimates are wrong in the same direction (they underestimate), so reading the real number is calibrating. If you do not have a full 30 days of history, note the shorter window and annualize conservatively (if you spent $5 in 10 days, budget for $18/month, not $15 — you do not know the variance yet).
2. How much can I afford to spend without causing problems for anyone else? This is the stakeholder question. For a teen: the number the parents agreed to, not the number the teen wishes for. For an adult: the number that fits in the household’s existing line-items without displacing something important. For anyone: a number you would be fine telling the reviewer from Content Block 4 you spent this month.
3. How much is the pipeline actually worth to me? An honest estimate of the value the student gets from the month’s worth of agent work. For students whose pipelines save them an hour a week of research time, the fair-value number can be substantial. For students whose pipeline is primarily a learning exercise, the number is small. This question is what keeps budgets from drifting upward just because providers’ prices move.
Take the lowest of the three answers — the real spend floor, the household-affordable ceiling, the fair-value estimate — and use that as the budget. Round to a round number you will remember.
Set the rails. Once the budget is picked:
- Alert threshold — set in the provider’s billing console at 70% of the budget. Most providers email you when usage crosses that line.
- Hard cap — set at 2–3× the budget. The cap is not a ceiling you expect to approach; it is the catastrophe-horizon rail that bounds a bad month.
- Re-read the cap from Lesson 9.3. You set a hard cap during the secrets-lesson work already. Reconcile: is the Lesson 9.3 cap at the right level relative to the budget you just picked? If not, adjust one or both. The posture document should have one cap, not two.
The recipe — set a hard cap in the provider console. The canonical step-by-step lives in /recipe-book/setting-a-hard-cap-on-cloud-spend/; the shape is:
# 1. Open the provider's billing console (OpenAI: Billing →
# Usage limits; Anthropic: Settings → Billing → Usage
# limits; cloud provider: varies by vendor).
# 2. Locate the "hard limit" or "usage cap" field. This is the
# number the provider refuses to serve past.
# 3. Enter a number 2-3x your monthly budget. If your budget is
# $30/month, the cap is $60-90. Round to a memorable number.
# 4. Locate the "alert threshold" or "soft limit" field. Set
# this to 70% of the monthly budget. If budget is $30, set
# the alert at $21.
# 5. Confirm the alert email address is one you actually read
# within 24 hours. Do not route it to a filtered folder.
# 6. Save. Re-open the settings page to verify the numbers
# stuck. (Some providers silently reject values above a
# ceiling the account has not verified past.)
# 7. Write the same two numbers, plus the date you set them,
# into Section 5 of /capstone/security-posture.md.Document. Write these numbers into Section 5 of the posture document — budget, alert threshold, hard cap, and the one-sentence reason the budget is at that level. The reason matters at the 90-day review, when the student will ask themselves “why is this number $30?” and would rather not re-derive it.
The four-step incident loop CORE
An incident in Module 9 is any event where the system did something the student did not authorize — a cost anomaly, a leaked secret (real or grey-zone), a pipeline runaway, an agent draft that was shaped by an injection, an auto-send that should not have happened, a plugin update that changed the plugin’s behavior past its audit, or any system behavior the student cannot fully explain within a few minutes of noticing it.
The response loop has four steps. Do them in this order.
The order is not arbitrary: stop first because a live incident compounds; assess before repair because fixing without knowing scope often misses the actual problem; tell one human after the first three because the one human does not want to be the first call for every blip, only for the ones that warrant it.
Naming the one human CORE
Pick one trusted person who will hear about every incident you cannot fully explain within 24 hours. The rules:
- One name, not a list. A list is a way to avoid telling anyone; one name is a commitment. You can have backup names in your own notes; the posture document names one.
- A real human with a real name, not a role. “My parents” is a list. “My mentor” is a role. “Dad, at 415-555-0143” is a human.
- Someone who will read a short factual message and respond with judgment, not panic or dismissal. A person who panics trains the student not to tell them. A person who dismisses does the same. The reviewer is someone who, when they receive your incident message, will respond with “OK, what happens next?” rather than “how bad is it?” or “don’t worry about it.”
- Someone whose trust you intend to keep. The point of the rule is that you are surfacing information to a person who has a reasonable interest in your building life and whose response helps you be a better operator of your systems. A reviewer who does not care about you, or whom you do not want to tell real things to, defeats the rule.
For most teen students, the honest reviewer is a parent. For homeschool students, one parent is usually the natural choice; the other is the backup. For adult self-learners, the reviewer is usually a spouse, a close friend with relevant expertise, a mentor from a previous job, or — if the student is lucky — an instructor from this or another course who has offered to play this role. If the student genuinely has no one in their life who fits all four criteria, they should treat that as the highest-leverage thing to notice from Module 9, because a builder without a reviewer has no brake on the “handle it alone” failure mode.
The one-human rule — Module 9’s new rail
You name the one human who hears about every incident you cannot fully explain within 24 hours — in writing, before you freeze.
Write the message template in advance. This is the piece most students skip. The template is three sentences to six:
Hi <name>,
I had an incident on <date, short>.
What happened: <one sentence>.
What I did: <one or two sentences — stop, assess, repair>.
What I'm not sure about: <one sentence — the thing
prompting this message>.
I'll let you know if I learn more or if the posture changes.The template lives in Section 6 of the posture document under a subheading Incident message template. You write it in Lesson 9.5 so it is ready before any real incident; you edit it once a year so it still sounds like you. Under pressure, the template is what you fill in — you do not have to compose it from scratch at the moment you want to least.
The responsible-builder posture CORE
This block is the ethics treatment Module 9 committed to. The claim is narrow and concrete: the student is responsible for everything their agents do, including the mistakes and the surprises, and that responsibility does not transfer to the model provider, the plugin author, or the open web.
What that means in practice:
- The cost the agent racked up is your cost. You wrote the pipeline, you set the rails, you pressed the button. “The model decided to retry more than I expected” is not a defense; you own the cost. This is why the budget and the cap exist.
- The email the agent almost sent is your email. “The triage agent misjudged” is not a defense; you installed the triage agent and set its scope. This is why audience-equals-you is a structural rule and not a preference.
- The citation the agent hallucinated is your citation. “The model got it wrong” is not a defense, at least not a complete one; you were the human who decided whether to use the output, and if you used it without checking, you own the claim it made. This is why the Module 4 work on spotting fabricated citations exists.
- The draft shaped by an injection is your draft. “A web page told it to” is not a defense; you directed the agent to read the page. This is why segregation, refusal, and containment all compose — and why the audience-equals-you rule makes the draft survivable instead of publishable.
This is not a list of guilt trips. It is a list of things the student committed to own when they signed up to build systems that act on their behalf. Owning the failures does not mean the student has to get everything right; it means the student does not shift the blame when things go wrong, and it means the student writes and maintains the posture document that makes “going wrong” predictable and small.
The public-commitment exercise. Write one paragraph, six sentences or fewer, that says what you commit to as a builder — in your own words, in plain terms, with no hedging. A student version might look like:
I direct AI systems that do real work on my behalf. I own what those systems do, including the mistakes I did not anticipate. I run them so the only person they deliver to is me; I keep my budgets deliberate and my secrets in one place; I know who I will tell when something goes wrong. When they fail, the fix is to tighten my rails, not to shift the blame. This is the deal I make with the tools and the people around me when I build.
The framing is welcoming to learners from any background. It does not argue the larger ethics of AI; it asks the student to take responsibility for the specific systems they have built. The paragraph goes in Section 6 of the posture document, under a subheading My commitment as a builder.
The incident drill RECIPE
This is the recipe block and the lesson’s centerpiece. The drill is required; posture without practice is theatre.
Pick a scripted scenario from /resources/module-09/incident-drill-scripts/. The worksheet has four:
- Scenario A — Cost anomaly. A pipeline ran overnight against a provider that has no current hard cap; the morning bill shows $38.74 of unexpected spend. You open your posture document — what is the four-step response?
- Scenario B — Grey-zone secret leak. Four weeks ago you pasted your cloud-provider API key into a Cowork-tab debugging conversation “just to rule something out.” You deleted the message. You just learned from a colleague that the conversation was transcribed for an unrelated support issue and the transcript was forwarded to two engineers at the vendor. What is the response?
- Scenario C — Injection-driven draft. Your research agent produced a weekly summary that includes a product recommendation you would not normally make and cannot explain. You discover a web page the agent read contained white-on-white instructional text. What is the response?
- Scenario D — Plugin behavior drift. A Cowork-tab plugin you installed three months ago received an auto-update. Its new behavior is subtly different — it is now logging queries to a URL you did not authorize. You learn about it from a forum post, not from the plugin’s changelog. What is the response?
Walk the scenario through the four steps. Do not short-circuit any step. Even the steps that feel obvious — “yes, I would stop the pipeline” — should be named in writing. The drill is slow deliberately; real incidents are fast, and the slow walk-through is how you build the muscle.
The recipe — run the scripted incident drill.
# 1. Open /resources/module-09/incident-drill-scripts/ and pick
# one of the four scenarios (A cost, B leak, C injection, D
# plugin drift).
# 2. Read the scenario twice. On the second read, note the
# specific numbers, dates, and names in the script -- these
# are the "facts" of your drill.
# 3. Work Step 1 (Stop). Write: exactly what you would stop,
# how you would stop it (the command, the click path, the
# kill-switch phrase from Module 8). Do not skip the
# sentence even if it seems obvious.
# 4. Work Step 2 (Assess). Answer the three questions in
# order: what did it touch, what did it spend, what did it
# produce. Use the numbers from the scenario; invent the
# rest plausibly.
# 5. Work Step 3 (Repair). Name the specific action: rotate
# the key, tighten the rail, delete the output, re-run the
# audit. Name the line you would add to the posture
# document.
# 6. Work Step 4 (Tell one human). Fill in the message
# template from Section 6 with the scenario's facts. Do
# not actually send it; the drill is the walk-through.
# 7. Write the after-action note (4-6 sentences): what you
# did at each step, what you would do differently in a
# real version, what rail needed tightening.
# 8. Append the after-action note to /capstone/security-
# posture.md under a subheading "Incident drill log."Write the after-action note. Four to six sentences. What you did at each step. What you would do differently in a real version of the scenario. What rail, if any, needed tightening. What sentence you would send to the reviewer (use the template from Content Block 4).
File the note. Add it as an appendix to /capstone/security-posture.md under a subheading Incident drill log. Like the rotation log, it grows over time — a real incident in six months adds a new entry.
Budget, cap, drill, freeze
Deliverables: Section 5 (Cost posture) and Section 6 (Incident loop) of the posture document; the one human named with their message template; one incident drill completed and logged; /capstone/security-posture.md frozen as the ninth capstone artifact.
Part 1 — Pick the budget and set the rails
Open the provider’s usage dashboard. Read the actual last-30-days spend. Walk the three questions from Content Block 2. Pick a budget. In the provider’s console, set the alert threshold at 70% of the budget and the hard cap at 2–3× the budget. Reconcile with the cap you set in Lesson 9.3. Verify by re-reading the numbers in the console.
Part 2 — Write Section 5
In /capstone/security-posture.md, fill Section 5 — Cost posture:
## 5. Cost posture
**Monthly AI-spend budget:** $<N>.
**Why this number:** <one sentence — tie to the three questions>.
**Alert threshold:** <70% of budget, set in <provider> console>.
**Hard cap (catastrophe rail):** $<M>, set in <provider> console.
**Stakeholders for this spend:** <self | household | named person
who is paying>.
**Next budget review:** <90 days out, matched to posture review>.Part 3 — Name the one human and write the template
Pick the one human. Write their name, how you will reach them (the channel matters — text, email, a specific messaging app), and the message template adapted for your own voice. Put this at the top of Section 6.
## 6. Incident loop
**The one human I tell:** <name>, via <channel>.
**Backup (not a list — for my notes only, named here as a
reminder):** <name>.
**My incident message template:**
Hi <name>,
I had an incident on <date>.
What happened: ...
What I did: ...
What I'm not sure about: ...
I'll let you know if I learn more or if the posture changes.
**My four-step loop:**
1. Stop — <how, on each path I run: kill the pipeline, disable
the task, revoke the plugin, rotate the key as appropriate>.
2. Assess — <the three questions: what did it touch, what did
it spend, what did it produce>.
3. Repair — <specific actions I typically take; update this
over time>.
4. Tell one human — <within 24h if I cannot fully explain it>.Part 4 — Write the commitment paragraph
At the bottom of Section 6, add a subheading My commitment as a builder and write the six-sentence-or-fewer paragraph from Content Block 5. Use your own words. This is the paragraph you would be willing to put your name on in public.
Part 5 — Run the incident drill
Pick one of the four scenarios from the incident-drill-scripts worksheet. Walk it through all four steps. Write the after-action note. Add it as the first entry under a subheading Incident drill log at the bottom of Section 6.
Part 6 — Freeze the posture document
Fill in the Last reviewed date at the top of the file (today). Fill in the Next review date (≤ 90 days out — pick a specific date, not “in about three months”). Confirm every section is complete — no “TBD,” no placeholders. Save. The file is now the ninth frozen capstone artifact. Open my-first-loop.md and add one line under the Module 9 retrospective subheading: “Security posture frozen 2026-04-24. Next review: 2026-07-23.” (Substitute your actual dates.)
If you did not complete one of the sections in a prior lesson
Sections 1–4 should already be complete from Lessons 9.1–9.4. If any are not — for example, the Section 2 data-classification table has rows that still read “TBD” — go back and finish them before freezing. The posture document’s value depends on its being complete; a frozen document with blanks is a document whose blanks will stay blank. Take the extra half-hour.
After the freeze, a word on what happens next
You are about to start Module 10, the capstone. The posture document you just froze is the document Module 10’s documentation will reference more than any other. If your Module 10 capstone combines components you have not yet brought under your posture (a new agent, a new MCP, a new data flow), the right move is to update the posture document before the capstone ships, not after. The posture is the frame; the capstone sits inside it, not past it.
Done with the hands-on?
When the recipe steps and any activity above are complete, mark this stage to unlock the assessment, reflection, and project checkpoint.
Quick check
Three questions to test whether the loop landed. Answers follow.
- A student has a $40/month budget, a $120 hard cap, and a 70% alert threshold. Their pipeline spends $45 in one week because of a bug. Which rail catches this, which rail should have caught it earlier, and what is the student’s first move?
- A student’s posture names five people as “who I’ll tell.” What does Module 9 say about that?
- Under the four-step loop, why is stop first and tell one human last? What failure mode would each out-of-order version produce?
Check your answers
(1) The alert threshold at 70% of the monthly budget (= $28) should have caught it earlier — the alert fires when the month’s spend crosses $28, and $45 in a week would have tripped the alert days before it accumulated. The hard cap at $120 has not been hit yet. The student’s first move is step 1, stop — kill the pipeline now, before investigating — because the bug is still producing spend. Then steps 2–4 in order, ending with a message to the reviewer if the student cannot fully explain the bug within 24 hours.
(2) A list is a way to avoid telling anyone. The Module 9 rule is one name. The student should pick one, put backup names in their own notes, and commit.
(3) Stop first because a live incident compounds — an investigation while the system is still running can cost more than the original incident. Tell one human last because the one human is for incidents the student cannot fully explain; the first three steps are what the student does alone to become able to explain. The out-of-order failure modes: “investigate without stopping” produces compounding losses; “tell one human without stopping” produces a panicked conversation with no information in it and wastes the reviewer’s trust for the incidents that warrant it.
Freeze the posture document
Freezing the posture is mostly a renaming and a commitment. The work is already done across Lessons 9.1–9.5; the freeze is the promise to stop editing it without a reason.
The six sections of the frozen /capstone/security-posture.md — walk each line; check every box:
- ☐ Section 1 — Threat model. Three adversaries named (careless self, hostile internet, supply chain); four out-of-scope categories named. Lesson 9.1.
- ☐ Section 2 — Data classification. Every class of data your pipelines touch, each with a sensitivity tier and a handling rule. No “TBD” rows. Lesson 9.2.
- ☐ Section 3 — Trust boundaries. The segregation-and-refusal framing, audience-equals-you reaffirmed, the list of untrusted inputs each agent reads. Lesson 9.2.
- ☐ Section 4 — Secrets posture. Vault location, rotation schedule, plugin register with permission lists and last-audit dates. Lessons 9.3–9.4.
- ☐ Section 5 — Cost posture. Monthly budget, alert threshold (70%), hard cap (2–3×), stakeholders, next budget review. Lesson 9.5 Part 2.
- ☐ Section 6 — Incident loop. The one human named with channel; the message template; the four-step loop in your own words; the commitment paragraph; the first incident-drill entry. Lesson 9.5 Parts 3–5.
- ☐ Header dates. Last reviewed = today. Next review = ≤ 90 days from today (pick a specific calendar date, not “about three months”).
The frozen file’s header looks exactly like this:
# Security Posture — <your name or handle>
**Last reviewed:** 2026-04-24
**Next review:** 2026-07-23 (≤ 90 days)
**Frozen as:** /capstone/security-posture.md (ninth capstone artifact)
---
## 1. Threat model
<three adversaries, four out-of-scope categories — Lesson 9.1>
## 2. Data classification
<sensitivity tiers and handling rules — Lesson 9.2>
## 3. Trust boundaries
<segregation, refusal, audience-equals-you — Lesson 9.2>
## 4. Secrets posture
<vault, rotation schedule, plugin register — Lessons 9.3 & 9.4>
## 5. Cost posture
<budget, alert, hard cap, stakeholders — Lesson 9.5>
## 6. Incident loop
<one human, message template, four steps, commitment,
incident drill log — Lesson 9.5>Freeze commands. Fill in the Last reviewed date (today). Fill in the Next review date (≤ 90 days out). Confirm no section reads “TBD.” Save. Open my-first-loop.md and add one line under the Module 9 retrospective subheading:
Security posture frozen 2026-04-24.
Next review: 2026-07-23.The file is now the ninth frozen capstone artifact. It sits alongside /capstone/pipeline-v1/ (Module 8), /capstone/custom-plugin-v1/ (Module 7), and the earlier frozen artifacts. Module 10 will reference it more than any other.
Quiz
Four questions. Click each to reveal the answer and the explanation.
- (A) Cost is technically classified as a security metric in industry standards.
- (B) Because the same rail-making discipline that prevents secret leakage prevents cost runaway — splitting them into two frames gives the student two lists to maintain instead of one, and a cost a rail did not catch is the same category of loss as a key a rail did not catch.
- (C) Cloud providers require cost monitoring as part of their security agreements.
- (D) Cost is a proxy for other security concerns; tracking cost is really a way of tracking unauthorized access.
Show explanation
Answer: B. Because the same rail-making discipline that prevents secret leakage prevents cost runaway — splitting them into two frames gives the student two lists to maintain instead of one, and a cost a rail did not catch is the same category of loss as a key a rail did not catch.
Why: This is the framing of Content Block 1. (A) “cost is technically a security metric” is not an argument. (C) “providers require it” is out of scope. (D) “cost is only a proxy for other security concerns” is not the lesson’s claim — cost is a first-class concern, not a proxy.
- (A) "What did I actually spend in the last 30 days?"
- (B) "How much can I afford to spend without causing problems for anyone else in my household?"
- (C) "How much is the pipeline actually worth to me?"
- (D) Any of the above — skipping any one of the three leaves a gap. The three together produce a number; the budget should be the lowest of the three answers.
Show explanation
Answer: D — any of the above. The three questions together produce a number; skipping any one leaves a gap. “Seems reasonable” is what students land on when they have not taken the budget seriously.
Why: Each of the three is a real failure mode on its own. (A) “what did I actually spend last month” — skipping it means the number is disconnected from reality. (B) “how much can I afford without causing problems for anyone else” — the stakeholder question; skipping it means the budget may displace something important in the household. (C) “how much is the pipeline worth to me” — skipping it means the budget has no bound tied to value. The correct response is to pick the lowest of the three answers.
- (A) Investigate first — stopping the pipeline mid-run might lose data.
- (B) Stop the pipeline first, then investigate. Investigating a live incident compounds it; the stop is cheap and reversible.
- (C) It depends on how expensive the investigation is going to be.
- (D) The "stop first" order only matters for secret-leak incidents, not cost incidents.
Show explanation
Answer: B. Stop the pipeline first, then investigate. Investigating a live incident compounds it; the stop is cheap and reversible.
Why: This is the stop first rule of Content Block 3. (A) “investigate first; stopping might lose data” is the exact failure mode the rule prevents. (C) “it depends on how expensive the investigation is” treats the order as optional, which is how students end up with compounding incidents. (D) “the order only matters for secret leaks” is wrong — the order applies to all incidents.
- (A) Three is better than one — more people watching for incidents is safer.
- (B) The rule is one name. A list is a way to avoid telling anyone. Pick one; the others can be backups in the student's own notes.
- (C) Two is enough — one primary, one backup.
- (D) Any list works as long as at least one of the people listed will respond when contacted.
Show explanation
Answer: B. The rule is one name. A list is a way to avoid telling anyone. Pick one; the others can be backups in the student’s own notes.
Why: This is Content Block 4’s rule. A list defeats the commitment. (A) “three is better than one,” (C) “two is enough,” and (D) “any list works as long as someone responds” are all variations on the evasion the rule is designed to prevent.
Reflection prompt
Write a short paragraph (6–8 sentences) in your journal or my-first-loop.md in response to the following:
Read your commitment paragraph from Section 6 out loud. Does it sound like you — is it a sentence you would be willing to put your name on, in public, if someone asked? If not, what is off? Who is the one human you named, and did you actually send them a message this week telling them you are their “one human”? (If not, send it; the commitment is real when they know they are the named person.) Looking back over the last nine modules, what has changed most in how you think about the systems you are building — what you used to believe AI work was, versus what you now believe it is?
The purpose is to let the weight of the posture land. Students who freeze the document without reading it aloud often discover, on re-reading, that a phrase is off or that a commitment sounds more confident than they are. That mismatch is the thing to fix before Module 10. The posture is yours; the voice should be yours.
Project checkpoint — the ninth frozen artifact
By the end of this lesson, you should have:
- Monthly budget picked deliberately, alert threshold set at 70%, hard cap set at 2–3× budget — all reflected in the provider’s console and in Section 5 of the posture document.
- Section 6 complete: the one human named with channel and message template, the four-step loop written in your own words, the commitment paragraph, and the first incident-drill entry.
- Every prior section (1–5) complete with no “TBD” blanks.
- /capstone/security-posture.md frozen with Last reviewed and Next review dates filled in. Ninth frozen capstone artifact.
- One line added to my-first-loop.md under the Module 9 retrospective subheading recording the freeze and the next review date.
Ninth frozen capstone artifact. /capstone/security-posture.md is your Module 9 deliverable and becomes the document Module 10 will reference more than any other. A capstone component in Module 10 that would require loosening your posture is a component you redesign, not a posture you loosen.
End of Module 9
Close the module with the end-of-module check.
Ten questions across the posture document — threat model, data classification, trust boundaries, secrets, cost, incident loop. This is the mastery gate for Module 9 credit; the parent / instructor rubric is included.
Coming next — Module 10
Module 10 — Capstone: ship your agentic system.
Module 10 is the capstone. You pick three integrated agentic components your system will combine (some mix of the skills, plugins, and pipelines you have frozen across Modules 6–8), document the composed system against the posture you just froze, deploy it so it actually runs, and produce a short video walkthrough. The frozen /capstone/security-posture.md is the first document the capstone design refers to — a component that would require loosening your posture is a component you redesign, not a posture you loosen.