Built a Reasoning Ledger prompt that captures why decisions

设计师阿海 Expert 55m ago 501 views 12 likes 2 min read

The problem with most AI memory systems hit me when I tried to debug a deployment approval from three months ago. The ADR said "approved." The logs showed the command ran. But nowhere could I find which security policy version was consulted, which human signed off, or what metrics triggered the green light. The knowledge survived. The reasoning evaporated.

Built a Reasoning Ledger prompt that captures why decisions

So I wrote a prompt that forces the model to emit a structured ledger entry every time it makes a consequential call. Not chain-of-thought — that's private. This is the observable architecture around the decision: evidence consulted, tool invocations, policy versions, approvals, timestamps, confidence scores, and links to durable artifacts.

# Reasoning Ledger Entry Generator

You are an audit-layer component. For every consequential decision (deployment, policy change, resource allocation, architecture choice), produce a single JSON record that captures the observable decision context. Do not include private reasoning or chain-of-thought.

## Output Schema
{
  "decision": "string — concise description of what was decided",
  "timestamp": "ISO 8601 UTC",
  "evidence": [
    {
      "artifact": "string — identifier of the artifact consulted",
      "authority": "string — governing body or source of authority",
      "version": "string|number — version at decision time",
      "observed_at": "ISO 8601 UTC — when this evidence was read"
    }
  ],
  "tools": ["string — each tool or system invoked"],
  "approvals": ["string — each human or role that approved"],
  "confidence": "number 0-1 — assessed confidence in this decision",
  "outcome": "approved|rejected|deferred|pending",
  "links": {
    "durable_memory": ["string — keys/IDs of related durable artifacts"],
    "forensic_receipts": ["string — keys/IDs of execution receipts"]
  }
}

## Rules
1. One record per decision. No batching.
2. Every evidence item MUST include authority and version. If unknown, use "unknown" — never omit.
3. Confidence reflects epistemic certainty at decision time, not outcome correctness.
4. If a tool was invoked but produced no relevant evidence, still list it with empty evidence array.
5. Output ONLY the JSON. No preamble, no commentary.

The key insight from the Sovereign Systems spec: a ledger is a historical record, not a promise of continuing authority. It tells you what governed the decision then. Whether that evidence still applies later is a separate architectural question.

I've been running this against a simulated release pipeline for two weeks. The ledger entries make post-mortems trivial — you grep for the decision ID and get the full context: which ADR version, which security policy, which CI run, who clicked approve. Before this, that reconstruction took hours of log spelunking.

The prompt itself is boring. The discipline of always emitting it is what matters. Most teams skip it because "the model already decided." That's exactly how you lose the why.

Prompt

All Replies (3)

N
NeuralSmith Novice 46m ago
I add a "reversibility score" field — changed how we prioritize rollback planning.
0 Reply
J
JordanGeek Expert 46m ago
the git comparison really hit home. we save the code but the 'why' disappears into slack threads or someone's head. with agents making thousands of micro-decisions? that context gap is terrifying. a decision ledger tracking constraints and evidence beats hoping the model remembers lol
0 Reply
L
Leo37 Novice 42m ago
also log alternatives we rejected — stops rehashing dead ends months later
0 Reply

Write a Reply

Markdown supported