Decision Logging
Log decisions so they stay useful later
Decision Logging & Synthetic Memory
How to record information into Continuity's synthetic memory so it's useful later.
The Basic Flow
When you make a durable project decision, record it into the synthetic memory immediately. If your AI is connected via a protocol like MCP, just tell it to log:
You: "Let's use Redis for caching because it has built-in TTL and we might need persistence later. We considered Memcached but it doesn't support persistence. Record this into our project memory."
AI: "Information recorded. Decision-15: Why Redis for caching — TTL support, potential persistence needs. Memcached rejected for lack of persistence."
That's it. The decision is now part of the project's permanent synthetic memory, searchable via RAG whenever you or your AI assistant need related context.
What Makes a Good Decision
Include three things:
- •What you chose — The specific option
- •Why you chose it — The reasoning
- •What you rejected — Alternatives considered
Good example
You: "We're going with PostgreSQL over MongoDB because we need relational integrity for user relationships. MongoDB's flexibility is nice but we'll use PostgreSQL's JSONB when we need it. Log this."
Weak example
You: "We chose PostgreSQL. Log it."
The first one will be useful in 6 months. The second won't.
Types of Decisions Worth Logging
Technology choices
You: "Let's use TypeScript because the type safety catches bugs at compile time and the IDE support is better. Log this decision."
Architecture decisions
You: "We're going with a monorepo structure because we have shared code between packages and it keeps everything in sync. Log it."
Implementation choices
You: "I'm bundling the core library into the build instead of using a symlink because the symlink breaks during packaging. Log this as a decision."
Rejection decisions
You: "We're NOT using MongoDB here because we need ACID transactions for payment processing. Log this."
How to Ask for Logging
The simplest way to use Continuity's synthetic memory is to talk to your AI assistant:
- •"Add this to our project memory"
- •"Record this decision"
- •"Save this for future context"
- •"Update our synthetic memory with this reasoning"
Be explicit about what to record:
You: "The decision is: Redis over Memcached for caching because of TTL and persistence. Save this with tags: caching, infrastructure."
Searching Your Project Memory
Before making new architectural choices, consult your synthetic memory via RAG:
You: "Search our project memory for anything about authentication."
AI: "I found 3 relevant decisions:
- •decision-8: JWT over sessions for stateless auth
- •decision-12: bcrypt for password hashing
- •decision-15: 15-minute token expiry for security"
You: "Good, so we're already using JWT. What was the original reasoning?"
AI: "Decision-8 from our memory says: JWT chosen for stateless authentication — no server-side session storage needed, works better with horizontal scaling."
Updating the Memory
When project directions change, supersede old information in the synthetic memory:
You: "Remember decision-8 about JWT? New compliance requirements mean we need to switch to server-side sessions. Record a new decision that supersedes it."
AI: "Recorded decision-23: Sessions over JWT for compliance requirements. Decision-8 marked as superseded in our project memory."
Tags and Organization
Ask for specific tags when logging:
You: "Log this decision with tags: database, postgresql, infrastructure"
Good tags:
- •Technology names:
postgresql,redis,typescript - •Areas:
authentication,api,frontend - •Types:
architecture,security,performance
Common Mistakes
Too vague
Bad: "Log that we're using Redis."
Better: "Log decision: Redis for caching because of built-in TTL and potential persistence needs. Rejected Memcached for lack of persistence."
No reasoning
Bad: "We chose React. Log it."
Better: "We chose React for the component model and ecosystem. Vue was considered but team has more React experience. Log this."
Logging everything
Don't log:
- •Code formatting preferences
- •Temporary debugging choices
- •Standard library usage
Do log:
- •Technology selections
- •Architecture patterns
- •Significant trade-offs
Workflow Tips
Start sessions with context
You: "Load the project decisions and tell me what we've decided about the database layer."
Check before deciding
You: "Before we pick a testing framework, are there any related decisions?"
Log immediately
Don't wait. Log decisions when you make them:
You: "Okay, we're going with Vitest. It's faster than Jest and has better TypeScript support. Log this decision."
Reference decisions
When discussing topics, ask about related decisions:
You: "We're working on auth. What decisions do we have about authentication and security?"
Key Takeaways
- •Be explicit — Ask your AI to record information into memory
- •Include reasoning — Why matters more than what
- •Mention alternatives — What you rejected adds critical context
- •Use tags — Makes RAG retrieval more accurate
- •Consult memory first — Search for related context before deciding
- •Record immediately — Don't wait until the reasoning is forgotten
If native Continuity tools are not mounted, use the repo-local files in .continuity/ instead of assuming the client can record directly into the synthetic memory.