Your words first

Last night I re-read one of my own entries in the app and did not like what I saw. The page opened on a transcript. My words were there, but so were every one of the companion's questions, in equal weight, and the page read like a chat log rather than a journal. Today I shipped two changes to fix that, and the second one turned up a sentence in the privacy policy that was about to become untrue.

The transcript is not the entry

The app works by conversation. Luna asks a gentle question, you answer, she asks another, and by the end you have written more than you would have on a blank page. That is the point of the design. But the artifact that conversation produces is not the thing a person wants to re-read a week later. What they want is what they said. The questions were scaffolding, and scaffolding comes down once the building stands.

So the entry page now opens on a view I call Journal: only the writer's turns, rendered as one flowing piece. Each of Luna's prompts is still there, collapsed to a faint one-line caption above the answer it produced, because some answers are meaningless without their question. "Yes, mostly" needs to know what it is agreeing with. Tap the caption and the full prompt opens; leave it and the page reads as your own writing. The full transcript is one tab away for anyone who wants it, and a third tab holds the reflection.

The principle underneath is one I keep relearning: the interaction model and the artifact model are different things. A product can be conversational in the moment and still owe the user a non-conversational record. Designing the record as a by-product of the interaction, which is what I had done, gets the ownership backwards.

The reflection nobody used

The second change started from a number. The app has had an "organize my thoughts" feature for months, a button that asks the model to pull out themes, highlights and an insight from an entry. I checked how often anyone used it. Across every entry ever written by every tester, the feature had been used on a fraction of them, and every one of those uses was mine.

That is not a feature. That is a button I liked. A summary you have to ask for is a summary most people will never see, and the output was thin anyway, because I had capped it hard and told the model to infer nothing. Both of those constraints were right. The grounding rule, in particular, is one I will not relax: a reflection that invents a detail about your day is worse than no reflection. But the caps had been set for a card, not for a page.

The new version generates a fuller reflection at the moment you save, in the background, so the entry already has one the first time you open it. A short title. A hundred words or so in the second person that keep your own details and names. The highlights, the gratitude, the insight, and one line about what you said you are carrying into tomorrow. The old button stays for older entries. Older reflections still render in their older shape, because a versioned record is cheaper than a migration and honest about when each one was made.

Two decisions inside that are worth naming. First, it keeps names. The earlier summaries strip names on purpose, because they are stored readable so Luna can remember your recent days. The reflection is stored encrypted on your device before it ever reaches the database, alongside the conversation itself, so it can hold what you actually wrote. Where a piece of text lives decides what it may contain. Second, when the model fails three times, the service returns a placeholder, and I found that the app had been quietly saving that placeholder as if it were a real reflection. Now nothing saves unless it is the real thing. A failure that looks like success is the most expensive kind.

The word "ask"

Here is the part I nearly missed. Before changing when the reflection runs, I read the privacy policy again, and one bullet said the organized thoughts are generated "when you ask." After today they are also generated when you save. Same data, same recipient, same purpose. Nothing new leaves the device that was not already leaving it for the summaries. But the sentence would have been false, and a false sentence in a privacy policy does not get graded on intent.

I treated it the way I treated a similar catch last week: a timing change to a feature already disclosed, published with the release as a clarification, with a note for the attorney who will eventually read all of this explaining why I did not hold it for a notice period. Reasonable people can disagree with that reading, and I wrote that down too.

The mental model I take from it is that a policy is a set of premises about the system, and every feature change is a chance for one of them to stop being true. The change that breaks a premise is rarely the big architectural one. It is the small one, the one that moves a feature from "on request" to "automatic" and feels too minor to check.

Should it be encrypted?

The last change came from a question my own testing raised. The home screen shows a card for your most recent entry, and it did not pick up the new title, because that card had been built on a rule from an earlier deploy: read only the plain summary, never decrypt anything on the home screen. When I proposed showing the title there, the question that came back was the right one. Should that title be encrypted?

It already is. The title is part of the reflection, and the reflection lives in the encrypted column. Showing it on the home screen means decrypting it on the device to display it, which is exactly what the history page already does. Nothing is written anywhere readable. The earlier "never decrypt on the home screen" rule had been a scope choice, a way to keep one screen simple, and somewhere along the way it had started to sound like a security boundary. It was worth ten minutes to say out loud which one it was before changing it.

That card also got a label and an arrow, because it had looked identical to two cards on the same screen that do nothing when tapped. And tapping it now opens the entry itself rather than the list, closing a small navigation gap that had sat on the backlog for months waiting for a product decision that took one sentence to make.

Mental Models

The artifact is not the interaction. A conversational product still owes the user a record shaped like a record. Design the record deliberately; do not let it be whatever the interaction happens to leave behind.

A feature you must ask for is a feature most people will never see. Check the usage number before polishing the output. Sometimes the fix is not a better result but a different trigger.

Where text lives decides what it may contain. The readable summary strips names; the encrypted reflection keeps them. Same model, same input, different rules, because the storage tier sets the privacy rule, not the prompt.

Every feature change is a premise check on the policy. Read the disclosure before changing when something runs, not just what it does. The small timing changes are the ones that turn a true sentence false.

Say whether a rule is scope or a boundary before you move it. Some constraints exist to keep a screen simple; some exist to keep a promise. They look the same in the code and are not the same to change.