Build Your Personal Assistant Operating System

5.2

Protect Privacy, Attention, and Agency

A powerful system with no boundaries eventually feels invasive

The more your second brain knows, the more useful it becomes. It also becomes more capable of surfacing things you did not want surfaced, storing things you did not want stored, and acting in ways you did not intend. The line between helpful and invasive is not a technical boundary. It is a set of decisions you make deliberately.

These projects build the boundaries before you need them. Privacy tiers control which modules see which records. Approval boundaries define what the assistant can do independently and what requires your review. Source confidence marks which facts are verified and which are guesses. Sensitive data splits separate raw data from safe summaries. Do-not-remember protocols exclude entire categories from storage.

Boundaries are not limitations. They are design decisions that make the system trustworthy. A system you trust gets more data, more corrections, and more use. A system that feels invasive gets abandoned.

A stylized teaching image showing privacy tiers, approval gates, and exclusion zones around a shared memory store — Boundary projects create the trust architecture that makes the system safe to use with personal data.

Privacy tiers control which modules see which records

Every record type in gets a : full access (any can read), restricted (only specified modules can read), or local-only (stored on your device and never sent to any cloud service). You assign the tier when you define the record type.

Contact names and interaction dates are typically full access: every benefits from knowing who you met and when. Financial transaction details are typically restricted: only the finance module and the need to see specific amounts. Journal entries containing personal reflections are typically local-only: they live on your device and never leave it.

The tier assignment is a one-time decision per record type, revisited when your comfort level changes. If you start using the system for health tracking and later decide it feels too exposed, you change the health records to local-only without affecting other record types.

Approval boundaries define the line between helpful and overstepping

Each already has an from its . This project reviews and tightens those boundaries across the whole system. For every module, you answer: what can the assistant read, summarize, draft, suggest, schedule, save, or never do?

The boundary answers come in layers. Level one (safe): read data, summarize findings, surface patterns. Level two (draft): draft replies, propose tasks, suggest reconnections. Level three (act): send an email, reschedule a meeting, create a calendar event. Most readers keep the assistant at level two: draft and suggest, never act without explicit approval.

Approval boundary levels

Level	What the assistant can do	Example
Read and summarize	Read sources, produce summaries, surface patterns	Read your calendar and tell you about scheduling conflicts
Draft and suggest	Draft replies, propose tasks, suggest actions	Draft an email reply for your review before sending
Act with approval	Execute an action after you approve	Send the drafted email after you confirm
Never	Actions the assistant must never take	Never delete contacts, never share data externally, never send without approval

The boundary exists before the assistant acts, not after. Setting the boundary is a proactive design decision. Discovering the boundary after the assistant did something unexpected is a failure. These projects front-load the decisions so the system operates within limits you defined.

Source confidence marks which facts are verified and which are guesses

accumulates facts from many sources. Some are directly observed (Sarah's email said the deadline is Friday). Some are inferred (the assistant guessed David's role from his email signature). Some are uncertain (the assistant thinks this contact is the same person mentioned in a meeting, based on name similarity). Source confidence marks each fact so modules that use it know how much to trust it.

The confidence audit reviews existing records and flags low-confidence fields. The assistant checks: which fields came from a verified source (email header, calendar event)? Which were inferred (email signature, domain name)? Which are stale (last verified more than 90 days ago)? The audit produces a report you can act on: verify this role, update that date, confirm or delete this guess.

Sensitive data splits separate raw details from safe summaries

Your finance might process raw transaction data: $847 to CloudHost on May 3, $1,200 from Atlas Corp on May 5. The needs to know your spending patterns, but does it need every transaction? The sensitive data split stores raw financial data in a restricted record type and produces an aggregated summary for the weekly review: 'Spending this month: $3,200, up 15% from April. Two invoices outstanding.'

The same split applies to health data. Raw health metrics (blood pressure readings, medication schedules) stay in local-only records. The sees only what you allow: 'Exercise: 4 days this week. Sleep: averaged 7 hours.' The raw data stays protected. The summary provides enough for the review without exposing details.

The split is the design that makes sensitive data usable. Without it, you either expose raw details to every or exclude sensitive categories entirely. The split gives you a middle path: protected storage with safe summaries.

A do-not-remember protocol excludes entire categories from storage

Some information should never enter the system. You might decide: never store specific medical diagnoses, never record salary negotiations, never capture arguments with family members, never save passwords or financial account numbers. The do-not- remember protocol defines these exclusions before they come up.

When you tell the assistant 'do not remember this,' it should honor the instruction immediately. The protocol goes further: it defines categories of information that the assistant should exclude even if mentioned in passing. If you have a rule that says 'never record health diagnoses,' and a meeting note mentions someone's medical condition, the assistant skips that detail during capture.

The protocol also handles retroactive requests. If you realize the system has stored something you want removed, you can ask the assistant to find and delete all records matching a category or keyword. The deletion is logged (so you know it happened) and the exclusion rule is saved (so it does not happen again).

How this module breaks

What goes wrong	How you notice	What to correct once	What rule to save
A reads a restricted record type because the was set incorrectly.	The morning brief includes a financial transaction detail that should only be visible to the finance .	Audit the map. Correct the record type's tier and re-check which modules are authorized to read it.	After changing any , verify by asking each to summarize what it can see. Unauthorized access should result in no data returned, with a log entry noting the denied request.
The do-not-remember protocol has gaps because the exclusion categories are too narrow.	The assistant stores a detail about a family argument because the rule says 'never store health data' but says nothing about personal conflicts.	Review the exclusion list quarterly. Add categories as new types of sensitive information arise. The protocol is a living document.	The do-not-remember protocol is reviewed quarterly alongside the . New exclusion categories can be added at any time. The assistant asks for clarification when it encounters content that might fall under an existing exclusion.
Source confidence flags are ignored because modules display facts without showing confidence levels.	A presents David's role as 'Senior Product Manager' without noting that this was inferred from an email signature four months ago.	Add a display rule: any field with medium or low confidence must show a flag when surfaced in a dossier or brief.	Fields with medium or low confidence display a flag in briefs and dossiers: '(inferred)' for medium, '(unverified)' for low. High-confidence fields display without a flag.

Your turn

Build your privacy tier map and approval boundaries

You'll produce a privacy tier map, approval boundaries for each module, and a do-not-remember protocol that protects your most sensitive information.

Why this exercise matters

Boundaries are what make the system trustworthy enough to use with personal data. A system without clear boundaries gets abandoned when it surfaces something unexpected.

You’ll leave with

A privacy tier assignment for every record type in shared memory.
Approval boundaries (read, draft, act, never) for each active module.
A source confidence audit of existing records.
A do-not-remember protocol with at least three exclusion categories.

Use the prompt in order

1
Assign a privacy tier to every record type
For each record type, choose: full access (any can read), restricted (only named modules), or local-only (never leaves your device). Consider what would happen if each record type were exposed to every module.
2
Set approval boundaries for each module
For each active , define what it can do at each level: read, draft, act with approval, and never. Pay special attention to the 'never' list.
3
Run a source confidence audit on existing records
The assistant reviews existing records and flags fields with low confidence or stale sources. Review the flagged fields and verify, update, or delete.
4
Write your do-not-remember protocol
List three to five categories of information the system should never store. Save the protocol as a system-level rule that applies to all capture workflows.

Prompt details

Each detail will be inferred, or you will be asked to clarify in the chat.

3/3 details

3 details will be inferred, or you will be asked to clarify in the chat

Starter prompt text

Open the full text if you want to check what will be copied.

Show starter prompt

Help me build the boundary architecture for my personal assistant system.

My record types: Infer from what you know about me or ask if it is unclear
My active modules: Infer from what you know about me or ask if it is unclear

1. For each record type, recommend a privacy tier (full access, restricted,
   local-only) and explain why. I will approve or override each recommendation.

2. For each module, define approval boundaries at four levels:
   - Read and summarize (safe to do independently)
   - Draft and suggest (propose actions for my review)
   - Act with approval (execute after I confirm)
   - Never (actions the module must never take)

3. Audit my existing records for source confidence. Flag any field that is
   inferred, unverified, or older than 90 days without update.

4. Here are the categories I never want stored:
   Infer from what you know about me or ask if it is unclear
   Save these as a do-not-remember protocol that applies to all capture
   workflows.

What the answer should give you

A privacy tier map (contacts: full access, financial records: restricted to finance and review, journal: local-only). Approval boundaries for seven modules (all at draft-and-suggest level, with 'never send email' and 'never delete records' in the never column). Source confidence audit flagging 4 low-confidence fields across 12 contact records. Do-not-remember protocol with five exclusion categories saved.