What is LADR?

Inference-time techniques — chain-of-thought, tree-of-thoughts, reflexion, self-consistency, and others — structure how a model reasons across multiple calls. LADR is the declarative language for writing those structures down.

LADR sits between the model and the application. The author declares a reasoning strategy in YAML; the runtime engine executes it, managing parallel dispatch, gating, jumps, memory, and budget enforcement.

What LADR is not:

• Not a general-purpose programming language. It is declarative, analyzable, and bounded. Every primitive is first-class and resource-accountable.
• Not a framework or library. It is a language, a runtime, a memory model, and a hosting platform.
• Not a model wrapper. It orchestrates calls to any model the caller supplies.

A LADR ladder makes the structure of a multi-step reasoning program explicit and machine-analyzable. Because a ladder is a declarative document rather than application code, it has properties that hand-rolled orchestration typically lacks:

• Inspectability. Every ladder is a YAML file. You can read it, diff it, version it, render it visually, lint it.
• Analyzability. The runtime knows what fields a step will read, what steps a jump can target, what slates a write will hit. Validation catches mistakes before a single LLM call runs.
• Publishability. A ladder is data, not code. It can be listed in a directory, forked, priced, embedded as structured data on a crawlable page.
• Composability. Cross-ladder jumps turn published ladders into building blocks. One ladder can hand off to another mid-execution.
• Bounded cost. Every execution runs under a spend cap. A published ladder cannot exceed its declared budget.

For a comparison to LangChain, DSPy, raw API calls, and prompted reasoning models, see LADR vs. Alternatives.

A minimal two-step ladder that drafts an answer and refines it:

name: Draft and Refine
allowedTargets:
  strategy: universal
exit: refine
knobs: {}

steps:
  - id: draft
    name: Draft
    fields:
      - { name: Question, type: text, from: input.context }
    systemPrompt: "Answer the question. Output only the answer."

  - id: refine
    name: Refine
    fields:
      - name: Draft
        type: ingest
        from: { stepId: draft, loopRef: current }
    systemPrompt: "Improve the given draft. Fix errors, tighten prose, preserve facts."

Execution trace:

1. Caller sends POST /v1/{author}/draft-and-refine/chat/completions with messages: [{role: "user", content: "..."}].
2. Runtime resolves input.context to the last user message.
3. draft runs: dispatches one LLM call with the assembled prompt. Output is stored as node 1 of step draft.
4. refine runs: ingests the draft output via the Draft field, dispatches one LLM call. Output is stored as node 1 of step refine.
5. Because exit: refine, the runtime returns the refine output to the caller in OpenAI Chat Completions format.

Two LLM calls. Total wall time is the sum of both call latencies (steps run sequentially unless explicitly parallelized). No gates, no slates, no knobs. This is the smallest useful ladder.

A ladder is a single YAML document with a fixed schema. The root object has ten fields, of which five are required.

The parser is strict: unknown top-level keys are rejected at parse time. Adding a new field is a grammar change, not a silent extension. Missing required fields fail parse. See Top-Level Config for the full reference.

LADR separates what the ladder does (declared in YAML) from how the runtime executes it. The author never writes imperative control flow. There are no loops, conditionals, or function calls in the YAML itself; instead, the author declares the structure and lets the runtime execute it.

This separation is what makes the budget guarantee enforceable. The runtime owns the loop, so the runtime can stop the loop. There is no escape hatch in the YAML that lets a ladder exceed its declared budget.

LADR is declarative and Turing-complete. Ladders can loop, recurse, jump, and rewrite themselves at runtime via dynamic steps. Termination is not statically guaranteed (halting problem; undecidable). Instead, every execution runs under four hard runtime ceilings:

The spend cap is the primary safety mechanism. A ladder can loop freely, but every LLM call costs money. The runtime kills execution the moment cumulative spend crosses the cap and returns the best-so-far output. This is what allows published ladders to be invoked safely — the runtime owns the loop, so the runtime can stop it.

A ladder can lower any ceiling (always safe) or raise it up to the platform max. The grammar places no restriction on how many times you jump or how deep you recurse; the ceilings bound the worst case at a declared dollar amount.

LADR's grammar is Turing-complete by design, paired with runtime caps. A more restricted grammar would force authors to flatten natural strategies into the runtime's primitive set; a Turing-complete grammar with runtime caps lets authors express a strategy and bound the worst case at a declared dollar amount.

Read these in order:

1. The LADR Mental Model. The six ideas that make every other concept intuitive.
2. Getting Started. Self-host a LADR stack in 5 minutes with Docker Compose.
3. Use Cases. Workload characteristics that justify a ladder.
4. LADR vs. Alternatives. Direct comparison to LangChain, DSPy, raw OpenAI calls, and reasoning models.
5. Adoption Phases. How teams typically roll out LADR internally.
6. Hello World. Build and run a ladder end-to-end.
7. Language Overview. Top-to-bottom tour of the grammar.
8. YAML Schema. Complete field reference.

If you learn better by example, start with Tutorials > Hello World and work through the Core Patterns. For a large composed example, see Examples > Reference Ladder: Crucible.