Handbook

Forge LCDL

Governed LLM tasks for Python systems. LCDL helps teams ship reviewable model calls: prompts and parsers stay versioned next to code, failures return typed errors instead of mystery JSON, and composition stays…

Updated 2026-07-06

Run your first governed task · Browse the task catalog

Second step: What is LCDL? or Install.

Choose your path

New to LCDL — What is LCDL?, Install, Tutorial 101
Building tasks — Tutorial 201, ContractSpec
Shipping to production — Adoption, Client API, Enterprise hub
Agents and editors — Agents hub, Examples
Playwright (read-only enterprise reads) — Architecture, Read-only policy, Messaging boundary, Outlook strategies, Teams strategies, SharePoint boundary, KA analysis consumer boundary, Testing, PDCA map

More routing: Choose your path.

Trust and boundaries

Data stays yours: keys, payloads, and retention live in your deployment; LCDL is not a hosted inference service.
Execution stays bounded: tasks run inside your process with gateways and models you configure.
Humans stay accountable: contracts and schemas document intent; failures return structured outcomes reviewers can trace.
Evidence stays inspectable: stable results and contract Markdown reduce “prompt archaeology” in logs.
Control stays composable: sequence, fallback-chain, and retry-style operators keep orchestration explicit.
Not a substitute for: certification, SLAs, threat modeling, or security review—see the Enterprise hub.

Proof points

Runnable offline examples, typed contracts packaged beside tasks, and Cursor / MCP guidance documented in-repo.

What LCDL gives you

Governed tasks — versioned task identifiers, human-readable contracts, JSON schemas, and typed success or failure results.
Schema-aware outputs — validation and optional repair hooks aligned with ContractSpec.
Deterministic orchestration — compose steps with operators instead of scattering branching logic across call sites.

How it works

Your application prepares a payload and selects a task plus version.
The runner loads the contract and executes against live or offline chat transport.
Responses are parsed and checked against the schema, yielding a typed success payload or a structured failure.

Visual walkthrough (same flow):

Governed task execution flow

How an application payload becomes a schema-validated, typed Ok or Err through the task runner.

App payload + task_id / versionCaller supplies input and selects the governed task version.
TaskRunner loads contract + chat transportRunner loads the contract and executes via configured chat transport.
Parse response + schema validate → Ok | ErrResponse is parsed and schema-checked into typed success or failure.

  App payload + task_id / version
        |
        v
  TaskRunner loads contract + chat transport
        |
        v
  Parse response + schema validate → Ok | Err

For a narrative tour with the same steps, open Getting started.

Enterprise boundary

LCDL ships contracts, runner, operators, and parsing primitives. Your deployment owns credentials, data custody, gateways, SLAs, and observability. Details: Enterprise hub.

Reference shortcuts

Topic	Link
Reference hub	reference/index.md
Client API	reference/CLIENT-API.md
ContractSpec	reference/CONTRACT-SPEC.md
Task catalog	reference/task-catalog.md