decision-logger

# Decision Logger

Two-layer memory system for executive decisions. Layer 1 stores everything discussed. Layer 2 stores only what the founder approved. Future sessions read Layer 2 only -- this prevents hallucinated consensus from past debates bleeding into new deliberations.

## Keywords

decision log, memory, approved decisions, action items, board minutes, conflict detection, DO_NOT_RESURFACE, decision history, overdue, supersession, decision search, decision tracking, accountability

---

## Two-Layer Architecture

### Why Two Layers?

Single-layer decision logs create a dangerous problem: agents read old debates, rejected proposals, and discarded ideas, then treat them as context for new decisions. This causes "hallucinated consensus" where rejected ideas gradually become accepted through repetition.

The two-layer system prevents this by strictly separating raw discussion from approved decisions.

### Layer Architecture

```
Layer 1: Raw Transcripts (NEVER auto-loaded)
  Location: memory/board-meetings/YYYY-MM-DD-raw.md
  Contains: Full deliberation, all perspectives, rejected arguments
  Loaded: Only on explicit founder request
  Retention: Active 90 days, then archived

Layer 2: Approved Decisions (AUTO-LOADED every session)
  Location: memory/board-meetings/decisions.md
  Contains: Only founder-approved decisions and action items
  Loaded: Automatically at start of every board meeting (Phase 1)
  Mutation: Append-only. Decisions are never deleted, only superseded.
```

### Layer Interaction Rules

| Rule | Rationale |
|------|-----------|
| Layer 2 is append-only | Preserves complete decision history |
| Layer 1 is never auto-loaded | Prevents hallucinated consensus |
| Only Chief of Staff writes to Layer 2 | Single point of control |
| Agents never write directly | All writes go through Chief of Staff after founder approval |
| Superseded decisions stay in Layer 2 | History is the record; nothing is deleted |

---

## Decision Entry Format

### Standard Decision Record

```markdown
## [YYYY-MM-DD] -- [DECISION TITLE]

**Decision:** [One clear statement of what was decided]
**Context:** [1-2 sentences on why this decision was needed]
**Owner:** [One person or role accountable for execution]
**Deadline:** [YYYY-MM-DD]
**Review Date:** [YYYY-MM-DD]
**Confidence:** [High / Medium / Low]
**Rationale:** [Why this option over alternatives, 1-2 sentences]

**User Override:** [If founder changed agent recommendation -- what and why]

**Rejected Alternatives:**
- [Proposal] -- [reason for rejection] [DO_NOT_RESURFACE]
- [Proposal] -- [reason for rejection]

**Action Items:**
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]

**Dependencies:** [Other decisions this depends on]
**Supersedes:** [DATE of previous decision on same topic, if any]
**Superseded by:** [Filled retroactively if overridden later]
**Raw transcript:** memory/board-meetings/[DATE]-raw.md
**Tags:** [topic tags for search -- e.g., pricing, hiring, market-entry]
```

### Completed Action Item Format

```markdown
- [x] [Action] -- Owner: [name] -- Completed: [YYYY-MM-DD] -- Result: [one sentence]
```

---

## Conflict Detection System

Before logging any new decision, the system checks for three types of conflicts.

### Conflict Type 1: DO_NOT_RESURFACE Violation

A new decision matches a previously rejected proposal.

```
Detection: New proposal text similarity > 70% to a rejected proposal

Response:
  BLOCKED: "[Proposal]" was rejected on [DATE].
  Reason: [original rejection reason]

  To reopen: Founder must explicitly say "reopen [topic] from [DATE]"
  This cannot be overridden by agents.
```

### Conflict Type 2: Topic Contradiction

Two active decisions on the same topic reach different conclusions.

```
Detection: Same tags + contradictory conclusions

Response:
  DECISION CONFLICT DETECTED

  Active decision (older): [DATE] -- [decision text]
  New decision: [DATE] -- [decision text]

  These decisions contradict each other.

  Options:
  1. Supersede old decision (new replaces old)
  2. Merge decisions (reconcile the conflict)
  3. Defer to founder (present both, let founder choose)
```

### Conflict Type 3: Owner Conflict

Same action assigned to different people in different decisions.

```
Detection: Same action description, different owners

Response:
  OWNER CONFLICT

  Action: "[action text]"
  Decision 1 ([DATE]): Owner = [Person A]
  Decision 2 ([DATE]): Owner = [Person B]

  Resolve: Which owner is correct?
```

### Conflict Resolution Decision Tree

```
START: Conflict detected
  |
  v
[What type of conflict?]
  |
  +-- DO_NOT_RESURFACE --> Block automatically. Only founder can reopen.
  |
  +-- Topic contradiction --> [Is the new decision from a board meeting?]
  |                           |
  |                           +-- YES --> Supersede old by default (board > individual)
  |                           +-- NO  --> Present both to founder for resolution
  |
  +-- Owner conflict --> [Which decision is more recent?]
                         |
                         +-- Flag to founder with both dates
                         +-- Default to more recent unless founder overrides
```

---

## Decision Lifecycle

### States

```
PROPOSED --> APPROVED --> ACTIVE --> [COMPLETED | SUPERSEDED | EXPIRED]

PROPOSED:    Agent synthesis presented to founder
APPROVED:    Founder explicitly approved
ACTIVE:      Being executed, action items in progress
COMPLETED:   All action items done, review confirmed success
SUPERSEDED:  New decision replaced this one
EXPIRED:     Review date passed without renewal
```

### State Transitions

| From | To | Trigger | Who |
|------|----|---------|-----|
| Proposed | Approved | Founder says "yes" or "approve" | Founder |
| Proposed | Rejected | Founder says "no" or "reject" | Founder |
| Approved | Active | Action items begin execution | Automatic |
| Active | Completed | All action items marked done | Chief of Staff |
| A