Voice cross-cuts every layer, but the durable preference lives here and the operational policy lives in voice.html.
Layer 1
Identity: Who the user is
Who is this person, and what durable preferences shape the response?
| Canonical path | identity/ |
|---|---|
| Trigger | Stable identity, communication preferences, boundaries, durable voice rules. |
| Stores | Durable user profile facts that should survive across projects and sessions. |
| Avoid | Dated events, current tasks, implementation steps, and source documents. |
| Lifecycle | Mutate carefully when the profile changes; keep corrections explicit. |
What belongs here
Identity captures durable facts about the user and the standing constraints that should shape responses across sessions. It answers the person question before any project-specific context is loaded.
| Good entries | Preferred name, role, long-lived collaboration preferences, accessibility needs, communication boundaries, durable voice rules. |
|---|---|
| Poor entries | Today's meeting, a temporary blocker, a one-off preference from a single task, raw biographical source dumps. |
| Primary risk | Turning dated observations into permanent identity without evidence or consent. |
When identity changes, mutate the current profile and record the evidence that justified the change if the correction could matter later.
If the future question is "who is Dave?" or "how should I speak to Dave?", the note starts in identity.
Good identity note
---
type: identity
last_verified: 2026-05-05
confidence: high
---
Dave prefers direct engineering prose with concrete trade-offs,
minimal cheerleading, and explicit assumptions.Poor identity note
Dave was frustrated after Tuesday's deploy failed.That belongs in episodic first. It might later inform identity only if repeated evidence supports a durable preference or boundary.