Development evidence · 19 September 2026
This page records what the current build of Lagstyr demonstrably does, what still needs proving in a real installation, and the gates — in order — between here and a first customer. Every claim is dated, and nothing on this page is a promise about timing.
How to read our labels
We use status language narrowly, so a technical achievement never becomes an availability claim by implication. Every capability status label on this site means exactly one of these four things; evidence rows carry a plain date or a neutral tag instead.
The capability exists in the product code, is covered by automated tests, and has been run through complete journeys — but on synthetic data we control, not a customer's.
The capability is built, but its most important evidence — running in a real deployment, against real outside systems, on a real buyer's documents — has not happened yet.
The intent and often the specification exist. The code, or the proof, does not.
No installation, hosted environment, trial, pilot, demo, or production support is currently offered — full stop.
Evidence milestone · contract documents · 28 August 2026
This is our own lab evidence, run by us on synthetic data. It shows the capability works and refuses correctly. It is not a customer's documents, a live connection to a customer's systems, or an independent assessment.
102 synthetic documents we generated and hold all rights to — 727 PDF pages across 13 document types. We hold 26 documents back from tuning, and we record the correct answer for every page, field, and search in advance, so results are scored against a fixed answer key rather than judged after the fact.
100 of the 102 documents index through the production path. All 118 scanned, image-only pages are read by text-recognition software inside the installation — nothing is sent to an outside service. The two remaining documents (one over the page limit, one an unsupported file type) are rejected outright rather than half-processed.
23 indexed supplier contracts each yield the expected renewal date, notice period, obligations, and automatic-renewal risk — and every extracted value points at the exact passage of the source document it came from.
The extractor can propose; only a person can make it official. When a reviewer accepts a proposal, everything in it is recorded in one step or not at all. Documents that are unsigned, unreliable, contradictory, or ownerless are refused whole — nothing is half-recorded.
The console joins the evidence, the human decision, the scheduled work, the outward action, and the measurement — without inventing progress. Where a number has no evidence yet, it is shown as not configured, never rounded up into success.
A real buyer's documents and their review, a live round trip into a supplier's actual system, a provisioned installation, and observed production operation. Those proofs belong to the gates below.
Evidence log
Each entry records something that was proven, with its date. Expect new entries roughly monthly while development continues — if this log goes quiet, read the silence as information.
Every place the installation reaches a provider, or is reached by one, now 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. Outbound effects cross a two-phase fence: the claim step is deliberately inert, only the start step releases the payload and the idempotency key the kernel minted, and a provider answer of unknown keeps the attempt without creating a receipt. A signed reference connector is published and driven end to end against the real routing and effect code, and a planted provider change is taken through paging, containment, remediation, and a replacement release. All of that is a loopback proof: no connector has been commissioned against a live provider account, and no installation has been provisioned to run one.
Connecting a consent-only provider is an authorisation-code flow with PKCE always on, and custody is split four ways: the console holds only the flow state, the kernel holds the authority record and never a refresh token or a client secret, a separate broker with no HTTP listener holds the sealing key and performs the exchange, and the connector receives a short-lived access token. The installation registers its own client with the provider; no vendor key sits on the path. Customer and partner connectors declare capture and effects in a manifest, are signed with a key the installation registered, and are published as immutable releases through the ordinary proposal and approval path. This lane has no shipped user yet — Xero and Google Calendar still connect through an attended ceremony — and the specification compiler refuses many real documents by design rather than guessing.
An installation can compose skill revisions it has already been granted into one named workflow without forking the product. The composition is flat and linear, frozen at approval into an immutable candidate, and measured against append-only test cases that the kernel replays and scores itself — the evaluator cannot assert its own score, and a perfect score is required on every case marked critical. Activation must name the exact passing digests, and editing the case set stops new use at once. In the same work a skill’s name stopped being its executable authority: proposals, approvals, agent actions, and effect receipts now pin the exact revision of the contract they were judged against, so a rename or a tier change cannot substitute meaning between validation and application.
A clean installation is inert by construction — which also left it mute about itself: an operator could not discover from the console that their own build carries a source-repository projector. The console now renders what the build ships from the binary’s own compiled catalogue, beside what this installation has actually turned on, and marks capability adopted by an upgrade that no person has yet consented to. A vendor-hosted catalogue was refused outright as a call home, so this needs no licence check and no update poll. Showing a capability never enables it, and a connector that cannot be started is shown with its readiness rather than a switch that would do nothing. No pack has been activated on a real host.
Nine engineering and DevSecOps chapters now cover installation planning, secure deployment, integrations, retrieval, operations, upgrades, recovery, and incidents. The console compiles those chapters in English, German, Spanish, French, Italian, Dutch, and Portuguese; source and translation receipts make stale text fail the build. Older business chapters disclose where a locale falls back to English. The public handbook publishes the English edition.
The authoritative record, document intake, full-text search, and console now work without a hosted model or embedding key. Pinned offline local-embedding and optional local-agent closures, loopback-only transport, root admission before each send, classification-safe export leases, and workload traffic fences are implemented and technically exercised. Hosted routes remain explicit installation opt-ins. This does not qualify a model, prove corpus rights or quality, establish capacity, or complete the observed no-external-traffic gate on a full installed reference deployment.
Text recognition inside the installation was tested against a fixed 28-page answer key — four pages each in English, German, Spanish, French, Italian, Dutch, and Portuguese, half printed and half synthetic handwriting — on one pinned software version, with pass floors declared in advance. It is our own qualification set. It says nothing about signatures, drawings, other scripts, or a real customer’s handwriting, and outside that envelope the system refuses rather than guesses.
In an isolated environment the support-email journey ran through the real routing and approval code: one bounded, reversible draft executed without prior approval inside its certified limits, and was then selected for human review because the message that triggered it came from an untrusted source; the customer-facing send stopped and waited for approval. Every rate in the outcome report carries its numerator and denominator. This proves the route and the measures. No deployed result and no production figure exists.
A review found one component — the reader of share certificates and equity grants — calling an AI model outside the governed run loop, leaving no record that a model had run. Rather than wrap it, we deleted it and re-expressed the job as an ordinary governed agent that must be granted authority before it can act. Four automated checks now refuse any second model path, and each was made to fail on purpose before it was trusted.
A lock in the governed-write path could slow identity ingestion by up to 97% while a governed action was in flight. The cause was located, the hold shrank from 14–73 ms to about 5 ms, and a check now refuses any future table joining that lock without the same protection — proven by removing the protection and watching the check fail. Behaviour under real concurrent load is not yet measured.
An audit of the release pipeline closed eight risks. Running the lane then exposed three more that had been true for weeks — including that the release this page had called “grandfathered” carried no install kit at all. The support policy now says plainly that there is no supported release; every newer build publishes complete signed artefacts as a candidate. Two of the fixes introduced defects that the next daily run caught. That is the record, and it is why the lane now runs every day.
The evidence above: bounded document reading, extraction with exact sources, human-only promotion to record, and inspectable journeys, on the frozen 102-document test set.
Faults were deliberately injected across the authority chain and the governed surfaces that reach it — the code where a missed fault matters most — to test whether the test suite notices. Every surviving mutant was individually examined and recorded in a written ledger — including one wrong entry, kept struck-through rather than deleted.
The full installation launch journey was run end to end in an isolated environment, by us, from documented steps and a reproducibly built install kit. The exercise also caught a broken release-publishing pipeline — that finding is in the record, which is the point of the exercise.
The foundation
These capability groups exist in the product code today, grouped the same way on every page. Behind them sit more than 5,800 automated tests in the source tree, deliberate fault-injection (mutation) testing with a written disposition ledger, properties tested exhaustively over the entire risk-routing space (every tier enumerated, not sampled), and a release gate with named human approvers — one that has already refused a release, which is the control working.
Stable identity for people, companies, agents, suppliers, and contracts. Sign-in through your own identity provider with multi-factor evidence and revocable sessions. Access roles, joiner–mover–leaver cases, and access reviews; when someone leaves, their roles and sessions close in one step.
The core service every action must pass through: who may act, for which legal entity, in what scope, within which limits. Routing by autonomy tier (T0, T2, T3; T1 is a reference tier), approvals, conflict checks, separation of duties, emergency stop and restore — enforced in the database, not only in application code.
Documents with their sources and page-level provenance; extraction into six register families — contracts, vendors, assets, certifications, licences, legal matters — that becomes record only on approval; decisions, obligations, and reports; tamper-evident history; retention, governed deletion, legal holds; and an exportable evidence pack for any decision.
Queues that bring work needing judgement to the right person, decision cards that carry the evidence with the proposal, an authority workbench, registers, exceptions, management reporting — and text-only, bounded chat with an active governed agent, run through the same authority loop as every other action.
Fourteen reusable agent blueprints, each inert until it is granted authority and passes evaluation; agent runs, tasks, proposals, and approvals through one model seam; registers of every AI system, impact assessments, and exceptions. Every change to prompts, skills, and models goes through the same explicit approval as any other material change, and a proposal pins the exact executable revision it was judged against. Customer-authored workflows compose already-granted skill revisions into one immutable, flat, linear release that stays inert until the kernel’s own replay of its recorded cases passes.
No hosted model or embedding credential is required for core records, documents, full-text search, or the console. Managed local embedding and optional local-agent serving use pinned offline assets, bounded resources, exact credentials, and per-send runtime admission; hosted processing is an explicit governed opt-in.
Inbound and outbound email as governed evidence, operator notifications with quiet hours and escalation, operational alerts, native document signing with an offline-verifiable evidence package, and structured reports rendered to DOCX and PDF. None of these can carry an approval or grant authority.
Precisely defined actions, safe to retry, with receipts; the owning system read back afterwards and differences reconciled rather than assumed away. Outbound effects cross a two-phase send fence, so an unknown provider answer keeps the attempt and creates no receipt. One ledger in the release names every connection, held equal to the code in both directions by a build gate. Xero capture and journal posting, Stripe collection and refund, a calendar mirror, source-repository projection, tabular import, eleven operational probes, and signed metadata-only event delivery exist in code, alongside a signed contract by which a customer or partner publishes their own connector as an immutable release. None is commissioned against a real provider account.
SCIM provisioning, an optional SAML broker, workload identity from Entra, Okta, and SPIFFE, and an AuthZEN enforcement point that can consult your own policy engine — with local rules that no external permit can bypass. No buyer tenant or policy engine has been connected yet.
The console supports English, German, Spanish, French, Italian, Dutch, and Portuguese. The handbook is compiled in all seven languages with independent source and translation receipts — the nine engineering and DevSecOps chapters, and now the operator’s chapter on what an installation connects to, the first business chapter to be translated; a floor in the build refuses a silent return to engineering-only. The remaining untranslated business chapters declare their English fallback.
Costs, benefits, and outcomes measured against the decision that authorised the work, with exact definitions and explicit denominators beside every number, so wider autonomy is an evidence-based decision. Switched on only when an installation records real evidence.
Built, not yet proven live
These exist in code or in supported specifications. Their most important proof requires a provisioned deployment, live outside systems, or a real buyer's data — none of which has happened yet.
The installation design, isolation model, operations material, and backup-and-restore paths exist and are rehearsed in isolated environments. The first real installation has not been provisioned.
Governed write-back into Xero (journal posting, receivables reading) and Stripe (hosted collection and refund only), a Google Calendar adapter, source-repository projection, signed event delivery to your own systems, and a signed contract by which a customer or partner publishes their own connector are built, and the whole lane — publish, capture, page, contain, remediate, replace — is driven end to end in continuous integration against a reference connector on a loopback address. A loopback proof exercises none of the things only a real account can show: a provider’s TLS and address pinning, live throttling, credential rotation and revocation, and consent withdrawal. The authorisation-code connection lane has no shipped user yet; Xero and Google Calendar still connect through an attended ceremony. None is commissioned against a real customer environment, so none is presented as an available connector.
PDF and scanned-image reading, bounded Latin-script text recognition (seven named languages, printed text plus a narrow synthetic-handwriting envelope), supplier-contract extraction, and extraction for five further register families are proven on our synthetic test sets. A real buyer's documents — with their mess, their languages, and their owners' review — are not yet.
Sign-in through a customer identity provider, SCIM provisioning, workload identity from Entra, Okta, and SPIFFE, and the AuthZEN connection to a customer policy engine all have code and local cryptographic tests. None has been exercised against a real tenant.
Managed local processor closures and their admission controls are implemented. No embedding or agent-model candidate is advertised as qualified; corpus-rights review, held-out quality judgments, full-envelope capacity measurement, a populated-generation cutover, and complete observed traffic evidence on the installed reference remain ahead.
The outcome view and its calculation definitions are built. Time, cost, quality, and benefit claims stay switched off until a real installation records the evidence they require.
Capacity, availability, upgrade behaviour, and support response can only be proven by running deployments under real load, over time.
The path to availability
Each gate opens on evidence, not on a date — so we publish the sequence and the conditions, and deliberately no schedule. This is the same rule our own operating guide prescribes: every gate is evidence, not a date.
Two intended ways to run it
Every installation locks to one of two operating profiles on the same kernel. Choosing a profile records how an installation is meant to run — it is not proof that one has run, and neither profile is offered for installation today.
For complex smaller businesses: curated connectors, assisted setup, business-hours support, and recovery from backup rather than a promised uptime percentage.
For customers who 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, tightly controlled outbound connections, and no third-party root access.
The install tooling refuses any configuration claiming more continuity than one restorable server — that refusal is deliberate. Not offering either profile yet is our own decision: a policy gate, not a technical one.
Not available
One of these will change first: the design-partner pilot is the next gate, and when it opens, its admission criteria will be published on this page. Ahead of it we intend to run an isolated evaluation environment on synthetic data, operated by us for qualified prospects — one deployment per prospect, never a shared service. It does not exist yet and is not offered. Until then, the website collects expressions of interest only — registering does not apply for access, place an order, or begin an evaluation, and it is how pilot candidates will be found.
Register for occasional development and availability updates — including when the design-partner gate opens.