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

# How Solver works

> Follow a task from eligible capabilities to its result and receipt.

Imagine an application needs a short answer from any approved text model. The
application stays focused on the outcome. Solver handles provider readiness,
data eligibility, route selection, and the run record.

That is the boundary Solver provides.

## From intent to evidence

<Steps>
  <Step title="Make capabilities available">
    Your organization registers options Solver may select. The API calls each
    option an `arm`: a model, an agent endpoint, or a reusable skill.
  </Step>

  <Step title="Send a task and limits">
    Describe the outcome. Declare the allowed data, maximum cost, maximum
    runtime, routing preference, and any response allowed after a check.
  </Step>

  <Step title="Remove what cannot run">
    Solver keeps options that are ready and permitted for every declared data
    class.
  </Step>

  <Step title="Choose and run">
    Solver deterministically ranks the eligible options and starts the selected
    route. The run is asynchronous, so the application follows its status to a
    final outcome.
  </Step>

  <Step title="Check within the rules">
    Solver applies the selected verifier or its basic output check. Fallback or
    a repair proposal can happen only when the run explicitly allows it.
  </Step>

  <Step title="Return two useful records">
    When live work completes, the result contains the output for the application.
    The receipt records the route, recorded usage, check, and any bounded action.
    Task and output content stay separate.
  </Step>
</Steps>

## One unit of work

The docs call this a **run**. The API resource is an `execution`. They are the
same thing: one submitted, tracked unit of work.

The execution and receipt schemas are slice-shaped. The current public request
creates one placeholder slice for one clear objective and one run.

## What the application owns

Your application still owns the product decision: the task, the permitted
data, the budget, the runtime boundary, and whether a returned result is fit
for its users. Solver makes the execution path inspectable. Product judgment
stays with your application.

<CardGroup cols={2}>
  <Card title="Build the lifecycle" icon="clock-3" href="/guides/execution-lifecycle">
    Implement polling, final states, cancellation, and retention.
  </Card>

  <Card title="Understand the evidence" icon="file-check-2" href="/concepts/results-and-receipts">
    See what belongs in a result and what belongs in a receipt.
  </Card>
</CardGroup>