Design Philosophy

The 9 principles that guide every feature decision in Coppermind CMO. Read this before building anything new or proposing a feature.

Why This Matters#

Coppermind is a product, not a generic memory system. Every tool, every prompt, every workflow is shaped by these principles. If a proposed feature violates a principle, it needs a strong reason or it should not be built.

The 9 Principles#

1. Sit on top, never replace#

Read from the tools CMOs already use (Granola, Obsidian, Google Calendar, Slack, Gmail). Write back into them. Never ask someone to change how they work.

Test: Can a CMO use Coppermind for a week without changing anything about their existing workflow?

In practice: The auto-ingest system polls connected sources rather than requiring the CMO to push data. The session watcher captures knowledge from normal Claude Code conversations. No new apps to open, no new habits to form.

2. Show your work#

When Coppermind modifies, updates, or supersedes anything, it shows exactly what changed. Change markers, not silent updates.

Test: After any automated action, can the CMO see exactly what changed at a glance without digging?

In practice: Ingestion summaries report counts by memory type. Reconsolidation notes when it merges memories. Brand DNA history tracks every field change with timestamps.

3. Read-only vs read-write discipline#

Each workflow has a clear contract:

Test: Can you explain in one sentence what each tool reads and writes?

4. Draft, never send#

The human stays in the decision seat on communications. Follow-up emails, Slack messages, and client updates are drafted for review -- never sent automatically. Even with explicit approval, the CMO sees the full message before it goes out.

Test: Is there any path through the product where a message reaches a client without the CMO seeing it first?

5. Reconcile quick captures into structured plans#

Quick notes, between-meeting thoughts, and Siri captures get stored fast but need to be processed into action items, agenda items, or plan updates. Raw capture without reconciliation is just a smarter notepad.

Test: If a CMO says "quick note: Josh wants budget by Thursday" on Tuesday, does that show up as an action item in Thursday's meeting brief without additional effort?

In practice: The morning briefing and post-meeting processor are where reconciliation happens. Quick notes feed into meeting prep automatically through semantic search.

6. Build the engagement arc#

Every memory, meeting brief, and weekly plan contributes to a longitudinal record of the engagement. After 6 months, Coppermind can generate a retrospective showing what was accomplished against what was planned.

Test: After 3 months of use, can Coppermind generate a one-page engagement summary that a client would find impressive?

In practice: This is what makes the client handoff a deliverable instead of a loss. The exported client mind is the engagement arc.

7. Compound over time#

Test: Is the product noticeably more valuable in month 3 than month 1, without the CMO doing anything differently?

8. Sell time, not features#

The CMO is not buying 12 tools. They are buying back their evening. Every feature should compress operational overhead so the CMO stays in strategy, leadership, and decision-making.

Test: For any proposed feature, can you finish the sentence "This saves the CMO from having to ___"?

9. Adapt to the user, not the other way around#

The system learns how each CMO works, not just what they know about clients. Preferences shape every interaction -- briefings, extractions, follow-ups. The more you use Coppermind, the more it becomes perfectly adapted to you.

Test: After 2 weeks of use, does Coppermind's output feel like it was built for this specific CMO?

The Adaptive Preferences System#

This is the technical implementation of Principle 9.

Two levels of preferences#

CMO-level (stored on internal "CMO Preferences" client mind):

• Briefing format (action items first? stakeholders first?)
• Output style (bullets vs prose, concise vs detailed)
• Communication tone for drafts
• Morning briefing structure

Client-level (stored as preference memories on the client's client mind):

• "Always lead with revenue targets for this client"
• "Josh hates long emails -- keep follow-ups under 3 sentences"
• "Always include competitor context in briefings"

How preferences are applied#

Every tool that generates output:

1. Check for CMO-level preferences (search internal "CMO Preferences" client mind)
2. Check for client-level preferences (search active client mind, type=preference)
3. Apply preferences to output generation
4. If conflict: client-level wins over CMO-level

How preferences are learned#

When a CMO gives feedback, Claude stores it as a preference automatically:

• "That briefing was too long" -> stores "Prefers concise briefings, under 300 words" as preference
• "Always include competitor analysis for Acme" -> stores on Acme client mind as client-level preference
• "I like bullet points, not paragraphs" -> stores on CMO Preferences client mind as CMO-level preference

Applying These Principles to New Features#

Before building anything, answer these questions:

1. Does it sit on top? Does the CMO need to change their workflow?
2. Does it show its work? Will the CMO know what changed?
3. What does it read and write? Is the contract clear?
4. Does it draft, never send? Is the human always in the loop?
5. Does it compound? Is it more valuable in month 3 than month 1?
6. Does it save time? Can you finish "This saves the CMO from having to ___"?
7. Does it adapt? Can preferences shape the output?

If a feature fails multiple checks, reconsider whether it belongs in the product.

Reference#

• Full design philosophy: docs/DESIGN_PHILOSOPHY.md
• Roadmap and phasing: docs/ROADMAP.md
• Product positioning: docs/GO_TO_MARKET.md