# Addendum — Where lagstyr Fits

| | |
|---|---|
| **Status** | Vendor addendum — deliberately **not** part of the reference model |
| **Product status** | Private development — not currently available for installation; no supported release exists |
| **Reviewed** | 12 September 2026 |
| **Companion docs** | 00 Overview · 01 Target Architecture · 02 Implementation Plan · 03 Data, Security & AI Governance · 04 Benefits Realisation |
| **Publisher** | lagstyr — VSPRY INTERNATIONAL PTY LIMITED, Brisbane, Australia |

> The five guide documents are a vendor-neutral reference model. Nothing in them
> requires lagstyr, and this addendum is published separately so the model stays
> that way. Read it if you want to know where our product sits in the plan the
> guide describes — and, just as importantly, where it does not.

## 1. The one-sentence version

The guide tells an organisation to put a deterministic control layer between AI
reasoning and business transactions; **Lagstyr is being built as the authority,
approval, and audit spine of that layer, intended for company-controlled
infrastructure instead of assembly from parts.** Connector verification,
permission-aware retrieval of your own documents, and the operating registers
still depend on the installed workflow and the systems it connects to.

Status labels below use the same vocabulary as lagstyr.com: **built & lab-tested**
means the capability works end to end on synthetic data we control; **built, not
yet proven live** means it exists in code but its decisive proof needs a real
installation, tenant, or connection. Neither means available.

## 2. Architectural mapping

Document 01 defines a vendor-neutral six-plane programme architecture and requires,
before any custom write-enabled workflow reaches production: a typed action broker,
a policy decision point, authenticated approval surfaces, explicit identity for
every actor, and reconstructable audit. Lagstyr's distinct five-plane product
architecture — Identity, Record, Projection, Action, and Governance — maps to those
requirements as follows:

| Guide concept (Doc 01) | lagstyr equivalent | Status |
|---|---|---|
| Typed action broker / transaction boundary | The governed write loop: typed proposal → authority derivation → approval → atomic apply → event, executed once through the system that owns the transaction, with a stable idempotency key, receipt, and read-back | Built & lab-tested for the loop; read-back and compensation against a real outside system are built, not yet proven live |
| Policy decision point | Mandate and grant checking — legal entity, actor, action class, value, currency, time window, exceptions, conflicts — enforced in the database and locked until the decision commits. An AuthZEN enforcement point can also consult *your* policy engine; its permit can never override a local refusal | Built & lab-tested locally; the connection to a customer policy engine is built, not yet proven live |
| Approval surface (T2) | Authenticated approve/reject with the frozen proposal, evidence, conflicts, limits, route, and an explicit list of any missing evidence; every governed action's approval route is checked for readiness before first use | Built & lab-tested |
| Logical agent / workload / delegated identity | Distinct identities for the initiating human, the logical agent, and the executing workload; agents hold no standing or inherited human authority. Sign-in through your identity provider, SCIM provisioning, and workload identity from Entra, Okta, or SPIFFE are implemented | Built & lab-tested for local identity; enterprise identity connections are built, not yet proven live |
| Workflow/agent register and audit events | Typed records for mandates, action classes, decisions, approvals, obligations, agent actions, effect receipts, AI systems, impact assessments, and exceptions; an append-only event history chained daily; any decision exportable as a checksummed evidence pack | Built & lab-tested; the installation still has to populate and review its own registers |
| Governed, permission-aware knowledge (Doc 01 P4) | One governed memory with source provenance, classification containment, and page-level record of how each document was read; full-text search is standard, semantic search is a candidate profile not yet qualified for release | Built & lab-tested; permission-correct retrieval of *your* documents needs your access lists configured first |
| Control plane vs execution plane separation | `write_kernel`: changes to the operating spine — prompts, models, skills, policy, authority — always require independent approval; the proposer cannot sign off, and no agent can supply the evidence that clears its own gate | Built & lab-tested |

The guide's build-versus-buy position (P13: *buy capability; build thin control
and differentiation*) is the practical point: an organisation reaching Phase 2
must otherwise assemble this machinery itself.

## 3. Phase mapping

| Guide phase (Doc 02) | What the organisation is doing | lagstyr's role |
|---|---|---|
| **Phase 0 — control & evidence** | Inventory, identity hygiene, baselines, registers | Light. Observe/shadow mode records how work actually happens; typed records give the registers a governed home |
| **Phase 1 — governed augmentation (T0/T1)** | Assistants, curated knowledge, drafts a person commits | Assembles cross-system context with provenance; records the case, decision, and outcome |
| **Phase 2 — controlled execution (T2)** | Promoting proven action classes to act-with-approval | **The core path.** Typed proposal → mandate check → authenticated approval → execution through the owning system → verified result. Promoting a class to production also requires the chosen connection's effect verifier and evidence contract — installation work |
| **Phase 3 — bounded autonomy (T3)** | Narrow, reversible action classes inside hard limits | The guide treats this as exceptional; in the product it is the normal path for routine work. A certified action class executes directly inside value, time, scope, rate, and recipient limits enforced outside the model, is sampled for review afterwards under deterministic rules and forced floors, and demotes automatically on exceptions. Production use additionally requires populated demotion signals, fallback, and drills |

## 4. Execution-mode mapping

The guide assigns an execution mode per action class. Lagstyr routes on two separate
axes: the action class's **execution mode** (how much autonomy) and the skill's
**risk tier** (how consequential the write is). They are deliberately not the same
thing, and neither can be chosen by the agent.

| Guide mode (Doc 01 §4.2.1) | lagstyr execution mode | Usual risk tier |
|---|---|---|
| T0 — Retrieve / analyse | `T0` — read authorised evidence; create no effect | `read` |
| T1 — Draft / recommend | A **reference tier only**: the runtime has no separate T1 route. A reversible local draft runs as `T3`; a consequential commit stays `T2`, with a person deciding it | as routed |
| T2 — Act after approval | `T2` — stop before the effect; a person approves the exact proposal; the kernel applies it | `write_governed` |
| T3 — Autonomous within bounded policy | `T3` — execute directly inside a promoted, certified class; deterministic sampling and exception review follow | `write_safe`, with hard limits plus promotion and demotion evidence |
| (Control-plane change — no guide mode) | Any mode | `write_kernel` — changes to authority itself always require independent approval |

## 5. When you do not need lagstyr

The guide is honest about this, and so are we. If your needs stop at search,
summarisation, drafting or single-system automation — Phase 1 work at T0/T1 — a
sanctioned assistant and native SaaS automation are the better answer.

lagstyr becomes the natural next step at exactly the guide's graduation
triggers (Doc 00 Appendix A.5): the first custom write-enabled automation, work
that crosses several systems, a workflow whose failure would materially harm a
customer, or a growing production portfolio that needs one register, one
authority model and one audit trail.

## 6. Intended deployment posture

Lagstyr is designed on one principle: the party that acts must not keep the only
record of its authority. The intended deployment is **BYOC** — the kernel,
workers, database, and storage run inside infrastructure the customer controls,
or in an isolated installation an approved partner operates for one customer —
with no Lagstyr vendor service on the runtime path and never a shared service.
Model and provider routes are explicit and governed by the organisation, through
one model seam; some document-processing paths have specific provider
requirements, so we do not claim blanket provider neutrality. This matches the
guide's positions on data control, residency, and exit design (Doc 01 P15): the
operating context — memory, mandates, decisions, and evidence — stays with the
company.

**Lagstyr is not currently available for installation, evaluation, trial,
pilot, demonstration, or product access, and there is no supported release.**
The website collects expressions of interest for development and availability
updates only. The dated evidence behind every claim above is on
[lagstyr.com/development/](https://lagstyr.com/development/).

---

*The guide gets an organisation to the point where it needs an operating spine.
Lagstyr is the product expression of that spine, now in private development.
Learn more at [lagstyr.com](https://lagstyr.com/).*