Record a decision, lesson, or observation in the Ledger
ledger_entries_createRecords a memory entry. Every entry is a TITLE (summary: one short plain sentence) over a BODY (rationale: the detail, markdown welcome) — never put the detail in the title. Three kinds: decision — a change being made now; PRE-REGISTRATION IS THE POINT, so prediction (what we expect) must be written NOW, before any evidence exists, and never backfilled to match an outcome. lesson — a distilled belief the team already holds (lesson text required, no prediction). observation — a durable fact worth remembering (no prediction): something already true, never something planned. Ideas, pitches, backlog items, and upcoming work are NOT entries — a dated piece of work that carries out a decision is a plan item (ledger_plan_add on that decision), and a running list you keep across runs belongs in a Napkin doc or sheet. When a user states something durable about their business in conversation, offer to capture it as a lesson or observation. When a user shares MEETING NOTES, propose the decisions you find with ledger_entries_draft so they keep or drop each one in Ledger; use this tool for an entry they've asked you to record. Link the Compass pages the entry touches so future consult-before-acting finds it. May return needs_confirmation — summarize the entry and wait for approval.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | decision = a change with a pre-registered expectation; lesson = a belief arriving already settled; observation = a fact that is already true (not a plan, idea, or pitch). | decision |
| lesson | No | What we learned — required for kind=lesson, optional for kind=observation, forbidden on decisions (their lesson is written at settlement). | |
| summary | Yes | The entry's TITLE: one short plain sentence naming what we did (decision) or the fact itself (lesson, observation). Plain text, no markdown, at most 280 characters — e.g. "Newsletter moves to a biweekly cadence". Everything longer goes in rationale. | |
| rationale | No | The entry's BODY: the detail under the title — why, context, lists, steps. Markdown is fine here and renders as formatted text. | |
| workspace | No | Workspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys. | |
| approvalId | No | Approval id from a prior needs_confirmation envelope. | |
| prediction | No | Decisions ONLY. What we expect: a list of `claims` plus one shared `deadline`, or `freeform` for room decisions nothing can settle. A claim either REACHES a value (comparator + target, e.g. CTA clicks >= 400) or HOLDS one (`hold`, e.g. newsletter reads no more than 5% below the 28 days before this). Name every number the change is expected to move AND every number it shouldn't cost — a decision that claims only what it hopes will rise gets to pick its own evidence. Set `watch: true` on a number worth following that the decision isn't committing to. When the change aims at part of an event metric ("new users in Germany"), narrow the claim with `slice` ({ country: ["DE"] }) using label values from ledger_metrics_get — a claim on an event metric settles on the total counted since landing (reach) or events per day (hold). | |
| compassPageIds | No | Where — Compass page ids this decision touches. |