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

# The Capsule (OEP)

> Orkestral's proprietary technology: the premium model compiles intent into a compact, verifiable unit the local model executes with high fidelity.

The **Capsule** is the layer between expensive thinking and cheap execution. It is what
makes Orkestral different from an AI chat or an editor: the premium model does not execute
everything, it **compiles** each task into a Capsule, and the local model (the
[Forge](/en/forge)) executes that Capsule with far higher fidelity than it would alone.

The internal protocol that defines this format is called **OEP** (Orkestral Execution
Protocol).

## The problem it solves

A small local model is fast and free, but on its own it:

* cannot understand a large task;
* needs very well filtered context;
* needs small, crystal clear instructions.

A premium model understands everything, but is expensive to run on every file. The Capsule
combines the best of both: the premium spends tokens **once** to compile; the local model
executes **cheaply and as many times as needed**.

## What is inside a Capsule

A Capsule is OPERATIONAL compression, not a summary. Instead of repeated prose, it carries
structure the executor consumes without re-inferring:

<CardGroup cols={2}>
  <Card title="Distilled intent" icon="bullseye">
    The goal in one line, plus the canonical terms of the task.
  </Card>

  <Card title="Exact target" icon="crosshairs">
    The file and the region (symbol or lines) to touch, not the whole file.
  </Card>

  <Card title="Verifiable contract" icon="circle-check">
    The done criterion as predicates the machine checks (symbol present, imports intact, no shrinkage).
  </Card>

  <Card title="Scope" icon="lock">
    What it may and may not touch (anti out of scope), enforced for real.
  </Card>

  <Card title="Project patterns" icon="ruler-combined">
    Your repository's conventions, distilled into short rules.
  </Card>

  <Card title="Learned pitfalls" icon="triangle-exclamation">
    What already went wrong in this repository, so the model does not repeat it.
  </Card>
</CardGroup>

## The cycle: understand, compact, execute, validate, learn

```mermaid theme={null}
flowchart LR
    A["You describe<br/>the request"] --> B["Premium understands<br/>the project"]
    B --> C["Compacts into<br/>a Capsule"]
    C --> D["Local Forge<br/>executes"]
    D --> E["Validates the<br/>contract"]
    E -->|passed| F["Done"]
    E -->|failed| G["Becomes a pitfall<br/>and retries"]
    G --> D
    G -.->|persists| H["Escalates to<br/>premium"]
```

<Steps>
  <Step title="Understands">
    The premium model reads the request and the project, helped by the [knowledge base](/en/knowledge-base).
  </Step>

  <Step title="Compacts">
    It distills everything into a Capsule: target, contract, patterns, pitfalls and one accepted-edit exemplar.
  </Step>

  <Step title="Executes">
    The Forge applies the change locally, fast and with zero API cost.
  </Step>

  <Step title="Validates">
    The contract is checked for real. For frontend, the build runs. See [proven delivery](/en/verified-delivery).
  </Step>

  <Step title="Learns">
    Every failure becomes a pitfall and every win becomes an exemplar. The next Capsule comes out better on your project.
  </Step>
</Steps>

## How it learns from your project

The Capsule is fed by two memories that grow with every run:

* **RAG of wins.** Edits that passed become exemplars; the next similar task gets the right example.
* **RAG of errors (pitfalls).** Each failure (anchor that did not match, dropped import, broken build) becomes a short "when, avoid, because" rule. The same error converges instead of being re-discovered.

<Note>
  By design, the Capsule's core is **deterministic**: it is assembled from signals the
  pipeline already produces, so it delivers value even before the premium refines the
  free-text fields. The premium raises quality, it does not create the structure.
</Note>

## How you use it

You do not build the Capsule by hand. The flow is automatic:

1. You [chat](/en/chat) and describe what you want.
2. The orchestrator writes a rich plan in the [knowledge base](/en/knowledge-base) and points the [issue](/en/issues) at it.
3. At execution time, the system compiles the Capsule from the plan, the code and the error memory.
4. You follow it in the [logs and savings](/en/observability): how much the Forge resolved locally and how much premium it avoided.

## See also

<CardGroup cols={2}>
  <Card title="The Forge" icon="microchip" href="/en/forge">
    The local model that executes the Capsule for free.
  </Card>

  <Card title="Proven delivery" icon="shield-check" href="/en/verified-delivery">
    The gates that confirm the Capsule was actually fulfilled.
  </Card>
</CardGroup>