Why AI output is always marked
In a memory archive, an unlabeled machine sentence is a small forgery. Provenance is enforced in the type system, not the style guide.
A family archive is a record of who actually said what. That is its whole value: the recipe in her words, the story the way he told it. The moment machine-written text can appear beside human memory without a label, every entry becomes slightly suspect — did Grandpa write that letter, or did a model summarize him? In most products a mislabeled AI sentence is an embarrassment. In this one it is a small forgery inserted into a family's record of a person.
So DearestEllie's rule is absolute: everything the AI writes is marked as the AI's, everywhere, forever. And because rules enforced by style guides erode, this one is enforced where erosion is hardest — in the type system.
The mechanism
Every AI feature in the product is backed by one provider abstraction, and its only output type is a proposal object that carries three things: the label it must be displayed with ("Family Archivist"), the backend that produced it (provenance, e.g. which CLI and model), and a field literally typed requiresReview: true. Not a boolean that defaults to true — the literal type true. Code that tries to construct an unreviewed AI result does not fail a code review; it fails to compile. There is exactly one sanctioned constructor for a proposal, and it stamps the marking on.
Review-gating is the second half of marking. Nothing the Archivist writes is auto-applied: a suggested chapter, a drafted introduction, a transcription cleanup — each lands as a marked proposal a person accepts, edits, or discards. The steward decides; the model proposes. Even in "gentle" mode, where the Archivist may draw themes across memories, the default mode is stricter still: only restate what a memory explicitly says.
The AI is also optional and off by default. A fresh install of this software has no AI configured and is fully usable; enabling the Archivist is a deliberate choice, gated by consent, per archive. And it runs on a local CLI under the operator's own subscription rather than a billed per-call API — partly economics, but mostly incentives: nothing in this architecture gets cheaper or more profitable by generating more text into people's archives.
Why not quietly helpful?
The counterargument is familiar from every writing product: labels add friction, people just want the help, the text is theirs once they accept it. We think memory archives are the domain where that logic fails. A future grandchild reading the archive is not a user experiencing friction; she is a reader trying to meet someone. She deserves to know which sentences are her grandmother's and which are a machine's paraphrase, and she will have no way to ask. The marking is not for the person who clicked the button — it is for the reader fifty years out.
There is also a quieter reason. Grief makes people suggestible; a fluent machine draft of "what Dad was like" can overwrite a hesitant true memory. Keeping the label visible keeps the human author in the loop as an author, not an approver. The Archivist's best work is asking good questions and offering scaffolding a person fills with their own words — and the marking keeps everyone honest about which is which.
If you are building in this space: put provenance in your types, not your guidelines. It is the difference between a promise and a property.