Skip to main content
The decision ledger is the single source of truth in Enfors. Every model call your AI workforce makes is reconstructed into one decision and recorded as a row in the ledger. Everything else — insights, Features, Pulse reports, the graph — is derived from it.

​
A hybrid record

Each ledger row combines two shapes of data:

Extracted columns

Scalar, indexed fields for fast filtering and aggregation — agent, session, outcome, confidence, cost, duration, and more.

JSONB audit trail

The full reconstructed detail — reasoning steps, findings, evidence, artifacts, and policy checks — stored as JSONB with GIN indexes.
This is why Enfors can both answer “show me every low-confidence decision over $1 last week” instantly and reconstruct exactly what happened inside any single decision.

​
Key fields

Large or sensitive payloads are scrubbed of PII and offloaded to object storage rather than kept inline. See Tenancy, Privacy & PII.

​
The defensible record

Beyond the scalar columns, each decision’s JSONB carries the structured justification that makes it defensible — the answer when a decision is challenged:
The reversal_condition is what lets a reviewer ask “what would it have taken to decide differently?” and get a concrete answer — not a re-run of the whole session.
Each decision carries a vector embedding, enabling semantic similarity search — “find decisions like this one” — across the ledger. This powers the search_similar_decisions MCP tool.

​
How it relates to everything else

  • Agents and sessions are computed by aggregating ledger rows. See Agents, Sessions & Decisions.
  • The graph mirrors each decision’s internal structure for traversal. See Evidence & the Logic Trace.
  • Insights, Features, and Pulse are all derived from ledger activity over time.
The ledger uses the modern outcome vocabulary (outcome_class / outcome_summary). An older final_verdict field is retained for backward compatibility but is deprecated — prefer outcome_class.