> ## 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.

# Meet Millwork

> Build with many models. Keep every run bounded and explainable.

**Composable intelligence, with verifiability.**

Every AI product starts simply. Then one model becomes several. Providers and
agent capabilities join the system. Teams want to move faster and keep control.
Soon, two questions matter: what came back, and what actually ran?

Millwork gives your business a verifiable AI strategy envelope: one operating
boundary for deciding what AI may do, measuring what happened, and improving
value with evidence.

Solver is the first product inside that envelope. It lets each task use an
eligible capability within the limits you set and leaves a receipt of what
happened.

Models, agent endpoints, and reusable skills can share the same boundaries and
run record. The pieces can change. The proof stays.

## Model supply is abundant. Strategy is the advantage.

Providers, clouds, gateways, and model releases will keep multiplying. The
lasting advantage is knowing how a business uses that supply: what may run,
what fits each task, what creates value, and what should change next.

Millwork sits above the changing supply. It turns available capabilities into a
governed, measurable system.

## Start with Solver

**Millwork is the platform. Solver is the first product.**

Your application sends the work and its boundaries. Solver selects from the
ready options your organization has made available, runs the chosen route, and
checks the outcome. When live work completes, its output is stored as the
result. The run's separate receipt records execution evidence.

Today, the private-preview journey begins with text models. Solver's execution
model also supports registered agent endpoints and reusable skills where those
capabilities are available to your organization.

<CardGroup cols={3}>
  <Card title="Compose" icon="blocks">
    Give models, agent endpoints, and reusable skills one execution model.
  </Card>

  <Card title="Govern" icon="sliders-horizontal">
    Put data, cost, time, and allowed actions beside the work.
  </Card>

  <Card title="Verify" icon="file-check-2">
    Keep the useful output and a separate record of how it happened.
  </Card>
</CardGroup>

## Where the leverage comes from

<CardGroup cols={2}>
  <Card title="Millwork model pool" icon="boxes">
    When a Millwork model appears in the live catalog, use it with your
    organization key. You do not need to configure the provider key. The run
    record keeps the source and billing owner clear.
  </Card>

  <Card title="Ranked routing" icon="list-ordered">
    Solver keeps options that are ready and permitted, then ranks the eligible
    set using the cost preference declared for the run.
  </Card>

  <Card title="Slice-level composition" icon="split">
    Solver's run and receipt formats are ready for work made of several parts.
    Dynamic slicing is coming. It is intended to divide one task into bounded
    slices, rank each slice, and keep them under one policy and receipt.
  </Card>

  <Card title="Evidence for better decisions" icon="chart-no-axes-combined">
    Receipts expose route, recorded usage, checks, and bounded actions so teams
    can improve their capability mix and operating rules over time.
  </Card>
</CardGroup>

## The compounding productivity axiom

Every capability a team adds should increase useful work faster than it
increases operational complexity.

When listed in the catalog, Millwork model access can make new supply easier to
add. Ranking chooses among eligible options. Dynamic slicing will let different
capabilities contribute to bounded parts of a task. Receipts will record which
combinations ran, their usage, and whether configured checks passed.

The same policy, lifecycle, and evidence model is reused each time. The system
can grow without asking the application team to rebuild control around every
new model, agent, or skill.

## Start small. Stay in control as you grow

Begin with one model and one public task. As the system grows, keep the same
way to govern what may run, measure what happened, and compare cost, quality,
and reliability using recorded cost, verifier outcomes, and terminal status.

## Output is one part of the answer

A response tells you what came back. The receipt shows the selected route and
checks. On deployment-bound model runs, it can also preserve requested,
resolved, and provider-reported model identity.

Solver keeps that evidence beside the run. The **result** contains the useful
output. The **receipt** records how the run happened while keeping the task and
output separate.

**Use the result. Keep the receipt.**

## One run, clearly handled

<Steps>
  <Step title="Make options available">
    Add a model from your live catalog or connect a provider account your
    organization already uses. The API calls a registered option an `arm`.
  </Step>

  <Step title="Send the work and its limits">
    Describe the outcome. Set the allowed data, maximum cost, maximum runtime,
    and any response permitted after a check.
  </Step>

  <Step title="Solver narrows the field">
    Solver keeps options that are ready and permitted for every declared data
    class, then selects from that eligible set.
  </Step>

  <Step title="Solver runs and checks">
    An eligible option is selected, the work is tracked to a final state, and
    the configured output check is applied.
  </Step>

  <Step title="Read the result and receipt">
    Use the output in your application. Keep the separate record of the route,
    recorded usage, checks, bounded actions, and, when available, model provenance.
  </Step>
</Steps>

## Made for the second day

Solver is for application and agent builders whose product has outgrown a
single model call, and for platform teams responsible for access, spend, and
run behavior across an organization.

Millwork becomes valuable when one model call is no longer enough and the
system still needs to stay explainable.

## Start with one public task

Run a text model through Solver, inspect the output, then read the receipt. The
difference is visible in one run.

<CardGroup cols={3}>
  <Card title="See how Solver works" icon="route" href="/overview/how-solver-works">
    Follow one task from limits to evidence.
  </Card>

  <Card title="Run a model" icon="play" href="/get-started/builder">
    Complete one public test task.
  </Card>

  <Card title="Evaluate fit" icon="clipboard-check" href="/get-started/evaluate">
    Compare the preview with your requirements.
  </Card>
</CardGroup>

<Note>
  Private-preview access is available to approved organizations.
  [See what is available today](/overview/availability).
</Note>