Redeo Docs
DocsLADR / Glossary

Schema

Glossary

Glossary

Authoritative definitions for every LADR + Redeo term. Mirrors Appendix A of the master spec.

Core language terms

TermDefinition
LADRLanguage for Adaptive Deliberation and Reasoning. The declarative DSL for writing ladders. Config files use the .ladr extension.
LadderA complete reasoning program; a pipeline configuration written in LADR. Atomic unit a user authors, publishes, runs, and shares. Identified publicly as @author/name.
StepExecution unit within a ladder. Type: normal, sequential, or group. Has fields, system prompt, optional gates, jumps, recursion, slate operations.
NodeA single LLM call within a step. nodes: 5 fans out into 5 calls (parallel for normal, sequential for sequential).
FieldA named prompt slot with a typed source. Rendered into the LLM call as Name: <value>. Types: text, ingest, multi_ingest, nodeInfo, knobInfo, slateRead, manifest.
KnobCaller-tunable control declared at config time. Adjusted at call time. Categorized as loops, recursion, nodes, or generic; UI input is slider or numerical.
LoopA full iteration of the step sequence. Multi-loop ladders run the sequence N times; later loops can read prior loops via loopRef.
RecursionA step spawning a child instance of the same ladder; the child result bubbles up. Bounded by maxRecursion.
GroupStep type containing sibling steps that run in parallel. Cannot be nested.
GateThe if block; typed predicate evaluated per node, with then/else actions. Eight condition kinds are supported.
JumpAction under then/else that repositions the engine's mutable cursor to another step (within-ladder) or another ladder (cross-ladder handoff).
Dynamic stepA step whose config (systemPrompt/fields/nodes, and optionally if/jump/recursion/retrieve) is loaded at runtime from a declared source rather than declared statically. The primitive that enables self-improvement.
ManifestRuntime index of everything readable at a given step (inputs, knobs, prior step outputs, slate state). Used to inform dynamic step generation.

Memory terms

TermDefinition
SlatePersistent memory store; folders of .md files with metatags. Survives across ladder invocations. Per-user by default.
FolderNamed container inside a slate. Has its own token budget, access policy, eviction policy, and metatag schema.
FilePlain-text (typically Markdown) inside a folder. Can be prose OR structured JSON (arbitrary depth).
MetatagNamed, typed value attached to a file (or auto-maintained at folder level). The universal primitive for describing and retrieving file data.
System metatagEngine-maintained metatag: index, tree, created, modified, size. Always present, read-only.
User metatagAuthor-declared metatag with type (string, string[], number, boolean, object). Writable via slateWrite.
Effective schemaThe union of folder-level and file-level metatags for a specific file. File-level wins on conflicts.
slateReadField source that reads file contents, a metatag value, or a system metatag from a slate. Shape: { slate, folder, file?, metatag?, depth? }.
slateWriteStep-level directive that extracts JSON from LLM output, validates against a schema, and writes if valid. No-match is no-op, not error.
Gated writeWrite action under if/then that writes unconditionally on gate match (no schema extraction).
mergeByKeyWrite policy that maintains a structured JSON store by merging entries on a key field inside the JSON objects.
retrieve:Step capability for on-demand bounded fetch. The LLM sees the slate index, requests specific files via JSON, and the engine fetches them within a maxRounds loop.
Cold-start retrievalThe problem of knowing what to read; solved by index/tree metatags + retrieve: capability.

Runtime + safety terms

TermDefinition
RuntimeThe execution layer that loads a ladder config and runs it. Walks the steps array, dispatches LLM calls, evaluates gates, persists slates, enforces ceilings.
GatewayOpenAI-compatible API surface for ladder execution. Accepts POST /v1/{author}/{ladder}/chat/completions and returns standard chat completion responses.
APIInternal Redeo API for auth, billing, providers, library, studio, and account management.
WorkerBackground execution layer for asynchronous pipeline jobs.
HopUnit of execution count. Every step execution counts. Jumps don't increment separately; the step they lead to does. Bounded by maxHops.
Spend capThe primary safety net. Hard dollar ceiling per execution. Default $5; platform max $50. Configurable per ladder via executionBudget.maxSpend.
Hop ceilingHard cap on total hops (loops + jumps + recursion). Default 200; platform max 10,000.
LLM-call ceilingHard cap on total LLM API calls. Default 500; platform max 5,000.
Recursion ceilingHard cap on recursion depth. Default 5; platform max 20.
Runtime-cap safety modelLADR's grammar is Turing-complete (declarative but unbounded). Safety is enforced at runtime via spend caps and resource ceilings, not via grammar restrictions.
Resource ceiling exhaustionWhen a runtime ceiling is hit mid-execution. Engine gracefully exits with best-so-far output when a ceiling is hit. Treated as normal termination, not error.

Product + platform terms

TermDefinition
FoundryThe editor for ladders. Browser-based at foundry.redeo.io; an Electron desktop app is planned.
StudioThe consumer experience for running ladders; live timeline, per-step output inspection, threaded conversations. Browser-based at studio.redeo.io (or via /studio on the main app).
LibraryThe public directory of published ladders. Browser-based at library.redeo.io (or via /library on the main app).
CrucibleReference ladder composing ToT + reflexion + self-refine + self-consistency + memory.
Visibility tierOne of: public-free (AGPL, full config disclosed), public-paid (creator-priced), hosted-private (callable via API, not listed), enterprise-local-licensed (deployed to customer sites), local (self-hosted only).
Ladder IDCanonical identifier: @author/name for published, local/name for self-hosted. Version suffix: @author/name@v3. URL form: library.redeo.io/@author/name.
Corpus thesisThe strategy where publishing measured reasoning strategies creates a training-corpus asset as a side effect. Product → usage data → corpus → research flywheel.