# How Arxo works

Arxo executes a pinned model against supplied facts and context. This page
follows one question through the system, then maps each stage to the part
of the documentation that covers it. For what Arxo is and is not, read
[What this is](/guide/what-is-this/); this page is about how one answer is
produced.

## One question, start to finish

The example is the one from the [Quickstart](/guide/quickstart/): an event
on 6 March 2026 starts a period of 14 calendar days — does the period end
on 20 March?

**The rule.** The canon `de.bgb.fristen` carries sections 187 and 188 of the
German Civil Code as a rule (labels omitted):

```law
@source(BGB_P187)
rule TagesfristEnde(f: Frist, e: Date, d: Quantity) strict {
    when frist_ereignis(f, e) and frist_dauer_tage(f, d);
    then frist_ende(f, add_business_days(e, d));
}
```

It reads: if a period `f` starts with an event on date `e` and lasts `d`
days, the period ends on the date `d` days after `e`, counted under the
deadline policy the call names. `@source` ties the rule to the pinned text
of section 187.

**Two facts and a question.** Your application supplies the facts
`frist_ereignis(frist, 2026-03-06)` and `frist_dauer_tage(frist, 14
calendar_day)`, the legal date and the policy `BGB_FRISTEN_TAG`, and asks
`truth` of `frist_ende(frist, 2026-03-20)`.

**The rule applies.** Both premises of `TagesfristEnde` are among the
facts, so the rule fires. The policy does not count the event day, so the
fourteenth day is 20 March, a Friday; no weekend or holiday moves it. The
engine concludes `frist_ende(frist, 2026-03-20)`.

**What comes back.** The answer document says `COMPUTED` (the evaluation
completed) and `TRUE_ONLY` (the claim is established). Its proof graph
links the conclusion to the rule `TagesfristEnde` and to the two facts, and
three hashes name the canon, the case and the result. Remove the duration
fact and the rule cannot fire: the answer becomes `NEITHER`, and `whyNot`
names the missing premise.

Nothing in this path reads the statute text at question time or guesses:
the rule was written and checked before the question was asked, and the
same inputs give the same bytes. The table below names who prepares each
part and where it is documented.

Start with the role you own: author the model, call it from an application or agent, or operate the service that exposes it.

## From a source to an answer

| Stage | What you prepare or receive | Where to start |
|---|---|---|
| Source and scope | A source edition, explicit coverage and modeling decisions | [Formalization Handbook](/handbook/) |
| Executable model | Rules, vocabulary, dependencies and scenarios | [Language walkthrough](/language/), [Corpus engineering](/corpus/) |
| Question and context | Facts, query kind, pinned model and time | [Quickstart](/guide/quickstart/), [SDK contracts](/build/sdk/) |
| Execution | The engine evaluates the supplied model and question | [Deployment overview](/operate/deployment-overview/) |
| Answer | Statuses, sources, proof and hashes, including refusals or missing support | [Read an answer](/guide/reading-an-answer/) |
| Review and reuse | Recorded checks, accepted scope and a versioned artifact | [Check and release a package](/author/check-and-release/) |

## Choose an access path

- **Application:** use the [TypeScript](/build/sdk/typescript/) or [Python SDK](/build/sdk/python/). The [deadline application](/build/) connects input validation, answers and saved captures.
- **Terminal:** use the [CLI](/cli/) to work with packages and cases.
- **Agent or editor:** connect through [MCP](/guide/mcp/). The [agent contract](/agent-engineering/agent-contract/) describes the caller's obligations.
- **Own service:** deploy [law serve](/operate/private-http-service/) or a [private MCP endpoint](/operate/private-mcp-server/).
- **Model inspection:** [LawQL](/lawql/) queries the structure of a model; its [boundary](/lawql/boundary/) explains when to ask the core instead.

These are access paths to documented contracts. They do not remove the need to pin versions, supply the relevant context or inspect the returned status.

## Checks happen at different stages

Authoring checks and scenarios examine a model. Semantic and technical reviews examine the candidate and its evidence. Application tests examine integration behavior. Deployment checks examine a running service. Agent evaluations examine the agent's behavior over scenarios.

Read the corresponding records: [Handbook reviews](/handbook/technical-review/), [application testing](/build/application/testing/), [deployment verification](/operate/verification-support-matrix/) and [agent evaluations](/agent-engineering/evaluations/). A published instruction is not proof that every platform or scenario has passed.

## Keep three boundaries visible

- **Handbook:** prepare and review one source model.
- **Corpus:** organize, distribute and maintain related packages.
- **Reference:** look up the exact meaning of an interface, form or document.

Choose [Author](/author/), [Build](/build/), [Agents](/agent-engineering/) or [Operate](/operate/) for the next result you want to obtain.