Get Started

How LACE is organized

Five peer product surfaces share one control plane. Understanding that shape explains most of the platform's behaviour.

The five surfaces

Pipelines are versioned, typed workflow graphs. Agents are tool-using definitions with deployments and channels. Apps are manifest-defined packages. Knowledge covers datasets, retrieval, search, and the knowledge graph. The Assistant is a tenant-scoped copilot over the same APIs everything else uses.

None of these is layered on top of another. They are peers over a shared control plane, which is why an agent can call a pipeline, a pipeline can write to the graph, and an app can ship all three.

The invariants

• Every resource and execution is tenant-scoped; roles resolve to named permission scopes.
• Model output proposes; deterministic services enforce permissions, validation, budgets, and approvals.
• Evidence is first-class: retrieval and graph assertions point back to document spans.
• Durable work uses persisted attempts, checkpoints, idempotency, and dead-letter handling.

Why the split matters

The second invariant is the one that 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.

Read Governance & security for how the enforcement layer is configured, or Deployment options for where it runs.