Home / Council and Characters / Characters and Visual Identity

Oracle Chat: Discovery + Profile Learning + History - Design Proposal (v1)

Updated Jul 10, 2026 · Affirmology_OracleDiscovery_Profile_History_Proposal_v1.md

Oracle Chat: Discovery + Profile Learning + History - Design Proposal (v1)

Written 2026-07-10 by the DATA/engine chat, from Jeff's direction. This is a decision doc to react to, not something built yet. Jeff: "the oracle chatbot needs a dimension of discovery, active questioning to learn more about the user; store and update a profile of these conversations; the user will want to access the history; cost-effectiveness is a concern, something to talk about and consider ways to do it."

Why this matters: the Guide chat is the star of the Founding Preview and the data flywheel. Every conversation should make the person feel known AND make their future audios better. Today it is largely passive Q&A. This proposal turns it into active discovery that feeds a durable, growing profile.

What ALREADY exists (don't rebuild)

• THE UNDERSTANDING is the per-person profile and already has a context_store and a learned-info store, and the design is APPEND on new learnings, never recompute (12-field schema in Affirmology_FlagshipReading_Proposal_v1.md). This is the natural home for conversation learnings.
• Write path exists: POST /api/profile-understanding {person, understanding} (and the newer /api/build-understanding). Learnings can be appended to the stored profile per person.
• The chat is council-grounded (Sophia + oracles, chart-aware). It can already reason about the person.
• The flywheel is already the stated intent (FoundingPreview spec: "every conversation feeds the Context & Learning that makes their Monday audios better").

So the gap is three concrete additions: (A) active discovery behavior, (B) write conversation learnings back to the profile, (C) durable, user-viewable history, all done cost-consciously.

A. DISCOVERY DIMENSION (active questioning)

Give the oracle a discovery agenda: a short, prioritized list of high-value unknowns that make the audios better, e.g. current season of life, what they most want to change, a live struggle, a relationship or role that matters, what "success" feels like to them, what they resist.

Behavior rules (system-prompt level, no new infra): - Lead with value, then get curious. Answer their question / reflect them first; then weave in ONE gentle, specific question when it is natural. Never an interrogation, never a form. - One open loop at a time. Ask, listen, integrate, then maybe ask the next. It should feel like a wise friend who is genuinely interested, not a survey. - Prioritize by audio-impact. Ask what would most change the next affirmation, not trivia. - Never re-ask what the profile already knows. Inject the person's current learned-info so the oracle builds on it instead of repeating.

Cost: this is a PROMPT change to the existing chat call. Near-zero added cost.

B. STORE + UPDATE A PROFILE FROM CONVERSATIONS

Every conversation should deposit durable learnings onto the person's Understanding.

Mechanism (recommended): a cheap distillation pass, not real-time heavy writes. - After each session (or every N messages, e.g. 6), run ONE small model call (Haiku, or cheap Sonnet) that reads the recent turns + the current learned-info and outputs "new, durable facts learned about this person" as a short structured delta. - Append that delta to profile.understanding.learned_info / context_store via the existing write path. Append only, never touch the chart or overwrite prior learnings. - The NEXT audio/reading generation already reads profile.understanding, so the flywheel closes for free.

Why a distillation pass and not "save every message as context": see cost, below. We store the raw transcript for the USER, but the MODEL consumes a compact distilled profile, not the whole history.

C. CONVERSATION HISTORY (user-accessible)

• Persist the transcript server-side, keyed by person (email / person_id): every user + oracle message, timestamped, with which oracle spoke. Store in the app DB (or R2 for cold storage). Text is tiny.
• App UI: a simple history/scrollback view in the Guide tab so the person can revisit past conversations. Survives reinstalls because it lives server-side, not just on device.
• This is mostly a storage + retrieval feature (cheap), plus a read-only screen. Low risk.

COST - the real question, and how to keep it cheap

The storage is trivial. The cost lever is how much context each LLM call carries, and the trap is feeding the entire growing transcript into every message (cost grows quadratically with conversation length). Keep it flat with four moves:

1. Model sees the DISTILLED profile, not raw history. Each chat call gets: the person's chart summary + their compact learned-info + the last few messages. Not the full transcript. Flat context = flat cost.
2. Rolling summarization. Old turns get folded into learned-info (the distillation pass) and dropped from the live context. The conversation can be infinite; the context stays small.
3. Tiered models. Use a cheap model (Haiku) for casual discovery chat + the distillation passes; escalate to the council / Sonnet ONLY for real chart/reading questions. (Ties to the standing principle: the council is our expensive weapon; do not fire it on every message.)
4. Store transcripts cheaply for the human, not for the model. History is for the USER to read back; it is never bulk-fed to the LLM.

Rough envelope (needs a real measurement pass): with compact context, a chat message is a few thousand tokens in / a few hundred out = well under a cent to low cents each; a per-session distillation ~1-2 cents. A chatty user might be ~$0.10-0.30/month of model IF we never feed raw history per turn. The naive "whole transcript every message" approach could be 10-50x that and grow without bound. So the architecture choice, not the feature, is what controls cost.

OPEN DECISIONS FOR JEFF

1. Discovery intensity: how forward should the oracle be, one light question per few exchanges, or more actively steering? (Recommend: light and value-first for the Founding Preview, tune from real logs.)
2. Distillation trigger: per-session vs every-N-messages vs on app background. (Recommend: per-session + a cap.)
3. History depth in the app: last session only, or full searchable archive? (Recommend: full server-side store now, simple scrollback UI first, search later.)
4. Model tiering: confirm Haiku for casual + distillation, council only for chart/reading. (Recommend yes.)
5. Privacy/consent framing: the app should say plainly that the guide remembers to personalize; the beta agreement already covers data use, but the app copy should be warm about "your guide gets to know you."

SUGGESTED SEQUENCE (after the Founding Preview ships)

1. Prompt-level discovery behavior (cheapest, biggest feel change) + inject existing learned-info. Ship first.
2. Server-side transcript persistence + a history screen.
3. The per-session distillation pass writing back to profile.understanding.
4. Model tiering + a cost measurement pass on real conversations, then tune.

None of this blocks tonight's Founding Preview build; it is the next layer once the app is in hands.

JEFF'S DECISIONS - BUILD APPROVED (2026-07-10, via Cowork)

Greenlight: build the full Oracle Discovery + Profile Learning + History system. "Our chatbot is our one main feature, make it solid and make it gather us info. Roll out as much of this as we can."

1. DISCOVERY INTENSITY: default LIGHT + value-first (one gentle question per few exchanges). PLUS build it as a DIAL, an adjustable intensity parameter that can sometimes trigger into MORE active questioning to help the user get clarity. Make the dial A/B-testable so we find the optimal setting from real logs (internal tuning lever now; could become a user-facing setting later).
2. DISTILLATION TRIGGER: PER SESSION (+ a cap), as recommended.
3. HISTORY DEPTH: go with the recommendation, full server-side transcript store now, simple scrollback UI first, search later.
4. MODEL TIERING: YES, Haiku for casual discovery chat + the distillation passes; escalate to council / Sonnet ONLY for real chart/reading questions (protects cost; council is the expensive weapon).
5. PRIVACY/CONSENT: YES, app copy warmly states the guide remembers in order to personalize ("your guide gets to know you"); the beta agreement already covers data use.

SEQUENCING (Jeff wants as much as possible now): ship the prompt-level discovery behavior + inject the existing learned-info WITH or right after the Founding Preview (cheapest, biggest feel change, near-zero cost). Then transcript persistence + history screen, then the per-session distillation write-back, then model tiering + a real cost-measurement pass to tune the dial.