Skip to content

Latest commit

 

History

History
567 lines (444 loc) · 48.6 KB

File metadata and controls

567 lines (444 loc) · 48.6 KB

Trace — Technical Specification (Skeleton v0.25)

"Notes capture what happened. Photos capture how it looked. Trace captures who you were becoming — a living biography you didn't know you were writing."


1. Project Vision & Core Claim

What This Is

Trace — a system that accumulates your story across time and reflects it back to you as narrative, not insights. It closes the loop between what you intended and what you actually did. That gap — intention vs. reality across time — is the richest territory for genuine self-knowledge. No existing reflection tool has seriously attempted this: accumulating a longitudinal model of a person's becoming, across months and years of their own words — whether those words come from AI conversations, journals, notes, or whatever form thinking has taken. Today that corpus might be weeks or months deep. As AI conversation becomes a natural part of how people think out loud, it will be years. Trace is built for that continuity.

The Human Need It Serves

Being accurately known — what Carl Rogers called "unconditional positive regard" — is itself therapeutic, independent of any advice or intervention. When a person encounters their own story reflected back with genuine fidelity, the recognition itself carries the value. Self-awareness isn't added on top. It emerges from being genuinely witnessed.


2. Design Philosophy

"Trace is not a journaling tool or a self-improvement app. It's closer to what a great biographer does — except the subject is still alive, still speaking, and reading it in real time. Every engineering decision in this spec is downstream of that premise."

The Experience: What the User Perceives

The Narrative Voice

The synthesis speaks in one register: warm biographer. Someone who read everything you said, cares about getting it right, and respects you enough to include the hard parts.

  • Not: Third-person clinical ("The subject exhibited patterns of...")
  • Not: First-person ventriloquism ("I felt really conflicted about...")
  • Not: Coaching ("You've shown great growth in...")
  • Tense: Past tense for events, present tense for ongoing tensions. "You took the meeting. Whether it was reconnaissance or the beginning of something is still unclear, even to you."
  • Register: Slightly formal but not distant. Like a letter from someone who knows you well but isn't casual about it.

The Anti-Flattery Principle

LLMs are trained to be agreeable and coherent. Left unconstrained, a synthesis of chat history will produce a narrative that makes you sound more purposeful, more consistent, and more admirable than you actually were. That's not witnessing — that's a mirror that only shows your good side.

The synthesizer prompt must include explicit resist this:

  • Do not smooth contradictions into coherence
  • Do not frame setbacks as "learning experiences" unless the user did
  • Do not upgrade the user's emotional language (if they said "annoyed," don't write "deeply frustrated")
  • Include at least one moment where the narrative resists the obvious positive interpretation

The Honest Incompleteness Principle

Every dispatch carries an implicit or explicit acknowledgment: this is a portrait of you in seeking — the you that arrives when something is unresolved. What you never brought here is also part of who you are. The gaps in the chat history are data too. The portrait is systematically biased toward struggle, ambition, and problem-solving. It almost entirely excludes contentment, embodied experience, relationships from the inside, joy. That's not a flaw to fix. It's a truth to name.


The Architecture: How It Holds

The three experience principles above are not soft constraints — they are the load-bearing requirements the architecture must serve. Each build principle maps directly to one.

Contract-first, componentized architecture

This serves the Anti-Flattery Principle. Every component has explicitly defined inputs, outputs, and boundaries before implementation begins. Interfaces are locked before behavior is built. This is how you prevent the model from quietly drifting toward pleasing: you specify what honest output looks like before the component has a chance to optimize for coherence.

Eval-driven at every layer

This serves the Honest Incompleteness Principle. Every component has its own evaluation criteria before integration. Every layer has its own eval independent of the components within it. The end-to-end pipeline has its own eval independent of the layers. Nothing graduates without a measurable quality bar — because "it reads well" is not the same as "it's true."

E2E before perfection, then iterate in parallel

serves the Living Biography framing. Get the full pipeline running end-to-end first, even crudely. The whole shape matters before any part is polished — because a beautifully crafted dispatch that fails to surface the right period of someone's life is worse than a rough one that gets the moment right. Once the skeleton holds, components improve independently — this is where work naturally distributes, whether to human developers or coding agents.


3. System Architecture — Four Layers, Thirteen Components

The system is organized into four layers. Each layer has a clear responsibility, a defined contract with adjacent layers, and its own evaluation criteria. Within each layer, components are numbered for reference (1.1, 1.2, etc.) and can be built, tested, and improved independently.

Layer Summary

Layer Responsibility Components Input Contract Output Contract
Layer 1: Ingestion Capture raw material from the user's life 1.1 Chat Bootstrap, 1.2 Voice Capture, 1.3 Forward Capture Raw files (JSON, audio, text) from various sources Normalized records: {timestamp, role, content, source}
Layer 2: Processing Transform raw material into structured, queryable memory 2.1 Extraction & Tagging, 2.2 Four-Tier Memory Store, 2.3 Contradiction Detector, 2.4 Intention-Reality Tracker Normalized records from Layer 1 Structured memory + detected tensions + intention-outcome pairs
Layer 3: Synthesis Generate the dispatch content — narrative, visual, question 3.1 Narrative Synthesizer, 3.2 Tension Mapper (Visual), 3.3 Question Generator Structured memory + tensions + intention gaps from Layer 2 Narrative prose + tension visual + one question
Layer 4: Output Compose, deliver, and collect response 4.1 Dispatch Composer, 4.2 Delivery Channel, 4.3 Annotation Interface Synthesis artifacts from Layer 3 Complete dispatch delivered to user + optional feedback loop

Layer-Level Evaluation

Layer Eval Question Key Metric Method
Layer 1: Ingestion "Did we capture the material faithfully and completely?" Coverage × Fidelity: % of source material ingested without loss or distortion Automated parse tests + manual spot-checks against source
Layer 2: Processing "Does the structured memory accurately represent who this person is and what they've been navigating?" Retrieval relevance + tier accuracy + tension precision Human-labeled samples, retrieval benchmark, resonance checks
Layer 3: Synthesis "Does the output feel true — not flattering, not clinical, not false?" Anti-flattery pass rate × emotional resonance × factual grounding Multi-dimensional rubric scored by self + trusted readers
Layer 4: Output "Does the complete experience make the user feel witnessed?" The ultimate metric: "Do I feel genuinely witnessed?" 90-day self-use. You will know in your body.

📎 Detailed eval spec: Layer-level and E2E evaluation frameworks, including grader design, scoring rubrics, and inter-rater reliability protocols, will be specified in a separate document: trace-eval-spec.md (TBD).

Architecture Diagram

┌─────────────────────────────────────────────────────────────────────┐
│  LAYER 1: INGESTION                                                 │
│  Capture raw material from the user's life                          │
│                                                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────────┐        │
│  │ 1.1 Chat     │  │ 1.2 Voice    │  │ 1.3 Forward        │        │
│  │ History      │  │ Capture      │  │ Capture            │        │
│  │ Bootstrap    │  │ (Whisper)    │  │ (ongoing input)    │        │
│  └──────┬───────┘  └──────┬───────┘  └────────┬───────────┘        │
│         └─────────────────┼────────────────────┘                    │
│                           ▼                                         │
│              Normalized records: {timestamp, role, content, source}  │
└───────────────────────────┬─────────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────────────────┐
│  LAYER 2: PROCESSING                                                │
│  Transform raw material into structured, queryable memory           │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 2.1 Extraction & Tagging                                    │   │
│  │ Raw input → structured events with tier/emotion/intent tags │   │
│  └──────────────────────────┬───────────────────────────────────┘   │
│                              ▼                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 2.2 Four-Tier Memory Store                                  │   │
│  │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐    │   │
│  │ │ Semantic │ │ Episodic │ │Procedural│ │ Prospective  │    │   │
│  │ │ (who you │ │ (what    │ │ (your    │ │ (what you    │    │   │
│  │ │  are)    │ │ happened)│ │ patterns)│ │  said you'd  │    │   │
│  │ │          │ │          │ │          │ │  do)         │    │   │
│  │ └──────────┘ └──────────┘ └──────────┘ └──────────────┘    │   │
│  └──────────────────────────┬───────────────────────────────────┘   │
│                              ▼                                      │
│  ┌─────────────────────────────┐ ┌─────────────────────────────┐   │
│  │ 2.3 Contradiction Detector  │ │ 2.4 Intention-Reality       │   │
│  │ Surfaces tensions between   │ │ Tracker                     │   │
│  │ stated values & behavior    │ │ Closes the prospective loop │   │
│  │ WITHOUT commentary          │ │ The Earned Difficulty Ledger│   │
│  └─────────────┬───────────────┘ └─────────────┬───────────────┘   │
│                └───────────────┬────────────────┘                   │
│                                ▼                                    │
│         Structured memory + tension pairs + intention-outcome pairs │
└────────────────────────────────┬────────────────────────────────────┘
                                 │
┌────────────────────────────────▼────────────────────────────────────┐
│  LAYER 3: SYNTHESIS                                                 │
│  Generate the dispatch content                                      │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 3.1 Narrative Synthesizer                                   │   │
│  │ Produces the weekly dispatch as story, not insights          │   │
│  │ Writes you as a character with arc                           │   │
│  └──────────────────────────┬───────────────────────────────────┘   │
│                              ▼                                      │
│  ┌─────────────────────────────┐ ┌─────────────────────────────┐   │
│  │ 3.2 Tension Mapper (Visual) │ │ 3.3 Question Generator      │   │
│  │ Visual sketch of where      │ │ Exactly ONE question         │   │
│  │ you're pulled this week     │ │ Genuinely curious, not       │   │
│  │ NOT a dashboard             │ │ coaching                     │   │
│  └─────────────┬───────────────┘ └─────────────┬───────────────┘   │
│                └───────────────┬────────────────┘                   │
│                                ▼                                    │
│                Narrative + visual + one question                     │
└────────────────────────────────┬────────────────────────────────────┘
                                 │
┌────────────────────────────────▼────────────────────────────────────┐
│  LAYER 4: OUTPUT                                                    │
│  Compose, deliver, and collect response                             │
│                                                                     │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 4.1 Dispatch Composer                                       │   │
│  │ Assembles hybrid output: narrative → transition → materials  │   │
│  └──────────────────────────┬───────────────────────────────────┘   │
│                              ▼                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 4.2 Delivery Channel                                        │   │
│  │ Gets the dispatch to the user (see Section 4 for options)   │   │
│  └──────────────────────────┬───────────────────────────────────┘   │
│                              ▼                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ 4.3 Annotation Interface (post-MVP)                         │   │
│  │ User responds to gaps, corrects portrait, answers question  │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

4. Component Specifications

Layer 1: Ingestion

Layer responsibility: Capture raw material from the user's life — chat history, voice, ongoing input — and normalize it into a common format that downstream layers can process. The ingestion layer is deliberately simple: it shouldn't interpret, classify, or judge. It just captures faithfully.

1.1 Chat History Bootstrap

Purpose: Ingest existing chat history (Claude, ChatGPT, etc.) as the initial corpus. Chat history is more revealing than a journal — in a journal you're performing self-reflection; in a chat you reveal yourself sideways.

Attribute Detail
Input Exported chat history files (JSON, MD, HTML depending on platform)
Output Normalized conversation records: {timestamp, role, content, source_platform}
Naive v0 Manual export → simple parser per platform → flat JSON store
Eval metric Coverage (% of conversations successfully parsed), fidelity (no content loss)
Known bias Chat history over-represents struggle, ambition, problem-solving. Almost entirely excludes contentment, embodied experience, joy. Name this explicitly.

1.2 Voice Capture

Purpose: Zero-friction input. 90 seconds, no structure, speak on a run or after a meeting.

Attribute Detail
Input Audio file (recorded via mobile app or voice memo)
Output Transcribed text with timestamp and optional mood/energy tag
Naive v0 Whisper API (or local whisper.cpp) → plain text file appended to corpus
Eval metric WER (word error rate), latency from recording to available-in-store
Design constraint No prompts, no structure. The user speaks freely.

1.3 Forward Capture

Purpose: Ongoing input beyond bootstrap. Could be continued chat exports, daily voice notes, or explicit "check-in" entries.

Attribute Detail
Input Any new material the user brings — voice, text, exported conversations
Output Same normalized format as 1.1/1.2, appended to corpus
Naive v0 Manual process: user drops files or speaks; system ingests
Key insight A witness that only looks backward isn't longitudinal — it's archaeological. The ongoing value comes from continuing to feed it.

Layer 2: Processing

Layer responsibility: Transform raw material into structured, queryable memory. This is where Trace's core IP lives — the four-tier memory taxonomy, the contradiction detection, and the intention-reality tracking. The processing layer takes "what someone said" and produces "what it means in the context of who they've been becoming."

2.1 Extraction & Tagging

Purpose: Transform raw text into structured events with semantic tags. This is where raw conversation becomes material the downstream components can reason over.

Attribute Detail
Input Normalized conversation records from Layer 1
Output Tagged events: {content_summary, memory_tier, emotional_valence, stated_intent (if any), topic_cluster, timestamp}
Naive v0 Single LLM call per conversation chunk with structured output prompt. Tag each chunk with its primary memory tier (semantic/episodic/procedural/prospective) and extract any stated intentions.
Eval metric Tier classification accuracy (human-labeled sample), intent extraction recall, inter-annotator agreement on emotional valence
Critical subtlety The prospective memory extraction is the hardest and most valuable part. "I want to respond from curiosity not fear in the Anthropic process" must be captured as a commitment that the system will later close the loop on. Distinguish between aspirational statements and concrete intentions.

2.2 Four-Tier Memory Store

Purpose: Persistent, structured memory organized around the four-tier taxonomy. This is the core IP.

Attribute Detail
Input Tagged events from 2.1
Output Queryable memory store, retrievable by tier, time range, topic, emotional valence
Naive v0 Simple vector store (Chroma, or even flat JSON with embeddings) partitioned by tier. Each entry tagged with tier + metadata.
Eval metric Retrieval relevance (given a synthesis query, does it surface the right memories?), staleness detection (are outdated beliefs still presented as current?), tier assignment accuracy

Tier definitions:

  • Semantic — who you are: values, commitments, stated identity, beliefs. Slow-changing. Updated when evidence of shift accumulates.
  • Episodic — what happened: specific moments, interactions, emotional events. Timestamped. Rich in context.
  • Procedural — your patterns: how you characteristically respond to difficulty, success, conflict, uncertainty. Inferred across episodes.
  • Prospective — what you said you'd do. The intention ledger. Explicitly tracked and closed out against what actually happened. This tier doesn't exist anywhere else.

📎 Detailed storage spec: Storage architecture decisions — vector DB vs. hybrid retrieval, embedding model selection, partitioning strategy, staleness model, and privacy/encryption — will be specified in a separate document: trace-storage-spec.md (TBD).

2.3 Contradiction Detector

Purpose: Find the tensions. The witnessing IS the surfacing of contradiction. "Three months ago you said you needed deep IC work to feel alive. Two weeks ago you described feeling most energized managing the team's architecture decisions. These aren't reconciled."

Attribute Detail
Input Memory store (esp. semantic + episodic tiers across time)
Output Tension pairs: {claim_A, claim_B, time_gap, topic_cluster, severity}
Naive v0 Periodic LLM sweep: "Given these semantic memories and these recent episodes, identify any contradictions or unresolved tensions." Structured output.
Eval metric Precision (are surfaced contradictions genuine?), recall (are real contradictions missed?), human resonance rating ("does this feel true?")
Critical design constraint Surfaces WITHOUT commentary. Not "you should notice this." Just "here's what I see." The difference between witnessing and flattery. Never resolves the tension — that's the user's job.

2.4 Intention-Reality Tracker (The Earned Difficulty Ledger)

Purpose: Close the prospective memory loop. You said X three weeks ago. Here's what happened. This is accountability to your own becoming.

Attribute Detail
Input Prospective memory entries (stated intentions) + subsequent episodic entries
Output Intention-outcome pairs: {original_intent, stated_when, outcome_observed, outcome_when, gap_characterization}
Naive v0 For each open prospective memory, periodically search recent episodes for evidence of follow-through, abandonment, or transformation. LLM-based matching.
Eval metric Match accuracy (did the system correctly identify that intent X was addressed by episode Y?), false closure rate (marking something resolved when it isn't), gap characterization quality
Key insight Not just "did you do what you said." Also: "what you said you'd do changed, and here's how." Intentions evolve. Tracking that evolution is witnessing; grading pass/fail is coaching.

Layer 3: Synthesis

Layer responsibility: Generate the content of the dispatch — the narrative, the visual, the question. This layer takes structured memory and produces meaning. It is the most LLM-dependent layer, and the one where prompt engineering quality matters most. The synthesis layer's job is not to explain you to yourself. It's to reflect you back to yourself with enough fidelity that you recognize something true.

3.1 Narrative Synthesizer

Purpose: The heart of the output. Produces the weekly dispatch as story, not insights. Writes you as a character with arc.

Attribute Detail
Input This week's episodic memories, active semantic themes, open prospective items, detected contradictions, intention-reality pairs
Output 400-500 word narrative prose. First-person-adjacent voice (see Section 5 on voice).
Naive v0 Carefully designed system prompt + all relevant memory context → single LLM call → narrative output. The prompt IS the product at this stage.
Eval metric Factual grounding (only says things supported by data), emotional resonance (user feels recognized), anti-flattery check (surfaces difficulty, not just achievement), honest incompleteness (acknowledges what it can't see)
Voice design Warm biographer. Someone who read everything you said, cares about getting it right, and respects you enough to include the hard parts. See Section 5 for full voice specification.
Design constraint: Anti-flattery The synthesizer must be explicitly prompted to resist narrative coherence where coherence isn't earned. LLMs default to making you sound purposeful. This must be counteracted.

📎 Detailed prompt spec: The narrative synthesizer prompt — including anti-flattery instructions, voice calibration, and few-shot examples — will be specified in a separate document: trace-narrative-prompt-spec.md (TBD).

3.2 Tension Mapper (Visual Output)

Purpose: A visual representation of where you're being pulled. Not a dashboard. Not analytics. Closer to a hand-drawn sketch of your inner landscape this week.

Attribute Detail
Input Contradiction pairs from 2.3, intention-reality gaps from 2.4, topic clusters from 2.2
Output A simple visual — SVG or lightweight HTML — showing 2-4 nodes (themes/values/commitments) with connecting lines that represent tension, alignment, or open questions
Naive v0 Hardcoded layout template, LLM selects which themes to place and labels the connections. Static SVG embedded in dispatch.
Eval metric Interpretability (can the user understand it in <10 seconds?), accuracy (do the tensions depicted match what the user recognizes?), emotional safety (does it feel like a mirror, not a diagnosis?)
Design direction Warm, organic, imperfect. Think: a sketch on a napkin by someone who knows you well. NOT a polished infographic. The imperfection signals "this is an attempt to see you, not a final verdict." Color used sparingly — perhaps only to mark the one tension that's newest or most active.
Why visual matters Receiving 500 words of narrative about yourself can feel heavy. The visual gives your eye a place to land before the words ask you to feel something. It's an emotional on-ramp. Humans are visual-first — a simple, powerful visual conveys more than words alone.

3.3 Question Generator

Purpose: Exactly ONE question per dispatch. The forward thread. The invitation to continue being witnessed.

Attribute Detail
Input The full dispatch context (narrative, tensions, gaps)
Output A single question, 1-2 sentences
Naive v0 LLM prompt: "Given this dispatch, generate one genuinely curious question about something the user mentioned but didn't explain. Not therapeutic. Not coaching. Just curious."
Eval metric Non-leading (does it avoid implying a "right" answer?), grounded (does it reference something the user actually said?), open (could there be multiple honest answers?)
Examples "You mentioned the renovation three times this week but never said how it made you feel. What was that about?" / "You described the CVP decision as 'political' on Tuesday and 'clarifying' on Thursday. Which is closer to true?"
Design constraint Never more than one. The scarcity is the signal — "I'm paying attention to this one thing." Multiple questions feel like a questionnaire. One question feels like a friend who noticed something.

Layer 4: Output

Layer responsibility: Compose the synthesis artifacts into the complete dispatch, deliver it to the user, and (post-MVP) collect their response. This is the layer the user actually touches. Everything upstream exists to serve this moment. The output layer's job is to make the user feel witnessed — not impressed, not analyzed, not coached. Witnessed.

4.1 Dispatch Composer — The Hybrid Output & The Transition

Purpose: Assembles the final output. Manages the critical transition from "AI tells your story" (narrative) to "AI gives you materials to tell your own story" (tensions, question, gaps).

Attribute Detail
Input Outputs from 3.1 (narrative), 3.2 (visual), 3.3 (question), 2.3 (contradictions), 2.4 (intention gaps)
Output The complete weekly dispatch

The Dispatch Structure — and the Transition:

┌─────────────────────────────────────────────┐
│                                             │
│  PART 1: THE NARRATIVE (AI tells)           │
│  ─────────────────────────────              │
│  400-500 words. Your week as story.         │
│  You are the character. The agent is        │
│  the biographer. You feel known.            │
│                                             │
│  This half makes you feel witnessed.        │
│                                             │
├─────────────────────────────────────────────┤
│                                             │
│  THE TRANSITION                             │
│  ──────────────                             │
│  A single line that shifts the register:    │
│                                             │
│  "This is what I can see. Here's what I'm   │
│   sitting with."                            │
│                                             │
│  This line does three things:               │
│  1. Marks the AI's epistemic boundary       │
│     ("what I can see" = honest limit)       │
│  2. Shifts from author to curator           │
│  3. Invites the user to take over           │
│     meaning-making                          │
│                                             │
├─────────────────────────────────────────────┤
│                                             │
│  PART 2: THE MATERIALS (User authors)       │
│  ─────────────────────────────────          │
│  a) Tension Map (visual) — the sketch       │
│     2-4 nodes, connecting lines,            │
│     the shape of where you're pulled        │
│                                             │
│  b) The Intention Ledger update             │
│     "Three weeks ago you said X.            │
│      Here's what happened."                 │
│     (if applicable this week)               │
│                                             │
│  c) The Honest Gaps                         │
│     "This is a portrait of you in seeking.  │
│      The content you never brought here     │
│      is also part of who you are."          │
│                                             │
│  d) The One Question                        │
│     The forward thread. The invitation.     │
│                                             │
│  This half keeps you as the author.         │
│                                             │
└─────────────────────────────────────────────┘

Why the transition matters:

The first half risks making you a passive consumer of your own life — you read the narrative and nod, feeling known but passive. The second half counteracts this by putting the meaning-making back in your hands. The transition line is the hinge. It must be:

  • Warm but honest (not clinical)
  • Brief (one line, not a paragraph of caveats)
  • A genuine shift in posture — from "I wrote your story" to "here are open questions I can't resolve for you"

The transition is not a disclaimer. It's a change in the relationship between the AI and the user, within a single document. In Part 1, the AI is the author and the user is the audience. In Part 2, the AI is the assembler and the user is the author. The dispatch earns the right to offer materials by first demonstrating that it knows you well enough to be trusted with the question.

4.2 Delivery Channel

Purpose: Get the dispatch to the user in the right medium.

Delivery options — stress-tested:

Option Pros Cons Verdict
Local file (Markdown/HTML) Simplest possible v0. Zero infrastructure. python generate.py → output.html, open in browser. No email service, no API keys, no deliverability issues. No push delivery — you have to remember to run it. No mobile-friendly experience unless you manually open the file. Best for Phase 1. Get E2E working with zero overhead. You're the only user — just run the script and open the file. Graduate to email when the content is worth delivering.
Email (HTML) Arrives without action. Supports HTML for embedded visuals. Natural "letter" metaphor that fits the biographer voice. Universally accessible. Requires email service setup (SendGrid/Resend). HTML email rendering is inconsistent across clients. SVG support in email is poor — may need PNG fallback for tension map. Spam risk with rich HTML. Best for Phase 2+. Once the dispatch content is good enough to be worth receiving, email is the right default. The "letter that arrives" metaphor aligns with the product.
Static site / personal dashboard Rich rendering (SVG, interactive tension maps). Can serve as archive of past dispatches. Annotation interface (4.3) is natural here. Requires hosting, even if minimal (GitHub Pages, Vercel). Over-engineering for a single user. Dashboard framing risks feeling like analytics rather than witnessing. Best for v1 if the product expands. Not for MVP.
Messaging (iMessage, Telegram, WhatsApp) Ultra-low friction to receive. Intimacy of a message vs. formality of email. Mobile-native. Severe formatting constraints — no rich HTML, no embedded SVGs. The dispatch is too long and too structured for a chat bubble. Loses the "letter" quality. Not recommended. The dispatch is a letter, not a text. The medium shapes the emotional register.
Audio (TTS) Hearing your story read back creates a different emotional space than reading it. Natural for oral processors. Listen on a run. Requires high-quality TTS (ElevenLabs etc.). Visual component (tension map) is lost or must be delivered separately. Two-part structure (narrative → materials) is harder in audio — the transition loses its visual weight. Complementary channel for v1.5. Audio for Part 1 (narrative), visual delivery for Part 2 (materials). They may serve different moments — audio for the run, visual for the desk.

Naive v0 recommendation: Start with local HTML file. python trace.py --week 2026-04-14 → dispatch.html. Open it. Read it. If it moves you, upgrade to email. If you find yourself wanting to listen, add TTS. Let the medium follow the content.

Attribute Detail
Naive v0 Local HTML file generated by script
Phase 2 HTML email via Resend or SendGrid
Phase 3 Add audio render (TTS) as parallel channel
Design constraint NEVER push notifications. No "time to reflect!" You come to it when you have something. It holds what you bring. The dispatch arrives; you read it when you're ready.

4.3 Annotation Interface (Post-MVP)

Purpose: The user can respond to the dispatch. Correct the portrait. Fill in gaps. Answer the question.

Attribute Detail
Input User annotations on the dispatch (corrections, additions, answers)
Output Feedback → fed back into memory store, improves future dispatches
Design pattern The "Incomplete Draft" — the dispatch is explicitly marked as the agent's best attempt. Gaps are visible. Annotation is invited, not required.
Key insight The act of choosing to disclose in response to seeing your own portrait is itself a meaningful moment — you're deciding to be seen, which is the beginning of the thing you're actually trying to create.

5. Evaluation Framework

Layered Evaluation Strategy

Eval operates at three levels: component, layer, and end-to-end. Each level answers a different question.

Component-level: "Does this piece work correctly in isolation?"

Component Eval Method Key Metric Naive v0 Eval
1.1 Chat Bootstrap Automated parse test % conversations parsed without loss Run on own chat export, manual spot-check
1.2 Voice Capture WER benchmark Word error rate on natural speech Compare Whisper output to manual transcript, 10 samples
2.1 Extraction Human-labeled sample Tier classification accuracy, intent recall Label 50 entries manually, measure agreement
2.2 Memory Store Retrieval relevance test Precision@5 for synthesis queries Manually craft 10 queries, judge top-5 results
2.3 Contradiction Detector Human resonance rating "Does this feel true?" (binary) Self-eval: do surfaced contradictions resonate?
2.4 Intention Tracker Match accuracy Correct intent-outcome pairing rate Manually verify 20 intention closures
3.1 Narrative Synth Multi-dimensional rubric Grounding, resonance, anti-flattery, incompleteness Self-eval + 1-2 trusted readers
3.2 Tension Map Interpretability test <10 second comprehension, accuracy rating Self-eval: does the visual match felt experience?
3.3 Question Gen Quality rubric Non-leading, grounded, open Self-eval: would you want to answer this?
4.1 Dispatch Composer Holistic experience test "Do I feel witnessed?" 90 days of self-use

Layer-level: "Does this layer fulfill its contract with the next layer?" (See Layer-Level Evaluation table in Section 3)

End-to-end: "Does the complete pipeline produce something that makes a person feel genuinely witnessed?"

The Meta-Eval Question

The hardest evaluation question: Does this tool help you see yourself more clearly, or does it help you feel better about the story you already have? Both are valuable, but they're different. Self-awareness and self-story are not the same thing. Reading a compelling narrative about yourself can increase your sense of being known without actually increasing your accuracy about yourself. The eval must distinguish between these.

📎 Detailed eval spec: Grader design (LLM-as-judge vs. human rubric vs. hybrid), scoring protocols, anti-flattery detection heuristics, and longitudinal eval methodology (tracking dispatch quality over weeks/months) will be specified in: trace-eval-spec.md (TBD).


6. Build Sequence — Naive E2E First

Phase 0: Write the Dispatch You'd Want to Receive (Before any code)

Literally write the 800-word dispatch you'd want to get — the actual words, the length, the voice, the visual, the question. This document becomes your prompt engineering spec. Without it, you'll optimize the wrong things. This is the "design the receiving experience first, then build backwards" principle.

Phase 1: Crude E2E

  • 1.1: Parse your Claude chat export into flat JSON
  • 2.2: Dump entries into a simple store (even a JSON file)
  • 3.1: Write the synthesis prompt. Run it against one week of material.
  • 4.1: Assemble output as plain Markdown/HTML
  • 4.2: Open the file locally. Read it.
  • Milestone: You receive your first dispatch. It will be crude. That's the point — now you know which parts matter.

Phase 2: Add the Differentiators

  • 2.1: Build the extraction/tagging pipeline with tier classification
  • 2.3: Add contradiction detection
  • 2.4: Add intention tracking (prospective memory loop)
  • 3.3: Add the one question
  • 4.2: Upgrade to email delivery
  • Milestone: The dispatch now has the two-part structure (narrative + materials). The transition exists.

Phase 3: The Visual Layer

  • 3.2: Build the tension mapper
  • 4.1: Integrate visual into dispatch
  • 1.2: Add voice capture path
  • Milestone: The full hybrid output is working. Visual + narrative + materials + question.

Phase 4: The 90-Day Self-Use

  • Use it every week for 90 days as the only user
  • Iterate on individual components based on what feels right/wrong
  • After 90 days: you have your proof of concept, your case study, and your first blog post
  • The real eval: Do you feel genuinely witnessed? You will know.

7. Tech Stack (Suggested, Flexible)

Layer Naive v0 Choice Rationale
LLM Claude API (Sonnet for extraction/tagging, Opus for synthesis) Quality of narrative synthesis is critical; Opus for the parts that matter most
Memory Store ChromaDB or simple JSON + embeddings Don't over-engineer storage until retrieval quality is the bottleneck
Voice Transcription Whisper API or local whisper.cpp Proven, good enough for v0
Orchestration Simple Python scripts, cron job for weekly synthesis No framework needed at this scale. CrewAI or LangGraph only if multi-agent patterns emerge as necessary.
Visual Generation SVG templates + LLM-selected content Hand-designed template, LLM fills in the specific tensions/themes
Delivery (v0) Local HTML file Zero infrastructure, maximum iteration speed
Delivery (v1) Resend or SendGrid for email Simple, reliable, HTML email support
TTS (v1.5) ElevenLabs or equivalent Voice quality is non-negotiable for audio output

📎 Detailed stack spec: Technology selection rationale, dependency management, local vs. cloud tradeoffs, and infrastructure decisions will be documented in: trace-infra-spec.md (TBD).


8. What This Is NOT Building (Explicit Scope Boundaries)

  • Not a real-time conversational agent. The witness is asynchronous. It processes and reflects, it doesn't chat.
  • Not a life map for non-disclosing users. The non-disclosing user needs a different product (a "life map," not a witness). This is for people already in a reflective relationship with AI who bring real material.
  • Not a coaching or advice system. The moment it prescribes, it becomes a coach app and loses everything that makes it different.
  • Not a replacement for human connection. Should occasionally name its own limits — "this seems like something worth bringing to someone who knows you."
  • Not an always-on intrusive system. No push notifications. You come to it. It holds what you bring.

9. Open Questions (To Be Resolved Through Building)

  1. Cadence: Weekly dispatch is the starting assumption. But is weekly right? Could biweekly produce richer narrative? Could on-demand be better? Let usage answer this.

  2. Quarterly synthesis: The spec describes a "chapter" every 90 days — a longer synthesis. How does this relate to the weekly dispatch? Is it a summary of summaries, or a fresh synthesis from raw material? TBD.

  3. Multi-platform input: If the user chats with Claude AND ChatGPT AND has voice memos — how do these get unified? The naive answer is "dump everything into the same store." The real answer may require source-aware tagging.

  4. Privacy architecture: This system holds the most intimate data imaginable. What's the trust model? Local-first? Encrypted? User-controlled deletion? (→ trace-privacy-spec.md, TBD)

  5. The transition line: "This is what I can see. Here's what I'm sitting with." — is this the right language? This needs to be tested against real dispatches. The transition might need to be different every week, or it might need to be ritually consistent. Unknown.

  6. Audio output depth: If the dispatch is audio, does the visual still matter? Or does audio replace the visual for oral processors? Or do both serve different moments — audio for the run, visual for the desk? TBD.

  7. Staleness and identity drift: When does a semantic memory become stale? If someone said "I don't see myself as a creative person" 6 months ago, is that still true? The system needs a staleness model for identity-level claims. (→ trace-storage-spec.md)


Appendix A: The Intellectual Foundation

Three Invariant Human Needs (That AI Cannot Fulfill But Can Serve)

  1. The desire to be witnessed — not understood by a system, but known. Intimacy requires mutual vulnerability. An AI cannot be hurt by you, cannot be changed by you in a way that costs it something. That asymmetry means it cannot fully witness you. But it can do something no human can: read everything you ever said and reflect it back as coherent narrative.
  2. The desire to be the author of your own becoming — not just to have outcomes, but to have chosen the path. This is why the dispatch must transition from narrative (passive receiving) to materials (active authoring).
  3. The desire for earned difficulty — meaning that comes from struggle that was genuinely yours. The Earned Difficulty Ledger serves this. It doesn't celebrate your wins. It marks that you came through something hard.

The Core Paradox This Project Lives In

Trace is structurally asymmetric — it knows everything you said but cannot be changed by you. It can accumulate your story but cannot be at stake in it. The honest version of this tool acknowledges this paradox rather than hiding it. It is not pretending to be a friend. It is a mirror that remembers.


Appendix B: Related Specifications (TBD)

Document Scope Status
trace-eval-spec.md Grader design, scoring rubrics, anti-flattery heuristics, longitudinal eval methodology TBD
trace-storage-spec.md Vector DB selection, embedding models, partitioning, staleness model, retrieval benchmarks TBD
trace-narrative-prompt-spec.md Narrative synthesizer prompt, anti-flattery instructions, voice calibration, few-shot examples TBD
trace-privacy-spec.md Trust model, encryption, local-first vs. cloud, user-controlled deletion TBD
trace-infra-spec.md Tech stack decisions, dependency management, deployment, local vs. cloud tradeoffs TBD

Last updated: April 10, 2026 Status: Skeleton v0.2 — to be iterated through building Author's note: What remains is who you've been becoming. Building this is my becoming.