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.

​

04 — Core concepts & vocabulary.

Every term defined here is used throughout this documentation with the exact meaning given below. Each entry has an anchor so later sections can link back. Sections 5–22 assume this vocabulary.

​

4.1 Substrate & planes

substrate — The platform itself: the unified plane on which agents and humans operate. The substrate is not a workflow; workflows are configurations on top of it. plane — One of the eight horizontal layers shown in §3 (Experience, Reasoning, Logic, Ontology, Data, Model Gateway, Action, External SoR). Cross-cutting services (Identity, Audit, Telemetry) are not “planes” but observe every plane. system of record — An external authoritative system Layerup integrates with — policy administration, claims, billing, document, registry, ledger. Layerup never replaces a system of record.

​

4.2 Ontology & objects

object — A typed business entity in the Ontology — Policy, Claim, Submission, Quote, Decision, Action, AuditEvent, etc. (§5) property — A typed field on an object. Every property carries source, confidence, and version metadata (see provenance record). link — A typed relationship between objects (e.g. Claim.exposureOf → Policy). Links are themselves versioned and audited. marking — A non-bypassable label attached to data — e.g. pii.high, regulated.hipaa, tenant.eu-only. Markings propagate through derivations and gate access. purpose — A declared reason for accessing data, e.g. underwriting.review, claims.adjustment, quality.calibration. Tool calls and human reads must declare a purpose; the PDP (§16) checks compatibility with the data’s marking.

​

4.3 Decisions, actions & runs

Decision — A typed verdict produced by either an agent or a human reviewer against a typed input, with linked evidence and rationale. First-class object in the Ontology (§5). Action — A typed intent to mutate a system of record. Lives on the Action Plane (§14) with a state machine: proposed → staged → approved → committed → reverted/rejected/failed. AgentRun — One bounded execution of an agent against an input object. Has a unique runId, a scoped permission set, a token budget, a wall-clock budget, and a deterministic seed for replay. decision lineage — The graph of (input properties → tool calls → model outputs → verifier rulings → decision) for a Decision. Stored against the run; queryable. action lineage — The graph of (decision → proposed action → staged action → approval → committed effect → optional compensation) for an Action. model lineage — The pinned identity of every model used in a run — base id, fine-tune id, prompt revision, retrieval snapshot id, parameter set, region.

​

4.4 Reasoning & agents

agent — A versioned, role-scoped reasoning unit composed of: a planner, an executor, a verifier, a memory, a tool registry slice, and a model routing policy. Agents do not have ambient authority. planner — The component that turns a typed input + role into an ordered sequence (or DAG) of tool calls and reasoning steps. Output is a structured plan, not free text. executor — The component that schedules and dispatches the planner’s plan, applies retry policy, manages tool concurrency, and records every step. verifier — The component that runs typed assertions, schema checks, business-rule packs and adversarial probes against a candidate Decision before it is allowed to leave the run. memory — Run-scoped, object-pinned working memory; never cross-tenant. Long-term memory is via the Ontology, not the agent. handoff — The transition from agent execution to a human reviewer (or to a different agent). Handoffs are typed, reasoned, and themselves audited.

​

4.5 Models & assets

capability lane — A typed slot in the Model Gateway routing table — e.g. reasoning.long, reasoning.fast, embedding.text, vlm.document, ocr.handwriting. Lanes have approved models and SLO targets. approved model — A model entry in the registry that has cleared eval gates, security review, and tenant policy. Only approved models can be routed. no-train policy — The default: customer data is never used to train any model. Opt-in is per dataset, per model lineage, with explicit tenant authorization. prompt revision — A semver-tagged hash of a prompt asset. Pinned at agent definition. Recorded in model lineage. retrieval snapshot — An immutable snapshot of an indexed corpus used at inference time. Referenced by every EvidenceSpan it contributes to.

​

4.6 Evaluation & drift

eval harness — The continuous evaluation system. Runs golden, replay, adversarial and probe suites against any model/prompt/tool change. Produces gate verdicts. bench score — A normalised score across an evaluation suite, weighted by suite criticality. Used as a release gate threshold (§13). drift sigma (σ) — The standard-deviation distance of a current eval window from the trailing baseline window. Drift breaches σ thresholds trigger demotion. regression suite — A frozen labelled set of inputs and expected verdicts, run on every change. Failures block release.

​

4.7 Lineage & replay

provenance record — The metadata stored alongside every property: . EvidenceSpan — A typed citation: (documentId, byteRange | bbox | timestampRange, retrievalSnapshotId). EvidenceSpans link to the Property they support and the Decision they justify. content address — A SHA-256 over normalised input bytes. Used as the immutable handle for documents, attachments, prompt revisions, and retrieval snapshots. replay — Reconstruction of a run given (runId, ontologyVersion). Deterministic on tool calls (idempotent), seed-pinned on model calls, and limited by retention.

​

4.8 Identity & governance

RBAC — Role-based access control: capability scopes attached to roles, roles attached to principals. ABAC — Attribute-based access control: predicates over (principal, object, environment) attributes evaluated at decision time. PDP — Policy decision point. The component (§16) that evaluates every tool call against the caller’s scopes, the object’s marking, the action’s policy, and the agent’s role. PEP — Policy enforcement point. The dispatcher in front of every tool that calls the PDP and applies the verdict. break-glass — A purpose-tagged, MFA-stepped, time-limited grant of a normally-denied scope, used for incident response. Always recorded in the tenant audit chain.

​

4.9 Operations

idempotency key — A deterministic key that uniquely identifies the intent of an Action; replays of the same intent must commit at most once. Construction defined in §14. compensating action — A typed reversal of a previously committed Action, used when forward retry is unsafe. The pair (Action, CompensatingAction) is recorded together in lineage. SLO — Service-level objective: a measurable target (latency, success ratio, freshness) per surface. Defined in §20. RPO / RTO — Recovery point objective / recovery time objective. Per-tenant disaster recovery commitments (§19).