Solutions

The Cookbook

The rest of this library explains concepts; this category ships WORKFLOWS. Each recipe is a complete implementation of one real workload, request by request, with actual payloads and the actual response fields your code branches on. Recipes stay at the wire level on purpose: every call is plain HTTP, so they translate to any language, and each step links to the chapter that explains the machinery it uses.

1The recipes#

Recipe	The workload
RAG, End to End	Retrieval-augmented generation over your own corpus: one-call cited answers, conversational sessions, or build-your-own from parts.
Invoice Automation, End to End	A scanned batch becomes validated records: upload, split, classify, extract, route on the review flag.
Compliance Redaction, End to End	PII is found, reviewed, destroyed, PROVEN absent, and the artifact archived with evidence.
A Support Assistant with Memory	A named agent with a skill, tools, and per-customer memory, consumed from an OpenAI SDK, tested like software.
An Archive That Answers	Documents become a searchable, filterable corpus: the retrieval foundation the RAG recipe consumes.

2Conventions every recipe uses#

Stated once here so the recipes stay lean:

Base URL and key: examples use $LMKIT_URL (for example http://localhost:5195) and send Authorization: Bearer $LMKIT_API_KEY. On a loopback workstation install, keyless local calls are accepted and the header can be dropped; Keys and Authentication covers minting real keys.
Upload once, chain by id. Files enter through one door and every later call references the id instead of re-sending bytes:

curl -s "$LMKIT_URL/lmkit/v1/files/upload" \
  -H "Authorization: Bearer $LMKIT_API_KEY" \
  -F "file=@batch.pdf"

{ "fileId": "d41f0c2a7e8b4b1f9d3a5c6e7f801234" }

Any endpoint then takes "input": "<fileId>" with "input_format": "FileIdentifier". Uploads expire on the server's retention clock (Where Data Lives), which is a feature: recipes never clean up what they forgot.

Long steps are jobs. Any task call may be forced asynchronous with the Prefer: respond-async header, returning 202 and a job_id to poll; a recipe step marked "job-friendly" is one you would run that way in production. The full contract, including the polling loop and retry discipline, is Errors, Retries, and Jobs.
Responses are truncated to what matters. Payloads shown omit fields the step does not branch on; the API reference is the complete shape, always.
Models resolve implicitly. No example pins model, so each capability uses the server's default slot; pin per request only when a recipe step says why.

3How to use a recipe#

Run it once against a test document with the exact payloads, watch each response, then adapt the schemas, taxonomies, and routing conditions to your domain: the STRUCTURE of each recipe (which calls, in which order, branching on which fields) is the part that transfers unchanged. When a step underperforms on your corpus, that is not a recipe problem but a measurement task: Measuring What Matters is the method, and the concept chapter linked from the step is where the levers live.

4Stated plainly#

Recipes are wire-level and complete: what to send, what comes back, what to branch on.
One upload, one id, many calls; long steps become jobs with one header.
Copy the structure, adapt the domain pieces, measure before believing.