The Problem
Why Normal PM Tools Don’t Work For Us
We’re three founders building an AI product. Each of us works with AI assistants (Claude Code, Cursor, etc). The AI does most of the actual work — writing specs, updating documents, tracking decisions. But traditional project management tools are built for humans clicking buttons in a browser.
The Human Problem
I can’t see what you did
Will updates the gravity scoring spec. Rob adds the error bank. Q restructures the whitepaper. Nobody knows what changed until someone asks on a call. Updates get lost in Slack. The whitepaper is always stale.
The AI Problem
Every AI session starts from zero
Will’s AI writes a brilliant spec — in a Google Doc. Q’s AI can’t read it. Rob’s AI doesn’t know it exists. Each AI operates in isolation. No shared context. No shared state. Three AIs doing redundant work.
The core insight: If AI is doing most of the work, the project management system needs to be optimized for AI first and humans second — not the other way around. AI reads structured data natively. Humans need visual dashboards. Build for both.
The Architecture
Two Layers — One Source of Truth
Backend — For AI
Structured YAML files
Every spec, task, decision, question, and milestone is a YAML file with typed fields and relationships to other objects. AI reads and writes these natively. No parsing HTML. No navigating a GUI. Pure structured data.
Frontend — For Humans
Auto-generated static HTML site
A Command Center, whitepaper status page, spec detail pages, and system manual — all generated from the YAML data by render_site.py and deployed to founder.mrd.works via Cloudflare Pages. Open the site on your phone, see the current state. Never edit the HTML directly — it regenerates every deploy.
THE FLOW
Will’s AI updates spec_001.yaml (gravity scoring formula)
↓
Meridian Core auto-bumps version, logs to activity, attributes to Will
↓
render_site.py regenerates Command Center + Whitepaper + Spec pages + Manual
↓
Q opens founder.mrd.works → sees “Will updated spec_001 v3 — gravity formula”
↓
Q’s AI runs meridian inbox → sees the change with full context
Nobody copies and pastes. Nobody messages “hey I updated the doc.” The system tracks every change, attributes it, and surfaces it to whoever needs to see it.
The Object Model
Everything Is a Connected Object
There are no “documents” in the traditional sense. Everything in the system is a typed object with structured fields and relationships to other objects. A spec is an object. A decision is an object. A task is an object. They all connect.
| Type | What it is | Example |
|---|
| Vision | North star documents | The whitepaper, the manifesto, the founding constitution |
| Spec | Technical specification | Node schema, gravity scoring, embedding standard |
| Decision | A choice made with rationale | “Gravity replaces confidence as primary ranking signal” |
| Question | Something unresolved, assigned to someone | “Decay function: time-based or usage-based?” |
| Task | Work item with owner and priority | “Define base schema” — Will, P0 |
| Milestone | Weekly goal that tasks roll up to | “Ship PM system + align on schema” |
| Call | Meeting record with extracted action items | “Founders call Apr 4” — 3 tasks, 2 decisions extracted |
| Blocker | Something preventing progress | “Schema alignment needed before either founder builds” |
How objects connect
Every object can reference any other object by ID. The system traverses these connections to build context. When you look at a spec, you don’t just see the spec — you see which whitepaper sections it implements, which decisions shaped it, what questions are still open, which tasks depend on it, and what changed recently.
CONTEXT GRAPH FOR SPEC_001: UNIFIED NODE SCHEMA
VISION: Whitepaper section 05 “Knowledge Architecture”
VISION: Whitepaper section 15 “Technical Specification”
↑ this spec implements these sections
DECISION: dec_003 “Gravity replaces confidence”
↑ this decision shaped the spec
QUESTION: “Decay function: time or usage?” (assigned: Will)
↑ still unresolved
BLOCKER: “Schema alignment needed”
↑ blocks task_001 and task_002
TASKS: “Define base schema” (Will), “Rename terms” (Q)
↑ depend on this spec
ACTIVITY: Will pushed v3 — gravity formula (Apr 4)
Q created spec (Apr 4)
This is the key difference from a flat task list or a shared doc. Every object knows its full context. When Will’s AI starts working on the gravity spec, it doesn’t just see the spec — it sees the whitepaper vision it serves, the decisions that constrained it, the open questions, and the tasks waiting on it. It makes better decisions because it has full business context.
The Weekly Cadence
How a Typical Week Works
1
Monday — Set Goals
Create milestones for the week, assign tasks
At the start of each week, we set 2–4 milestones. Each milestone is a group goal that multiple founders contribute to. Tasks roll up to milestones.
$ meridian milestone “Ship PM + align on schema” --owners Q,Will --tasks task_001,task_002
WEEK 2026-W14
• Set up PM system and schema alignment Q, Will 0/4
[ ] Build PM system (Q, P0)
[ ] Define base schema (Will, P0)
[ ] Site render pipeline (Q, P1)
[ ] Review two-layer schema (Will, P1)
• Standardize terminology Q 0/1
[ ] Rename terms to industry standard (Q, P1)
• Error bank spec first draft Rob 0/1
[ ] Draft error bank spec (Rob, P1)
2
Meetings — Capture Everything
2 scheduled calls per week + ad-hoc, every one produces structured objects
After each call, raw notes get fed into the system. The AI extracts tasks, decisions, and questions from the notes and creates the corresponding objects. The call record links to everything it produced.
$ meridian capture “Founders Call April 4” --file notes.txt
Extracted:
TASKS:
+ task_004: Build Site render pipeline → Q
+ task_005: Review two-layer schema → Will
+ task_006: Draft error bank spec → Rob
DECISIONS:
+ dec_002: YAML source of truth, static HTML site as view layer
+ dec_003: All founders get CLI access + git clone
QUESTIONS:
+ question_003: BGE-M3 or newer embedding model? → Will
+ question_004: Dream Engine + error bank interaction? → Rob
$ meridian summarize call_001 --text “Aligned on schema approach...”
The meeting summary, extracted items, and attendees are all connected. When Q looks at task_005 later, the context shows it came from the April 4 call and links back to the meeting record.
3
During the Week — Work + Inbox
Each founder works with their AI, checks inbox for what others did
Each founder works on their assigned tasks using their own AI. The AI reads the system manual (CLAUDE.md), understands the architecture, and operates through the CLI or directly through the Python API.
Q’s AI
Builds the PM system
Creates objects, builds CLI commands, wires the render pipeline. Every change logged to activity with attribution.
Will’s AI
Updates gravity spec
Loads spec_001, adds the scoring formula, saves with summary. Version bumps automatically. Q sees it in his inbox.
Rob’s AI
Drafts error bank spec
Creates spec_003, defines the schema, links to Dream Engine architecture. Everyone sees the new spec appear.
The inbox system tracks what each founder has seen. When Will pushes a spec update, Q’s inbox shows:
$ meridian inbox
UPDATED (1 doc with new versions)
[spec] Unified Node Schema
spec_001 v2 → v3 (1 change)
v3 Will: Added gravity scoring formula with non-linear curve and 90-day decay
NEW (1 object you haven’t seen)
[spec] Embedding Standard
spec_002 v1 by Will
RECENT ACTIVITY FROM OTHERS
[Apr 5 18:27] Will: Created spec: Embedding Standard
[Apr 5 18:27] Will: Added gravity scoring formula
Q sees exactly what changed, who changed it, and the summary. No Slack messages needed. No “hey did you update the doc?”
4
Deploy — Push to founder.mrd.works
One command renders HTML and deploys to the live site
After making changes, run one command:
$ bash deploy.sh
Meridian Deploy
render_site.py → generates site/ from YAML objects
site/index.html Command Center
site/whitepaper.html Full whitepaper
site/specs/index.html Specs A-Z
site/specs/spec_001.html Individual spec pages
site/manual.html System manual
Cloudflare Pages → deploys site/ to founder.mrd.works
Account: bqminlee@gmail.com (isolated — Meridian only)
Project: meridian-portal
Domain: founder.mrd.works
The live site is now current. Open founder.mrd.works on your phone, see the dashboard.
The Live Site — founder.mrd.works
What Humans See
The live site at founder.mrd.works is the read-only frontend. Every page is static HTML auto-generated from YAML data by render_site.py and deployed via Cloudflare Pages. Nobody edits the HTML directly — it regenerates on every deploy.
The workspace
| Page | URL | What it shows |
|---|
| Command Center | index.html | Live dashboard: this week’s milestones (with progress), active blockers, tasks by founder, open questions, recent decisions, core docs status, activity feed. |
| Whitepaper | whitepaper.html | The full product vision document with per-section status. Each section shows which specs implement it, what’s in progress, what questions are open, and what’s blocking. |
| Specs | specs/ | Index of every technical spec. Click into any one to see: definition, formula, whitepaper references, dependencies, open questions, blockers, and full changelog with attribution. |
| Manual | manual.html | The system manual (CLAUDE.md rendered as HTML). Contains the full architecture, object model, commands, and rules. AI reads the local CLAUDE.md file; humans read this page. |
The Command Center
What you see when you open founder.mrd.works on your phone:
MERIDIAN — COMMAND CENTER
Week 2026-W14
• 1 ACTIVE BLOCKER
Schema alignment needed → blocks task_001, task_002
THIS WEEK’S GOALS
• Set up PM + schema alignment Q, Will 0/4
[ ] P0 Build PM system (Q)
[ ] P0 Define base schema (Will)
[ ] P1 Site render pipeline (Q)
[ ] P1 Review two-layer schema (Will)
• Standardize terminology Q 0/1
• Error bank spec draft Rob 0/1
MEETINGS
Apr 5 Founders Call | 3 tasks, 2 decisions, 2 questions
Summary: Aligned on schema approach. Q builds PM, Will does schema...
Q’s TASKS (3) Will’s TASKS (2) Rob’s TASKS (1)
P0 Build PM system P0 Define base schema P1 Error bank spec
P1 Render pipeline P1 Review schema
P1 Rename terms
OPEN QUESTIONS (4)
Industry term mapping → Q
Gravity decay function → Will
BGE-M3 or newer? → Will
Dream Engine + error bank → Rob
RECENT DECISIONS
PM backend for AI, frontend for humans — Q, Will
YAML source of truth, HTML site as view — Q, Will
CORE DOCS
Whitepaper v3 | Manifesto v1 | Constitution v1
spec_001: Unified Node Schema v3 (Will)
spec_002: Embedding Standard v1 (Will)
ACTIVITY
Apr 5 Will Added gravity scoring formula
Apr 5 Will Created spec: Embedding Standard
Apr 5 Q Created spec_001, 6 tasks, blockers...
The Whitepaper as a Living System
The Document That Updates Itself
The whitepaper is not a file someone edits. It’s a rendering of structured data. When Will updates a spec, the whitepaper section that references that spec automatically reflects the change on the next sync.
WHITEPAPER — SECTION MAP
✓ 01. Abstract Approved
✓ 02. The Problem Approved
✓ 03. Personal System vs. Meridian Approved (Will v4)
✓ 04. The Base Model Approved
• 05. The Knowledge Architecture In Progress
→ spec_001: Unified Node Schema draft v3 (Will)
→ spec_002: Embedding Standard draft v1 (Will)
→ ? Decay function: time or usage? open (Will)
□ 06. Generational Architecture Not started
□ 07. The Codex System Not started
□ 08. The Collective Layer Not started
• 10. Self-Evolution Architecture In Progress
• 15. Technical Specification In Progress
→ spec_001: Unified Node Schema draft v3 (Will)
→ • BLOCKER: Schema alignment needed
The same spec (spec_001) appears under both Section 05 and Section 15 because it implements both. It’s one object referenced from two places. When Will updates the spec, both sections show the new version.
Click into any spec from the whitepaper page and you see the full detail: definition, formula, inputs, whitepaper references, dependencies, open questions, and the complete changelog showing who changed what and when.
AI Onboarding
How a New AI Gets Up to Speed
When any founder starts a new AI session, the AI needs to understand the full system before it can operate. Here’s the sequence:
AI SESSION START
1. AI reads CLAUDE.md (the System Manual)
→ understands: architecture, object model, commands, rules
→ knows: YAML is source of truth, HTML site is view, never edit HTML directly
2. AI checks inbox
→ sees: what changed since last session, who did what
→ knows: current state without asking the founder
3. AI checks status
→ sees: tasks assigned, blockers, open questions
→ knows: what needs attention right now
4. AI loads context for whatever the founder wants to work on
→ sees: the full graph — vision refs, deps, questions, activity
→ knows: the business context behind every technical decision
5. AI asks: “What do you want to work on?”
The System Manual is the key. It lives as a local file (CLAUDE.md in the meridian folder) and is also rendered as manual.html on founder.mrd.works. Claude Code reads the local file automatically. Humans can read it on the live site. Every founder clones the repo from github.com/Qphiuchus/meridian and syncs via git push/pull.
When anyone changes the system, they update the manual. New object types, new commands, new rules — the manual gets updated. Next session, every AI reads the updated manual. Everyone’s AI stays aligned.
Portability
The View Layer Is Replaceable
The static HTML site is the view layer, not the source of truth. The real data is YAML files in git. If we want to switch to a custom web app, Linear, or anything else, we write a new render target. The backend doesn’t change.
What stays
Everything that matters
All objects, all history, all relationships, all changelogs, the full activity log, the complete whitepaper content, every spec, every decision. It’s all in YAML files on disk.
What changes
Only the render scripts
Replace render_site.py with whatever targets the new frontend. Same data, different rendering. Could be a React app, a custom dashboard, or a completely different tool.
The Complete Picture
Everything Connected
THE MERIDIAN PM SYSTEM
INPUTS SYSTEM OUTPUTS
─────── ────── ───────
Meeting notes → YAML Objects → Command Center (founder.mrd.works)
Spec research → specs/ → Whitepaper page (founder.mrd.works)
Decisions made → decisions/ → Spec detail pages (founder.mrd.works)
Questions raised → tasks/ → Inbox (CLI)
Weekly goals → milestones/ → Weekly view (CLI)
calls/ → Activity feed
questions/ → Context graphs
blockers/
vision/
↑
meridian_core.py
Auto-versions every change
Logs every mutation
Attributes to author
Resolves all relationships
↑
render_site.py → deploy.sh
YAML → HTML → founder.mrd.works
Git: github.com/Qphiuchus/meridian
Cloudflare: bqminlee@gmail.com
↑
CLAUDE.md
The System Manual
Every AI reads this first
Shared brain across all founders
0
Manual status
updates needed