Specific is not the same as right

Today the companion learned to ask one question at the end of the night: what is one small thing you mean to do tomorrow? On paper that is a tiny feature. In practice it forced three decisions I did not expect, and all three came down to the same lesson. Being specific felt like being careful, and twice it was the opposite.

Whose words is it

The app already produced a line at the end of every reflection about what the writer seemed to be carrying into tomorrow. The model wrote it. It was a reading, sometimes a good one, of what was left unresolved. When I added a real intention, I had to decide whether the two were the same thing wearing different labels.

They are not, and the difference is authorship. The carrying line is the model's inference. The intention is something the writer said, in their words, as a commitment. That distinction decides what the app may do the next evening. Playing back a commitment is safe: "last night you said you would text your sister, how did that go?" Playing back an inference as if it were a promise puts words in the writer's mouth, and the research on follow-through is clear that the effect comes from the person's own commitment language, not from a paraphrase. So both lines stay, and only the writer's line is ever spoken back.

That led to a better version of the feature than the one I had drafted. Instead of a generic "want to set an intention?", the companion first looks for something the writer already said they mean to do earlier in the conversation and offers it back: is that your intention for tomorrow, or would you rather set a different one? One tap confirms it. Fewer round trips than the generic ask, and it feels like being heard rather than being prompted.

The guardrail matters more than the feature. The candidate may only come from the writer's own stated wants. Never from the model's read of what they need, never from a feeling they described, never from anything that sounds like advice. Language models drift toward directive suggestions, and a bedtime app that starts assigning homework has stopped being a journal. When in doubt, the open question.

The gate that was a turn count in disguise

The first night on the new build, the companion moved to gratitude after three exchanges. I had written the transition rule as a condition on the conversation rather than a count, on purpose, because counting turns is exactly the kind of mechanical pacing the research warns against. The condition said: stay in listening until the writer has named something that mattered, you have reflected it, and they have accepted or added to it.

Any coherent three-turn exchange satisfies that. My carefully non-mechanical rule was a turn count of three, written in prose.

The fix has two parts, and neither is a longer rule. First, the transition became a question with its own turn: is there anything else from today you would like to sit with, or would you like to look at what was good? Two chips, one tap. That is the interviewing discipline of asking permission before changing direction, and it means a "no" has somewhere to go. Second, a floor under that question that the server enforces rather than the prompt: the check cannot appear before six typed messages. The function counts and tells the model; the model does not count. A short night has a button for wrapping up early, so the floor never traps anyone.

The principle I keep relearning: prompt compliance decides the wording, structure decides the timing. If a behaviour has to hold, put it in code the model cannot argue with.

The sentence that went stale

The intention is stored inside the encrypted reflection, and the next evening the app decrypts that one line on the device and sends it with the greeting so the companion can ask about it. Before building anything I read the privacy policy to see whether it covered that flow. It did not. The policy described the prompt as carrying "the readable summaries of your last ten entries." Precise, true on the day it was written, and now incomplete.

My first instinct was to add a sentence about the new flow. Then a trimmed sentence. Then a mechanism-level sentence that would survive the next feature. Each was accurate. Each was also more than anyone had asked for, so I stopped and looked up what a privacy policy is actually required to say.

For a US web app of this size the floor is clear. California's website privacy law applies to any commercial site with California users, no threshold, and it asks for categories: what kinds of information are collected and what kinds of third parties receive them. The state's consumer privacy regulations, if the app ever grows into them, ask for the same at the category level plus purposes described so a reader understands why. Federal law asks that the policy be accurate, and for sensitive data like a journal, that the recipient be named plainly and consent obtained before collection. The enforcement cases on mental-health apps were about policies that implied less sharing than happened. None of it asks for a data-flow diagram.

I read the policies of the closest comparable apps the same evening. All of them sit at the category level. One uses a word for model-provider data that its own practice does not earn under the statutory definition, which is the mistake I have been most careful to avoid. None of them itemise features.

So the section that walked through the request step by step became one plain paragraph: what you write, the companion's replies, and context drawn from your saved entries are sent through our server to the model provider, which generates the replies, the summaries and the reflection; the server checks that you are signed in, applies the daily limit, screens for crisis phrases, and keeps nothing. The detail moved into the internal attorney note, along with a definition of the two kinds of context the prompt can carry, so that the next feature in the same class needs no policy edit and a feature outside it is obviously a change.

The specific sentence was a trust device I had chosen, not a legal one, and it was the sentence that went stale. The category-level sentence is true now and will still be true in three features.

Mental Models

Authorship decides use. A line the model inferred and a line the user wrote can look identical and must be handled differently. Only the user's own commitment gets spoken back to them.

A condition any short exchange satisfies is a count in disguise. Test a pacing rule against the minimal conversation that passes it. If three turns pass, you wrote "three."

Prompt compliance decides wording; structure decides timing. Anything that must hold goes in code the model cannot negotiate with, and the model is told the result.

Write disclosures at the legal floor and keep the mechanism in the notes. Categories of data and recipients stay true across features. A step-by-step sentence is precise on the day it is written and stale by the next release.

Read what the law asks before deciding how much to say. Three accurate drafts were all above the floor. The fourth was shorter, more durable, and the only one grounded in a requirement rather than an instinct.