project Feb 28, 2026

The Machine That Translates My Ideas for Different People

Reading style:
ai content communication writing

TLDR: I built a system that takes the same idea and reshapes it for different audiences — friends, engineers, kids, executives. Same truth, different packaging. This site is the first output. The narrative engine is what powers it.


The problem

I have a bunch of projects and ideas, but sharing them is hard. Not because the ideas are secret — because they’re trapped in formats that only I can understand.

My project specs are dense technical documents. My notes are full of jargon. When a friend asks “what are you working on?” I end up giving a rambling explanation that either oversimplifies to the point of being wrong, or goes too deep and their eyes glaze over.

The frustrating part is that the core idea is usually simple and interesting. “I built a system that argues with my own beliefs” is a compelling concept. “I built a pgvector-backed knowledge graph with hybrid scoring and automated synthesis” is the same thing, but only an engineer would care about that sentence.

The idea is the same. The packaging needs to be completely different depending on who’s listening.

What I’m building

A narrative engine. It takes raw source material — my project specs, notes, and conversations — and transforms it into audience-specific versions. Same core idea, different surface.

For a friend: “I read hundreds of articles and couldn’t remember what I thought about any of them. So I built a second brain that argues with me.”

For an engineer: “PKB: thesis-driven knowledge graph with pgvector embeddings, hybrid connection scoring, and automated synthesis. 160 tests, runs on a Mac mini.”

For a kid: “What if your notebook could think? Imagine all your notes could talk to each other and tell you things you never noticed.”

For a product manager: “Knowledge workers consume content but don’t synthesize it. The market lacks tools that challenge existing beliefs rather than just filing information.”

Same project. Four completely different entry points. Each one accurate, each one optimized for how that audience thinks.

How the themes work

I’ve defined six audience profiles, each with specific rules about voice, structure, complexity, and emphasis:

Keep it simple (friends and family). Conversational, analogy-driven, focuses on the human problem and what surprised me. No jargon.

Go deep (engineers). Technical, opinionated, full of tradeoffs and implementation details. Jargon expected. Failures included.

Explain like I’m 10 (kids). Story-driven, concrete metaphors from their world, ends with a thought-provoking question. Zero jargon, ever.

Business case (product managers). Problem, market gap, evidence, monetization. Frameworks over feelings.

Quick take (professional network). Hook, skills, outcome. Dense, scannable, written for someone scrolling on their phone.

Executive brief (senior leaders). Vision, timing, defensibility, scalability. Every word earns its place.

Each theme has rules about what to emphasize, what to avoid, and how to handle gaps in the source material. And critically: if the source material doesn’t have enough information for a theme (like market sizing for the executive brief), the system flags it rather than making something up.

Why this matters

We all do a version of this naturally. You explain your job differently to your mom than to a colleague. You tell a story differently to a five-year-old than to your boss. But doing it well, consistently, across multiple audiences, for every project? That’s hard.

The insight is that the translation layer is separable from the ideas themselves. I write the idea once, in whatever messy technical format comes naturally. The narrative engine handles the rest.

This site is the first output surface — a place where the different versions live. Eventually, the same engine will produce voice blogs, diagrams, social posts, and video scripts. Same ideas, any format, any audience.

But honestly, the most valuable thing so far hasn’t been the technology. It’s been the exercise of defining who my audiences are and what they care about. That forced clarity makes everything I communicate better — even the conversations where no engine is involved.

The problem, specifically

Projects and ideas live in SPECs, PLANs, and PKB notes — formats optimized for building, not sharing. When a non-technical person asks “what are you working on?” there’s no artifact to point them to. Converting a technical SPEC into an accessible explanation is manual, inconsistent, and usually done on the fly (badly).

The goal: automate the transformation from raw technical source material into audience-specific narratives, with quality controls that prevent AI slop.

Architecture

Source Layer (existing)
    |-- Project SPECs, PLANs (markdown)
    |-- PKB notes + theses (structured markdown, YAML frontmatter)
    |-- Conversations / session transcripts
    |
    v
Narrative Engine
    |-- Theme selection (audience profile)
    |-- Source gap analysis (what's missing for this theme?)
    |-- Narrative generation (LLM with humanizer gate)
    |-- Graphics generation (Mermaid + AI image gen working, SVG templates planned)
    |
    v
Quality Gate
    |-- Humanizer pass (Wikipedia AI writing patterns check)
    |-- Faithfulness check (every claim traceable to source)
    |-- Gap labeling ([NEEDS: market size data])
    |
    v
Output Surfaces
    |-- Website (Astro static site) -- BUILT
    |-- Voice blogs (TTS pipeline) -- PLANNED
    |-- Social snippets -- PLANNED
    |-- Diagrams/infographics -- PLANNED

Theme system

Six audience profiles, each codified with:

FieldPurpose
Job to be done (JTBD)What the reader is hiring this content for
Cognitive load strategyHow to manage complexity given reader’s expertise level
VoiceTone, person, style markers
StructureSection ordering, required/optional elements
ComplexityJargon rules, Flesch-Kincaid target, explanation depth
EmphasisWhat matters most to this audience
Anti-patternsWhat to explicitly avoid

Grounded in Cognitive Load Theory (expertise reversal effect), COPE framework, Plain Language Movement, and narrative transportation research. Validated via Gemini Deep Research against academic audience segmentation literature.

Key insight from CLT: detailed explanations that help novices actually hinder experts (extraneous cognitive load). The theme system operationalizes this — the builder theme assumes schemas exist and is concise; the friends theme builds schemas from scratch with analogies.

Faithfulness principle (critical guardrail)

The engine transforms source material. It does not fabricate.

Three responses to source gaps:

  1. Prompt for input — surface the specific question to the author
  2. Prompt for research — recommend a deep research query
  3. Placeholder with label[NEEDS: competitive analysis] ships visibly

Gap risk varies by theme. Friends and young-explorer themes rarely have gaps (they need less external data). PM and executive themes are most gap-prone (they require market/business context that SPECs don’t contain).

The rule: when you don’t know, say you don’t know. Never fill gaps with plausible-sounding filler.

Theme switcher

Reader-facing UI that lets visitors self-select their preferred reading style:

  • Labels: “Keep it simple” / “Go deep” / “Explain like I’m 10” / etc.
  • All available variants rendered at build time, JS toggles visibility
  • localStorage persistence + URL parameter override for sharing specific versions
  • Only shows buttons for themes with written content

Approach: Option A (all variants in one page, client-side switching). Acceptable page weight trade-off for instant switching with no network request.

Site stack

Astro (static output) + Tailwind CSS + @tailwindcss/typography. Dark-first design (Linear/Vercel aesthetic). Inter + JetBrains Mono. Content collections with Zod schema validation.

45 vitest tests covering: build verification, page rendering, dark theme application, no duplicate h1s, viewport meta, meta descriptions, internal link integrity, focus-visible CSS, html lang attribute.

Build: 11 pages in ~650ms, 64KB total output. Hosted on S3 + CloudFront.

Content inventory

Each project rendered in 3 themes minimum (friends, builder, young-explorer):

ProjectFriendsBuilderYoung Explorer
PKBdonedonedone
AI Arenadonedonedone
Bob (AI partner)donedonedone
AI Safety (containers + MFA)donedonedone
Narrative Engine (this)donedone
Boring Workflows (thesis)done

What’s working

  • Theme definitions produce genuinely different output from the same source. The PKB friends piece and builder piece are unrecognizable as the same project — different structure, vocabulary, emphasis, length.
  • Humanizer pass catches AI patterns effectively. The friends theme reads like a human wrote it over dinner.
  • Three drafts reviewed and voice-approved by Raymond on first iteration with minor feedback.

What’s not built yet

  • SVG template graphics. Framework visuals (2x2 matrices, flywheels) not yet templated. Mermaid diagrams and AI-generated illustrations are working.
  • Automated pipeline CLI. Currently manual. Phase 4: narrative-engine render pkb --theme friends --format blog.
  • Automated pipeline. Currently manual: read SPEC, write themed narrative, humanizer pass. Phase 2 automates: render pkb --theme friends --format blog.
  • Multi-format output. Voice blogs, social snippets, video scripts all planned but not built.

Key design decision: COPE not bespoke

The architecture follows NPR’s COPE model (Create Once, Publish Everywhere). One “pillar” source (the SPEC/PKB notes) atomized into audience-specific outputs. This means:

  • Adding a new theme doesn’t require rewriting content — it requires defining a new theme profile and running the existing source through it
  • Adding a new output format (voice, video) doesn’t require new content — it requires a new renderer
  • The source material is the single source of truth. If a SPEC changes, all themed versions should be regeneratable

This scales better than writing bespoke content per audience per format. The constraint is that the source must be rich enough to support all themes — which circles back to the gap-awareness system.

A lightbulb character trying on different costumes -- lab coat, business suit, party outfit, tiny kid-sized outfit.

The costume party problem

Have you ever tried to explain something you’re really excited about to different people?

Maybe you learned something cool in science class. You explain it to your best friend and they get it instantly. Then you try to tell your little cousin and they just look confused. Then your teacher asks about it and suddenly you feel like you need to use bigger words.

The idea is the same every time. But the way you explain it needs to change depending on who’s listening. It’s like the idea needs to wear different costumes for different parties.

Why this is harder than it sounds

Here’s the tricky part: when you change how you explain something, you have to be really careful not to change what it means.

If you make it too simple, you might accidentally say something wrong. If you make it too complicated, nobody understands. If you use the wrong examples, people might get the wrong idea entirely.

Professional writers and teachers deal with this every day. A newspaper reporter has to explain a complicated science discovery in a way that everyone can understand. A textbook writer has to explain the same discovery in a way that students can learn from. A scientist has to explain it to other scientists with all the technical details.

Same truth. Three completely different explanations.

What I’m building

I’m building a machine that does this automatically. I write down an idea once — in my own messy, technical notes — and the machine reshapes it for different audiences.

For my friends: “I built a system that argues with my own beliefs.” Simple, interesting, no confusing words.

For engineers (people who build things with computers): “A knowledge graph with vector embeddings and automated synthesis.” Very specific, very technical.

For someone your age: “What if your notebook could think and tell you things you never noticed?” A question that makes you want to know more.

Same project. Three completely different starting points. Each one is true. Each one is designed for how that person thinks.

The six costumes

I’ve designed six different “costumes” my ideas can wear:

The dinner conversation. For friends and family. Casual, fun, uses comparisons to everyday things.

The blueprint. For builders and engineers. Detailed, precise, shows how everything works under the hood.

The adventure story. For curious kids like you. Uses stories, asks questions, connects to things in your world.

The business case. For people who want to know: is this a good idea? Will it work? Who would use it?

The quick version. For busy people scrolling on their phones. The highlights in two minutes.

The big picture. For leaders making big decisions. Just the vision and the strategy.

The rule that matters most

Here’s the most important rule I built into the system: if it doesn’t know something, it has to say so.

Think about how important that is. Imagine if the machine was trying to explain something for a business audience, and the business version needs market size data — like “how many people would use this?” But my original notes don’t have that information.

A lazy machine would just make up a number that sounds right. A trustworthy machine says “I don’t have this information yet.”

That’s a rule for life, not just for machines: if you don’t know something, it’s always better to say “I don’t know” than to make something up. The people who are really smart aren’t the ones who have all the answers. They’re the ones who know what they don’t know.

Your turn

Next time you need to explain something — a school project, a game you love, an idea you had — try this experiment: explain it to three different people, and adjust how you say it for each one.

Which explanation was hardest to write? Which one taught you the most about your own idea?

Sometimes the best way to understand something deeply is to try explaining it to someone who thinks completely differently from you.