The “why” archive — decision memory

“Why is auth done this weird way?” finally has an answer.

error_outline

Without memory

Code records what you built; nothing records why. Six months later the context behind an architectural choice is gone — so teams either cargo-cult the old decision or unknowingly re-litigate it, and agents confidently “fix” things that were deliberate.

check_circle

With Rekall

Rekall keeps a dedicated decision store: structured, bi-temporal records of each decision, the alternatives considered, why they were rejected, what later superseded it, and how it actually turned out. Humans and agents can trace the why-chain behind any part of the system.

How it works

Decisions are captured ambiently

The extraction pipeline spots decisions in your working sessions and records them with their context and alternatives — no ceremony.

Typed edges link causes to effects

Decisions connect to the entities, evidence, and prior decisions they touch through typed edges — influenced, based on, superseded by. Vector-only memory has no concept of this: “is this still current?” resolves along the supersession chain instead of being guessed.

Outcomes close the loop

Record how a decision worked out, and future recall includes the track record — your team stops repeating the failures.

See it in action

Tracing a why-chain

> why is auth done with first-party JWTs
  instead of provider sessions?

rekall.recall_decisions("auth token strategy")

→ Decision (Mar 12): mint a first-party HS256 JWT
  from the identity-provider session
  Considered: pass provider tokens through
    (rejected — couples every service to the provider)
  Considered: session cookies on the API
    (rejected — breaks MCP + CLI clients)
  Outcome (Apr 02): shipped — zero auth incidents since