> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enfors.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Outcomes & Decision Intent

> How Enfors classifies what a decision achieved and what kind of work it was.

Two controlled dimensions make decisions comparable across agents and time: **what the
decision achieved** (its outcome) and **what kind of work it was** (its intent).

## Outcome

Every decision is classified into a single **outcome class** — the canonical
description of its result. The outcome class is the primary group-by and filter
dimension across the product, and it's constrained at the database level to a fixed set
of values.

Alongside it, `outcome_summary` carries free-text colour — *what the agent actually
did* — and `decision_title` is a short, scannable 3–5 word headline.

The controlled values are:

| `outcome_class` | Meaning                                                    |
| --------------- | ---------------------------------------------------------- |
| `success`       | The decision achieved its goal.                            |
| `partial`       | Partially achieved — some goals met, others not.           |
| `failure`       | Did not achieve its goal.                                  |
| `blocked`       | Could not proceed (missing input, dependency, permission). |
| `pending`       | Not yet resolved.                                          |
| `needs_review`  | Flagged for human review.                                  |
| `error`         | An execution error prevented a clean outcome.              |
| `unknown`       | Could not be classified.                                   |

<Note>
  **Vocabulary note.** Enfors standardized its outcome terminology across the whole
  product. The current canonical field is `outcome_class` (plus `outcome_summary`). The
  older `final_verdict` / `verdict_label` fields (`PASS | REJECT | INCONCLUSIVE | PARTIAL`)
  are **deprecated** and derived from `outcome_class` for backward compatibility only.
  New integrations should read `outcome_class`.
</Note>

## Decision intent (work type)

Each decision is also classified by **intent** — the type of work it represents — with
a `decision_intent_confidence` score. Intent is what lets Enfors answer *where the effort
actually went*:

| `decision_intent`    | Work type                                         |
| -------------------- | ------------------------------------------------- |
| `development`        | Building features or functionality.               |
| `bug_fix`            | Diagnosing and fixing defects.                    |
| `research`           | Exploration, investigation, analysis.             |
| `product_management` | Planning, prioritization, requirements.           |
| `auditing_review`    | Reviewing, auditing, or evaluating work.          |
| `coordination`       | Orchestration and hand-offs across people/agents. |
| `other`              | Anything not covered above.                       |

This classification, weighted by real decisions, powers the effort-mix breakdown in
[Pulse reports](/concepts/pulse-reports) and the cost-per-work-type view in the
[Leader lens](/using/leader-lens).

<Frame caption="Effort breakdown by work type in a Pulse briefing">
  <img src="https://mintcdn.com/enfors/EStKoMAmv9k4MqOd/images/effort-by-work-type.svg?fit=max&auto=format&n=EStKoMAmv9k4MqOd&q=85&s=516802d1fb623750dd6ce3fc960a72a5" alt="Effort-by-work-type breakdown" width="1200" height="750" data-path="images/effort-by-work-type.svg" />
</Frame>

## Why it matters

Because outcome and intent are structured (not free text), you can:

* compare success rates across agents and people,
* attribute cost to the kind of work that produced it,
* and detect when an agent's outcome mix **drifts** over time
  ([Insights & Drift Detection](/concepts/insights-and-drift)).

<Info>
  Decisions captured before these fields existed carry `NULL` and surface as
  "unclassified." Enfors backfills where possible.
</Info>