FREE · understand

Decision Memory

Preserve evidence-backed reasoning while it is still recoverable and flag the parts that need confirmation.

01 · THE SITUATION

“The client asks why refund approvals work this way, and the rationale is scattered across a pull request, ticket, and prompt change.”

Important rationale is scattered across pull requests, tickets, commits, and the memories of the delivery team.

REPOSITORY → ACTION → ARTIFACT → OUTCOME

02 · WHAT IT READS

acme-support-agent/fictional fixture

events/commit-7ac21f.jsonChanges and messages recorded during delivery.
events/pr-184.jsonReview discussion and implementation evidence.
events/ticket-ACME-91.jsonClient requirement and acceptance rationale.
repo/prompts/refund-triage.md + repo/config/routing.tomlThe shipped expression of the approval decision.

03 · WHAT THE FDE DOES

workbenchIllustrative planned interaction

Planned workflow — illustrative.

coding agentIllustrative planned interaction

Find evidence for the refund approval decision; cite each source and mark unsupported rationale for confirmation.

Planned coding-agent workflow — illustrative.

04 · WHAT GETS PRODUCED

outputs/decisions.jsonIllustrative fixture

Evidence-linked decision record

A decision card connecting the approval rule to its source evidence and confirmation state.

05 · WORK AVOIDED

You no longer reconstruct the decision from memory or old chat threads months later.

06 · CREDIBILITY BOUNDARY

When recoverable evidence does not explain the rationale, Decision Memory marks it unknown and asks a human to confirm it.

07 · NEXT STEP

Use the fictional repository demo to inspect the whole free-layer sequence before touching a real project.