Skip to content

Lesson 31 — Assumptions ledger ​

Outcome ​

Ask capable agents to record important choices they made without escalating and surface those Claims in Review.

Why this comes now ​

The dangerous failure is often the missing Decision: the agent made an assumption silently. The ledger narrows where a reviewer should look without pretending to replace review.

Understand ​

The Assumptions Ledger is agent-authored and therefore a Claim. It should be captured at a natural Turn boundary through the same structured integration channel used for narration/escalation when available. Missing ledger capability must degrade honestly, not fabricate assumptions.

Build the real project ​

  1. Define a structured assumption entry: statement, reason/context, confidence/impact only if useful, related files/criteria optionally.
  2. Extend capable adapter prompt/tool contract.
  3. Store as Claims linked to Run/Turn/RawRef.
  4. Surface in Review beside diff/criteria/verification.
  5. Add fake scenarios with no assumptions, one assumption, and malformed output.
  6. Measure whether ledger is helpful or verbose in several real Tasks.

Completion gate ​

Review clearly labels assumptions as agent-authored. Absence is shown as unavailable/none, not filled by Forge.

Pitfalls to avoid ​

Do not treat the ledger as proof that all assumptions were disclosed. Do not block Done merely because a provider lacks the capability unless product evidence later justifies it.

References ​

Archived Forge ADR-0008: docs/archive/01-previous-forge-overview.md; UX_PRINCIPLES.md.

Checkpoint ​

Record whether the ledger changed your review behavior. This feature exists to improve human judgement, not to produce more text.

Forge is local-first. The docs are part of the product engineering system.