Local vs. cloud: routing data with intent.

Three buckets, one principle CORE

Data classification sounds bureaucratic. It is not. It is the shortest way to turn “where should this go?” from a per-decision judgment call into a mechanical lookup — and a mechanical lookup is the kind of rule a tired student follows correctly at 11 p.m. when a judgment call would be wrong.

The three buckets Module 9 commits to:

• Public. Information that already lives on the open internet, or would be fine if it did. Examples: a Wikipedia article the student summarized, a public blog post, an open dataset, a news headline, a paragraph from a textbook, code from a public GitHub repository, a quote from a published book. The defining test: if a stranger read this tomorrow, would anything change? If nothing would change, it is public.
• Personal. Information about the student, their immediate household, or a third party the student has a relationship with, that the student has not chosen to publish. Examples: a draft of the student’s essay, a calendar event, an email thread, a note about a friend’s birthday, a meeting prep document, a research brief for a school project that has not yet been submitted. The defining test: would the student be fine if the same stranger read this tomorrow? If the answer is “I’d rather they didn’t, but it wouldn’t be a problem,” it is personal.
• Sensitive. Information whose disclosure would create real, non-trivial harm — to the student, their household, or a third party. Examples: medical or mental-health detail, financial-account specifics, immigration or legal status information, anyone else’s password or secret key, the student’s own credentials beyond what is already covered by Lesson 9.3, a third party’s private information the student was trusted with (a friend’s health situation, a sibling’s search history). The defining test: would the student or someone they care about experience real harm if a stranger read this tomorrow? If the answer is yes, it is sensitive.

The one principle that holds the scheme together: the lower a bucket’s tolerance for disclosure, the tighter the routing rule that follows must be. Public data may go anywhere. Personal data may go to cloud models whose terms the student has read and accepted. Sensitive data goes to a local model or not through an agent at all. The principle is mechanical and does not require judgment at the moment the data is about to be processed.

The scheme is deliberately coarse — three buckets, not seven. Finer classification schemes exist (some organizations use six or more tiers); they add complexity that one student cannot maintain. Three is the coarsest scheme that captures the distinction that matters: does disclosure matter? → no (public), yes but mildly (personal), yes and a real problem (sensitive).

What sensitive actually means (and why students under-classify it) CORE

The bucket students most often mis-classify is sensitive. The common failure mode is to label sensitive data as personal because the student does not, in the moment, feel threatened. The lesson’s correction: sensitivity is a property of what the data could become, not how the student feels about it right now. Three examples that students typically under-classify on first pass:

A friend’s mental-health remark in an email. A friend mentions in an email that they are struggling with anxiety. The student’s inbox triage agent processes the email. The friend’s mental-health status is sensitive — not because the student feels threatened, but because its disclosure would affect the friend. The student’s comfort is not the test; the friend’s downside is. An agent processing this email should not be running against a model whose terms allow training on user content, and the email body should not land in a shared-state folder that gets committed to git.

A financial-account digit a parent mentioned in passing. A parent texted the student the last four digits of their credit card to confirm a purchase. An agent summarizing the day’s messages reads the text. Those four digits are sensitive — not because a four-digit suffix alone is reconstructible, but because, combined with other information an attacker could find elsewhere (the parent’s name, approximate income, usual vendors), it moves them closer to an account-takeover. Information does not have to be standalone-catastrophic to be sensitive; contribution to a larger disclosure is enough.

The student’s own medical condition, even if “minor.” The student is being treated for something routine — allergies, anxiety, a skin condition. The student mentions it in a note they dictated for a personal-health-tracking agent to summarize. Medical information is sensitive by default, regardless of the student’s own assessment of its severity, because the downside of miscategorization is disproportionate (it affects insurance, employment, relationships in ways the student may not be able to fully predict at the moment of disclosure). The lesson’s rule: medical data is sensitive, full stop.

Two further notes on sensitivity:

• Sensitivity is sticky. Data that starts personal and later gets mixed with sensitive context inherits the sensitive rating. A summary of five emails is sensitive if any one of the five was sensitive. This is why the worksheet in the activity below asks you to rate data at the folder level as well as the artifact level: once a sensitive file has landed in a folder, the folder’s routing rule tightens.
• Third-party sensitive data is the hardest call. Most students are generous with their own data (“I don’t care if a cloud model sees my draft essay”) and stricter with data about others (“I would care if a cloud model saw my sister’s email to me”). The lesson’s guidance: when in doubt about a third party’s disclosure tolerance, rate up. Personal becomes sensitive; sensitive becomes “do not process through an agent at all.” The cost of being too conservative here is a slightly slower workflow; the cost of being too permissive is a trust breach with someone who did not consent to the routing.

Routing rules derived from classification CORE

The classification scheme is not the rule; the routing rule it implies is. Here is the rule Module 9 commits to.

Public data → any model. A Wikipedia article summarized by a research agent, a news headline triaged by an inbox agent, a public-repo code file reviewed by a coding partner. These can go to your cloud-default model, your local model, a cloud model you are evaluating, or a third-party MCP. Nothing about public data constrains the routing.

Personal data → vetted cloud model, or local. Personal data may go to a cloud model whose terms the student has read and accepted — which in practice means the default cloud model named in Module 2 (Anthropic’s Claude, OpenAI’s GPT family, or whichever the student committed to), and specifically the non-training-on-user-data tier of that provider if the provider offers one. Personal data does not go to cloud models the student has not vetted (most third-party-MCP-hosted models), to models whose terms allow training on user content without an opt-out, or to experimental models on platforms the student is trying for the first time. The local model is also a valid destination for personal data; the choice between local and vetted-cloud for personal data is a quality/convenience tradeoff, not a security one.

Sensitive data → local, or not through an agent at all. Sensitive data stays on the student’s own hardware. In practice this means: Ollama or LM Studio running a model the student pulled to their machine, with no network egress on the inference call. If the task genuinely requires a cloud-scale model to complete — if the local model cannot do the job well enough — the student’s options are (a) process the sensitive data themselves without an agent, or (b) redact/generalize the sensitive portions until the remaining task is personal-class, then route accordingly. The option that is not available is “just this once, I’ll send the sensitive data to the cloud model.” The whole point of the rule is that it is categorical, because exceptions are what lead to slow slips in posture.

There is an implicit fourth rule for data that is not supposed to be in an agent’s context at all: information the student does not own and was not given permission to redistribute. A friend’s private message forwarded to the student in confidence, an in-confidence document someone shared privately, a conversation overheard and written down. This data is not the student’s to route anywhere — not even locally — without the originator’s consent. Module 9 flags this once here and treats it as a responsibility question more than a routing question; Lesson 9.5 will revisit it under the ethics contract.

What about data that is public but embarrassing? A public tweet the student would rather not have their essay-writing agent process. The classification rule still applies: it is public (the test is “a stranger could read this tomorrow,” which for a public tweet is already true). The routing rule is “any model.” The student may choose to route it locally for their own comfort; that is fine, but it is a preference, not a security rule.

What about data that is personal but would become sensitive if combined with other data? The example from Content Block 2 — four digits of a card, plus the parent’s name — is the case. If the agent’s context will contain both pieces together, rate up: the combined artifact is sensitive, and the routing rule for the combined artifact applies to the agent call that reads both.

Finishing Section 3 (trust boundaries for the pipeline) CORE

Lesson 9.2 drafted Section 3 — Trust boundaries, and left the pipeline-specific portion for this lesson — because pipelines cannot be fully hardened until the data classification is done. Now do it.

For your frozen pipeline from Module 8 (/capstone/pipeline-v1/), add to Section 3 of the posture document:

• The pipeline’s data classification. Usually this is the strictest classification of any artifact the pipeline reads or writes. For most students, the frozen pipeline reads public data (web search results), produces personal data (summaries, drafts), and is therefore personal-class for routing purposes. If your pipeline touches sensitive data at any step, re-classify.
• The per-stage trust boundary hardening. For each stage, note the segregation-and-refusal framing applied to its prompt, and the containment (audience-only-you) applied to the pipeline as a whole. If a stage does not yet have segregation-and-refusal applied, add it now.
• The shared-state folder hardening. The folder where stages hand off to each other is, itself, an injection surface (Lesson 9.2, Surface 3). The hardening here is: (a) the downstream stage’s prompt treats upstream-stage output as untrusted (it applies segregation and refusal to the upstream output), and (b) the shared-state folder is not a folder any third-party MCP or unaudited plugin can read or write.

Note the sentence in the posture document marking Section 3 as complete, with the date. This is the only section that was split across two lessons by design; the completion marker is how you know you have closed the loop.

Walking your capstone and labeling every artifact RECIPE

This is the main hands-on block of the lesson.

What to walk. Your capstone folder is the authoritative set, but you have more artifacts than just what is under /capstone/. Use this checklist:

• Everything under /capstone/ — my-first-loop.md, workstation manifest, Module 3 codebase posture, Module 4 source posture, Module 5 inbox/calendar posture, Module 6 schedule register, Module 7 plugin/skill register, Module 8 pipeline blueprint, /capstone/pipeline-v1/ and its shared-state subfolders, /capstone/security-posture.md itself.
• Every scheduled-task definition and the folders those tasks read from and write to (from Module 6 and Module 8).
• Every agent’s “input sources” — which folders, which email labels, which calendar calendars, which URLs or URL patterns.
• Any notes-app page an agent reads, any sync folder an agent watches.

How to label. Open /resources/module-09/data-classification-table/ and fill one row per artifact (or per clearly-distinct group of artifacts — you do not need a row for every file in a public-repo source tree). Columns:

• Artifact — the file/folder/source, in plain language.
• Class — public / personal / sensitive.
• Reason — one phrase. (“Wikipedia article,” “my own unpublished essay draft,” “third-party mental-health context”).
• Routing rule — which models may process this artifact.
• Current routing — which models actually process it today.
• Gap? — yes/no. “Yes” if current routing does not match the required rule.

Honesty is the whole deal. The table is only useful if the “current routing” column is honest. Most students discover at least one gap — a folder they have labelled personal but whose contents have been read by a third-party MCP the student installed casually, or a file they now realize is sensitive but was being processed by their cloud-default research agent. The gap is not a failure of the lesson; the gap is why the lesson exists. The next block is the drill that closes the most important one.

Folder-level inheritance. When filling the table, work outside-in: label folders first, then walk their contents. The folder inherits the strictest classification of any child; a personal folder containing one sensitive file is a sensitive folder for routing purposes. This is why the /capstone/pipeline-v1/ shared-state folder is usually rated personal-or-sensitive on first pass — the research agent may drop a web-page quote (public) into the same folder where a personal email was previously summarized, and the folder’s rating is the strictest of any of its contents.

Re-routing one sensitive flow to a local model RECIPE

Pick the highest-impact gap from the previous block — the one where current routing is cloud and required routing is local — and re-route it. If your table has no such gap (some students’ systems do not touch sensitive data at all), create one for the drill: take a small sample of sensitive-class data (for example, three sentences of a personal health note), route it through your cloud-default once to see what happens, then re-route the flow so the same kind of data would go local next time. The drill is about having done the re-routing, so next time you need to do it in a hurry, you have.

## 2. Data classification

I classify data my agents touch into three buckets, with routing rules:

- **Public** (e.g., web pages, news, public repos): any model.
- **Personal** (e.g., my drafts, my calendar, my inbox): vetted cloud
  default (provider named in workstation manifest) or local model.
- **Sensitive** (e.g., medical, financial, others’ private info,
  credentials beyond Section 4): local model only, or no agent at all.

**Artifacts classified (summary — full table in
`/resources/module-09/your-completed-worksheets/data-classification-table.md`):**

- `/capstone/pipeline-v1/` → personal-class folder (inherits).
- Inbox (Module 5) → personal, with sensitive sub-category for emails
  matching <pattern>. See Section 3 for trust-boundary notes.
- Calendar (Module 5) → personal.
- <any sensitive-class flows that need special routing, named>

**Gaps found and closed:**
- <list>

**Gaps found and deferred (with deadline):**
- <list — there should be very few; any deferred gap has a date>