Documentation Index
Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt
Use this file to discover all available pages before exploring further.
02 — Architectural principles.
Layerup’s design is constrained by ten principles. They are not aspirational; they are the invariants the platform enforces by construction. Every later section is an implementation of one or more of them.2.1 Decision-centricity
The unit of value in the platform is not a model output, a chat turn, or an extracted field. It is a Decision: a typed verdict produced against a typed input, supported by typed evidence, optionally requiring approval, and resulting in zero or more typed Actions. Decisions are first-class objects in the Ontology, are versioned, are linkable, and are queryable. The platform is organised around producing, governing, and replaying Decisions.2.2 Deterministic effects, non-deterministic reasoning
Models are non-deterministic. Effects on the business cannot be. Layerup separates the two cleanly: reasoning steps may be probabilistic, but every effect that mutates a system of record is dispatched through a typed, idempotent, side-effect-bounded tool with a permission scope, a contract, and an audit trail. The “reasoning may be soft, the interface to reality is hard” rule is enforced by the Logic Plane.2.3 Governed agency
Agents do not have ambient authority. Every tool invocation is checked against the caller’s scopes, the object’s markings, the action’s policy, and the agent’s role. An agent has the minimum scope required for the run; tools that exceed scope are rejected at dispatch time, not at the system-of-record boundary. Agency is therefore scoped, evaluated and revocable, not implicit.2.4 Pre-commit reality arbitration
Before any effect commits, Layerup must reconcile the proposed effect with reality. That includes verifying that the target object still exists in the system of record at the expected version, that no concurrent reviewer has changed it, that the policy still applies, and that the action is idempotent against any prior commit. Reality arbitration runs after staging and before commit; it is what prevents “stale” agent decisions from silently overwriting human actions.2.5 Immutability and replayability
Every input the platform sees is content-addressed; every interpretation is recorded with its inputs, its model identity, its prompt revision, its tool calls, and its verdict. Given a (run id, ontology version) pair, the platform can reconstruct the exact reasoning and exact action graph that was produced — bit-for-bit on deterministic steps, and with preserved-seed reproducibility on non-deterministic steps. Immutability is not a feature; it is a precondition for governed agency.2.6 Ontology as contract
Every property, decision, action and audit event the platform produces is typed against the Insurance Ontology (§5). The ontology is versioned (§6). Tools and agents pin to ontology versions; clients of the platform see a stable contract; field-level lineage references the ontology version active at write-time. The ontology is not a schema convention — it is the contract between the platform’s planes.2.7 No rip and replace
Layerup never asks a tenant to migrate off a system of record. The platform is designed to ride above existing policy administration, claims, billing, document, registry and analytics systems. The cost of integration is paid by mappings (§8) and by tools (§9), not by data migration. Tenants can adopt the substrate workflow-by-workflow, never as a step-function.2.8 Asset separation: prompt, tool, retrieval, fine-tune
The four kinds of model “asset” are managed separately, version-pinned separately, evaluated separately, and governed separately. Prompts are content; tools are capability; retrieval corpora are data; fine-tunes are parameter changes. Conflating them is the root cause of most enterprise AI failure modes. Layerup makes the distinction structural.| Asset | Versioned | Eval gate | Provenance |
|---|---|---|---|
| Prompt | semver per role/agent | regression suite, adversarial probes | recorded against run; hashable |
| Tool | semver per signature | contract tests, side-effect tests, idempotency | recorded against run; permission set logged |
| Retrieval corpus | snapshot id | recall/precision over labelled set | EvidenceSpan back-references corpus snapshot |
| Fine-tune | model id + base + dataset hash | full benchmark suite + drift | model registry; promotion ladder |
2.9 Tenant isolation by construction
Tenant data, tenant prompts, tenant tools, tenant evals, tenant fine-tunes, tenant retrieval corpora and tenant audit chains are kept in physically separated stores. Cross-tenant transfer is impossible by routing, not by policy. Operator-mode access (Layerup staff) is gated by purpose-tagged break-glass and is itself audited into the tenant’s chain. No customer data is used to train any model unless that tenant has explicitly opted in for that specific dataset and that specific model lineage.2.10 Failure as a first-class state
Failure modes — model drift, schema mismatch, source-of-record downtime, low-confidence extraction, ambiguous evidence, conflicting evidence, policy contradictions, privilege escalation attempts, tool-contract violations — are not exceptions. Every one has a typed class, a detection rule, a containment path, a fallback path, and an audit signature (§21). The platform is engineered around the assumption that any plane can fail and that failure must be observable, contained, and reversible.These ten principles map one-to-one onto enforcement points in the architecture. §3 shows where each principle is enforced. §15–17 specify the security and audit machinery that backs them.