Get Started
How LACE is organized
Five peer product surfaces share one tenant-scoped control plane. Understanding that shape explains most of the platform's behaviour.
The five surfaces — peers, not layers
| Surface | What it is | Example |
|---|---|---|
| Pipelines | Versioned, typed workflow graphs with checkpoints, retries, DLQ | Extraction pipeline that populates the KG |
| Agents | Tool-using definitions with deployments and channels; real agentic loops | Intake Triage agent on web + email |
| Apps | Manifest-defined packages bundling routes, tools, agents, pipelines, data, UI | Grid Ops Console sidecar |
| Knowledge | Datasets, connectors, ingest, retrieval, search, KG, schema packs | Dataset alpenglow-ops + warranty.v2 |
| Assistant | Tenant-scoped copilot over the same APIs — OBO identity, operation catalog | LACE Assistant answering with citations |
None of these is layered on top of another. They are peers over a shared control plane. That is why an agent can call a pipeline, a pipeline can write to the graph, and an app can ship all three. The control plane provides auth, tenancy, policy, budgets, audit, and observability once, for all five.
The invariants — what LACE enforces that an LLM never decides
- Every resource and execution is tenant-scoped — roles resolve to named permission scopes; tenancy is a bound store context (
bind_store_tenant), not a header. - Model output proposes; deterministic services enforce. A model that decides to escalate still goes through the approval gate; a model that invents a tool still needs it in the capability allow-list.
- Evidence is first-class. Retrieval and KG assertions point back to document spans (document / block / char offsets) — citations, not summaries.
- Durable work uses persisted attempts, checkpoints, idempotency, and DLQ. A pipeline or agent turn that crashes resumes from its checkpoint; an agent that would exceed its budget stops before billing.
Why the split matters
The second invariant does most of the work. A language model in LACE never decides whether an action is permitted — it proposes an action, and a deterministic service accepts or rejects it against policy the model cannot see or influence. That is what makes the audit trail meaningful: the record shows what was proposed, what was enforced, and why, rather than a transcript of a model asserting it was being careful.
The same split is why the SDK boundary matters: apps import only lace_app_sdk, so the platform can enforce governance without trusting generated code to do it.
Where to go from here
- Architecture overview — control plane, app framework, execution, knowledge stack, platform data.
- Governance & security — scopes, ACLs, budgets, approvals, audit.
- Deployment options — managed cloud, VPC, on-prem, air-gapped.
- REST API & SDKs — the same control plane you see in the console is the /v1 API.