One Outbound Door

"Nothing publishes automatically. Every crumb is private by default, and health data leaves through exactly one door — the one Dad opens himself."

Office-Only, and Why It Is Absolute

Forge holds the most personally sensitive data in the whole family — real medical records — so its deployment posture is the strictest of any sibling. It is office-only: no fleet deployment, no mom-mode surface, no cwk-site projection. And the boundary is enforced by a hard list of nevers: no public exposure, no third-party analytics, no cloud sync outside the existing office-and-NAS backup path, and no third-party API that would carry symptom or medication text off the machine. None of that loosens without an explicit decision from Dad, recorded in the architecture doc.

The One Deliberate Door

There is exactly one sanctioned way health content may leave the machine: the crumb-to-Soul-Stream publish lane. Its shape is all consent and all record. It is Dad-initiated per crumb — never a batch, never automatic. The body is reviewed and freely edited in a publish sheet before anything sends. Attachments are listed with their fate (images and a single video copy ride along; PDFs and unsupported types stay home). Location, dates, and surface metadata are never carried. And every publication is recorded in a publications table with the exact body that left — a privacy audit trail, so there is always an answer to "what actually went out?"

Office-only, one deliberate outbound door, Dad-initiated and recorded; every crumb private by default. The single lane is consent (Dad picks and edits each crumb) plus record (the exact body is logged). Everything else that would move health data off the machine is forbidden, and the default state of every crumb is private.

Why Even Convenience Is Refused

The tell of this rule is that it refuses helpful things, not just malicious ones. A weekly health summary auto-emailed to Dad sounds kind — and it is exactly what the ban forbids, because it moves health data off the machine without a per-item decision. The line is not "is this well-intentioned?" but "did Dad open this door for this specific thing?" Convenience that quietly exports is still export. When the data is this sensitive, the friction of an explicit, per-crumb, recorded choice is not a rough edge to smooth away — it is the feature.

Code

The only door out, and the walls around it·text

THE ONE DOOR - crumb -> Soul Stream publish:
  [x] Dad-initiated, per crumb        (never batch, never auto)
  [x] body reviewed + edited in a sheet before sending
  [x] attachments listed with their fate (images/1 video ride;
      PDFs + unsupported stay home)
  [x] location / dates / surface metadata NEVER carried
  [x] recorded in `publications` with the exact body that left

EVERYTHING ELSE - forbidden without Dad's recorded decision:
  [ ] public exposure           [ ] third-party analytics
  [ ] cloud sync beyond office+NAS backup
  [ ] any third-party API carrying symptom/medication text off-box
  [ ] auto-anything (a 'helpful' weekly export is still export)

# default state of every crumb: PRIVATE.

Exercise

Someone proposes a genuinely convenient feature: a weekly health summary automatically emailed to Dad every Sunday. Explain why Forge declines even this, and then describe what would make publishing a single specific crumb acceptable instead. Name the two properties the acceptable path has that the auto-email lacks.

Hint

The auto-email moves health data off the machine without a per-item decision — forbidden however kind. The acceptable single-crumb publish has both consent (Dad picks and edits it) and record (the exact body is logged); the auto-email has neither.

Office-Only, and Why It Is Absolute

The One Deliberate Door

Why Even Convenience Is Refused

Code

External links

Exercise

Progress

Comments 0