Time to authoritative answer
Median and p95 time from source-document registration to the first governed promotion, with incomplete pairs excluded.
Product · private development
Give agents room to act. Keep every action answerable.
Lagstyr sits between agent intent and company consequence. It gives routine, reversible work a certified lane, stops material work for the exact approval, and keeps the mandate, evidence, decision, external effect, obligation, and measured outcome connected. A trace can show what a model did. Lagstyr is built to prove why the company allowed it and what happened next.
Lagstyr in operation
One contract. Five visible stages. No inferred success.
The operator can follow a supplier contract from source evidence to outcome without creating a second workflow record. Every stage is derived from the authoritative records that already own it.
01 · Evidence
Can the source be relied on?
The signed document, its classification, where it came from, how each page was read, and whether it is due for deletion all remain visible.
02 · Human authority
Were the extracted terms accepted?
The exact frozen proposal, source spans, accountable decision, approval, and applied facts stay together.
03 · Scheduled work
What is now owed?
Notice, renewal, and delivery obligations remain owned, dated, and linked to the contract that created them.
04 · External action
Did the owning system confirm the effect?
Accepted, rejected, partial, unknown, overdue, verified, and reconciled effects stay distinct, and an unknown answer from the owning system never becomes a receipt. What an installation connects to covers the connections themselves. A live connection into a real supplier’s system is still ahead.
05 · Outcome
Did the work produce an evidenced result?
Missing measurement stays not configured. An adverse or overdue result needs attention; it is never rounded into success.
The same path now covers more than contracts. Vendor records, assets, certifications, licences and permits, and legal matters are extracted from their source documents the same way—every value pointing at its passage, nothing becoming record until a person accepts it. And any decision on the case can be exported as a checksummed evidence pack for an assessor, in standard formats, without creating a new record or papering over a gap in the history.
Operating outcomes
Know not only what agents did. Know whether it was authorised, verified, and worth doing.
The outcome view is calculated live from records your installation already holds. It keeps no second copy of the numbers, compares you with no other customer, and estimates no ROI. Every autonomy-tier rate—how much ran directly, how much stopped for approval, how much was reviewed afterwards—is reported with its numerator and denominator.
Human decision load
Proposals, approval decisions, and active corrections show how much accountable human work the operating model requires.
Deadlines and prevention
Recorded obligations show the deadlines found; actions the system refused because they broke policy show the exceptions prevented.
Actions and verified effects
Accepted, rejected, corrected, unconfirmed, and read-back-verified effects stay separate.
Cost per accepted outcome
Cost per outcome is calculated only when the costs and the outcomes cover the same period. If nothing was accepted, you see no unit cost at all—the system never invents one.
Time and benefit evidence
Recorded released minutes remain time evidence. Financial benefit remains unavailable until an authoritative amount and currency exist.
Five planes, one governed path
The model can reason. The operating layer controls what becomes real.
The architecture separates responsibilities often collapsed into a prompt, an orchestration framework, or a collection of logs.
Identity
Stable people, organisations, agents, suppliers, contracts, and external aliases across every system.
Record
Authoritative management records with source, provenance, history, obligations, and retention.
Projection
Queryable context and disposable derived views that never silently become company truth.
Action
Precisely defined proposals, safe to retry, acting through the specialist systems that own the transaction.
Governance
Mandates, approvals, policy, limits, conflicts, exceptions, containment, and governed change.
Authority is sacred. Derived views are disposable. An answer can always be regenerated; the reason a company acted cannot be.
The human operating surface
Attention, judgement, and consequence in one view.
The console holds no authority of its own. It brings the records that need human action into a coherent operating surface while the kernel remains the only validator.
Evidence-rich decision cards
The proposal, mandate, material evidence, conflicts, limits, prior decisions, and expected effect arrive in the same case.
Attention queues
Exceptions and material work route to the person who actually holds authority, rather than a generic approval inbox.
Journey progress
Not started, not configured, waiting, needs attention, and complete remain explicit across the full case.
Calculation definitions
Outcome measures carry their exact meaning beside the number, including exactly what evidence exists and where live proof stops.
Authority workbench
Who may do what, for which legal entity, within which limits, through which approval route—and which governed action still lacks a route—visible before anyone is surprised by a refusal.
Chat with a governed agent
An operator can talk to an active agent in plain text. Each turn re-checks who is asking and what they may see, runs through the same authority loop as any other action, and stops for approval where the work requires it. Text only, size-bounded, and never a channel for granting authority.
Seven-language operating surface
The console supports English, German, Spanish, French, Italian, Dutch, and Portuguese. The embedded handbook ships in every locale—the nine engineering and DevSecOps chapters, and the operator’s chapter on what an installation connects to, which is the first business chapter to be translated. The rest say when they fall back to English.
What an installation connects to
The facts live elsewhere. The authority does not.
An integration is a governed connection to a system that owns the facts—an accounting system, a payment processor, a calendar, a mailbox, a source repository. It reads records in, writes effects out, or both, and everything it does carries a source and an event. A clean installation connects to nothing until somebody decides it should.
What ships built in
Accounting through Xero—chart of accounts, invoices, contacts, payments, a whole book’s journals imported into the shadow ledger, a daily bank position, and journals posted back out. Stripe collection and refund with a verified inbound edge. Email in and out as governed evidence. A provider-neutral calendar mirror. Source-repository projection. Tabular imports. Eleven operational probes. And signed outbound delivery that carries metadata and never record content.
One file names every connection there is
Every place the installation reaches a provider, or is reached by one, has a row in a single ledger in the release, and a build gate holds that file equal to the code in both directions: a connector with no row fails the build, and so does a row whose code has gone. If it is not in that file, this installation does not connect to it.
Your own connectors, on the same terms
A customer or partner integration declares its capture and its effects in a manifest, is signed with a key your installation registered, and is published as an immutable release through the ordinary proposal and approval path. It is not a plug-in inside the kernel: it is a separate worker that may only act through the contract, which is what keeps a connector’s defect a connector’s defect. Its releases are yours—nobody else’s upgrade changes them. The grammar is deliberately closed; this is a governed connector contract, not a no-code workflow engine.
Nothing unknown is recorded as sent
An effect crosses a two-phase fence before it reaches a provider. The claim step is deliberately inert; only the start step hands over the payload and the idempotency key the kernel minted, and only once. If the provider’s answer comes back unknown, the attempt is kept and no receipt is created—uncertainty is not evidence that an external effect occurred.
Three things page. Everything else waits.
A release that cannot execute, a connector whose records are being refused, and a remediation case past the date its owner promised. A pause by a person is containment, not an incident. Nothing quietens an overdue remediation except resolving or re-dating it. Refused records are held as capsules of metadata—what was expected, what arrived, a digest, and when it will be erased. The record itself is never shown.
When a provider changes its API
Upload the provider’s new specification and the installation compiles it into a candidate: a proposed manifest, never an authority. Where the specification does not say enough to be certain, the candidate carries a hole rather than a guess, and a person resolves each one through the ordinary approval. The provider’s own text is shown as a quotation, labelled as the provider’s words and never followed as an instruction. Your active release keeps running, unchanged, until you publish a new one.
Optional capability ships off, and visible is not enabled
Some capability arrives in packs an installation may decline to run: the financial mirror, operational assurance, and software-delivery governance. They are inert until activated, and activating one is a governed decision needing a second approver. The console shows what your build ships beside what you have turned on, read out of the binary itself—no licence check, no update poll, no call home. Showing a capability never enables it, and what the console cannot start, it does not offer to start.
Evidence boundary: the lane is proven end to end in continuous integration—a signed reference connector published and driven against the real routing and effect code, and a planted provider change taken through paging, containment, remediation, and a replacement release. That is a loopback proof. No installation has been provisioned, no pack has been activated on a real host, and no connector—ours or a customer’s—has been commissioned against a live provider account.
Sovereign processing
The authority layer works before you choose an AI provider.
The deterministic record is not held hostage by a model endpoint. Lagstyr’s core records, document intake, full-text search, and operator console work without a hosted model or embedding credential.
Local where it matters
OCR already runs inside the installation. Pinned, offline-packaged local embedding and optional local-agent serving paths are built with bounded CPU, memory, credentials, and loopback-only transport.
External only by decision
A hosted model or embedding service must be selected and approved for the exact processor, endpoint, workload, purpose, and data class. Redirects and inherited proxy routes are refused.
Model choice grants no authority
Selecting a processor does not activate an agent, approve corpus rights, relax local rules, or qualify model quality. Agents remain inert until their own authority and evaluation gates pass.
Bring your own compute
Run one isolated deployment on hardware you control, a rented host, or private or public cloud—directly or through an approved operator. There is no shared customer data plane and no vendor reach-in on the authority path.
Evidence boundary: the local processor closures and controls are built and technically exercised. No embedding or agent-model profile is advertised as qualified, and the complete default installation has not yet produced the required observed traffic evidence.
Intended operating profiles
One authority layer. Two ways to operate it.
Every installation locks to one of two operating profiles. They are intended operating models, not separate products—and neither can be installed until its proof exists in a real deployment. The intended commercial shape is a subscription licence for software run on customer-controlled compute; pricing is not yet published.
Control Starter
Run by an approved partner, for you
Designed for complex smaller and lower-mid-market businesses that need curated connectors, assisted setup, business-hours support, and recovery from backup rather than a promised uptime percentage.
Authority Platform
Run by your own team, on your own compute
Designed for customers that operate the deployment themselves: bring-your-own-compute (BYOC—customer-controlled hardware, a rented host, or private or public cloud), your identity systems in charge (sign-in through your provider, SCIM provisioning, workload identity, and an AuthZEN connection to your policy engine are built and await a real tenant), tightly controlled outbound connections, and no third-party root access.
Shared boundary
Same authority and lifecycle controls
Both profiles use the same isolated kernel, release lifecycle, recovery, deletion, and offboarding controls. Each installation still needs its own proof before it can rely on them.
Inspect the evidence behind the ambition.
The development record separates what is built and lab-tested, what is built but not yet proven live, and what is not available yet.