Data Access, Security, and Emergencies
Data Access, Security, and Emergencies
Sections 10 and 11 are where trust becomes concrete. Section 10 asks which systems the twin may read, which data is strictly prohibited, whether it works read-only, how it handles restricted material, and who is told and who audits. Section 11 asks what an approval request must contain, which alerts go to which channel at which severity, what counts as an emergency, which actions are preapproved in one, and who else gets notified. Owners tend to under-specify both sections and regret it inside the first month.
Readable, prohibited, read-only
Make three lists. Readable: the systems the twin may open to do its work — typically email, calendar, the client database, and shared documents. Strictly prohibited: data it must never touch even when technically reachable — banking credentials, payroll or health records, client passwords, contract negotiations still in flight. Read-only posture: the standing rule that reading exists for judgment, never for extraction. The twin may read a client file to prepare your briefing; it does not download exports, forward raw records, or paste sensitive rows into outputs.
Restricted-data behavior then has a simple form: summarize without quoting specifics, redact names and numbers when context allows, and when a task genuinely requires the restricted material itself, the task requires a human — you. Finally, build the accountability pair: who is told, and who audits. The audit log from Lesson 9 gets a second reader with standing to raise an eyebrow — a partner, an office manager, the person who signs. A log nobody reviews is a screen saver.
What an approval request must contain
Write the format now so the twin cannot send you lazy questions. A proper request states: the exact action proposed, why it is proposed, the alternatives considered, what happens if you decline, the risk in one sentence, and the deadline after which the decision expires. "Should I send this?" is an incomplete request. A complete one lets you approve in seconds and audit the decision weeks later.
Alerts, severity, and emergencies
Map severity to channel before the twin draws its own conclusions: emergencies arrive by phone call, high-priority items by text, and everything else is batched into a daily digest so the twin never manufactures urgency to seem diligent. Then write your definition of an emergency — your definition, not the machine's. Which events qualify: an outage affecting clients, a suspected data breach, a safety issue, a legal letter. Which do not: a client who is annoyed this hour, a supplier moving slowly on a Friday.
Preapproved actions are the moves the twin may take alone the moment its definition is met: gather the facts, reach you on every channel, draft the client notice ready for the moment you look, freeze what can safely be frozen. Write the other notifiees too — your partner, your lead technician, your attorney — and in which order. At 2 a.m. the twin does not read your mind; it executes the list you wrote at a calm desk. That is the entire point of Sections 10 and 11.
Key Takeaways
- Sections 10 and 11 define data boundaries, read-only posture, approval format, alert severity, and emergency behavior.
- Prohibited means never — even with technical access; extraction needs a rule, reading does not.
- An audit log with a second named reviewer turns security from a promise into a practice.
- Approval requests have a fixed content list, so you decide in seconds and audit decisions later.
- Emergency definitions and preapproved actions are written in calm daylight and executed at 2 a.m.
Data Access, Security, and Emergencies
Sections 10 and 11 are where trust becomes concrete. Section 10 asks which systems the twin may read, which data is strictly prohibited, whether it works read-only, how it handles restricted material, and who is told and who audits. Section 11 asks what an approval request must contain, which alerts go to which channel at which severity, what counts as an emergency, which actions are preapproved in one, and who else gets notified. Owners tend to under-specify both sections and regret it inside the first month.
Readable, prohibited, read-only
Make three lists. Readable: the systems the twin may open to do its work — typically email, calendar, the client database, and shared documents. Strictly prohibited: data it must never touch even when technically reachable — banking credentials, payroll or health records, client passwords, contract negotiations still in flight. Read-only posture: the standing rule that reading exists for judgment, never for extraction. The twin may read a client file to prepare your briefing; it does not download exports, forward raw records, or paste sensitive rows into outputs.
Restricted-data behavior then has a simple form: summarize without quoting specifics, redact names and numbers when context allows, and when a task genuinely requires the restricted material itself, the task requires a human — you. Finally, build the accountability pair: who is told, and who audits. The audit log from Lesson 9 gets a second reader with standing to raise an eyebrow — a partner, an office manager, the person who signs. A log nobody reviews is a screen saver.
What an approval request must contain
Write the format now so the twin cannot send you lazy questions. A proper request states: the exact action proposed, why it is proposed, the alternatives considered, what happens if you decline, the risk in one sentence, and the deadline after which the decision expires. "Should I send this?" is an incomplete request. A complete one lets you approve in seconds and audit the decision weeks later.
Alerts, severity, and emergencies
Map severity to channel before the twin draws its own conclusions: emergencies arrive by phone call, high-priority items by text, and everything else is batched into a daily digest so the twin never manufactures urgency to seem diligent. Then write your definition of an emergency — your definition, not the machine's. Which events qualify: an outage affecting clients, a suspected data breach, a safety issue, a legal letter. Which do not: a client who is annoyed this hour, a supplier moving slowly on a Friday.
Preapproved actions are the moves the twin may take alone the moment its definition is met: gather the facts, reach you on every channel, draft the client notice ready for the moment you look, freeze what can safely be frozen. Write the other notifiees too — your partner, your lead technician, your attorney — and in which order. At 2 a.m. the twin does not read your mind; it executes the list you wrote at a calm desk. That is the entire point of Sections 10 and 11.
Key Takeaways
- Sections 10 and 11 define data boundaries, read-only posture, approval format, alert severity, and emergency behavior.
- Prohibited means never — even with technical access; extraction needs a rule, reading does not.
- An audit log with a second named reviewer turns security from a promise into a practice.
- Approval requests have a fixed content list, so you decide in seconds and audit decisions later.
- Emergency definitions and preapproved actions are written in calm daylight and executed at 2 a.m.
There are no comments for now.