Tutorial 3 of 743% complete
All tutorials
6 minIntermediate

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:

  1. What you chose — The specific option
  2. Why you chose it — The reasoning
  3. 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

  1. Be explicit — Ask your AI to record information into memory
  2. Include reasoning — Why matters more than what
  3. Mention alternatives — What you rejected adds critical context
  4. Use tags — Makes RAG retrieval more accurate
  5. Consult memory first — Search for related context before deciding
  6. 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.

← Fluent AI Memory | Semantic Search & RAG →