Documentation · The Lagstyr handbook

Administering your console

The first part of this book is about deciding. This part is about the work that comes before a decision can exist: bringing an agent into service, defining what it may do, registering the AI systems the company runs, and holding the emergency keys. The console calls the person who does this an operator; this book calls them the administrator, to keep them apart from the person who runs the host your installation lives on.

The administrator’s pages live under Govern (authority, obligations, conflicts, policies, board resolutions, action classes, AI systems, policy exceptions, access holders, administrators) and Investigate (agents, sources, the operations index). The agent-template catalogue has no entry in the navigation; you reach it from the Agents page or from the sign-in page.

Every administrative act is one of three shapes

It helps to know, before you touch a form, which of three things it will do.

A governed proposal. Nearly everything. The form assembles a proposal and hands it to the kernel, which validates it and routes it for approval. Nothing changes until a separate authorised human decides it, and the console adds nothing of its own: mode and risk compatibility, evidence and limit completeness are enforced at the governed boundary, and any refusal is shown back on the page you submitted from. The receipt says so in one sentence: Proposal … submitted. It takes effect only when an authorised approver decides it. Acts at the kernel tier also carry a cooling-off window before the deciding approval can apply.

A break-glass or containment act. Exactly five skip the prior decision. Pausing an action class immediately and pausing every active class an agent holds are break-glass acts that re-authenticate you with a password; see Defining and promoting action classes. Pausing an integration, closing an integration break and disconnecting an integration’s provider connection are containment acts that use your identity-provider session, or your password in an emergency session; see Sources, structure and the operations index. All five are fully audited, and restoration afterwards, whether restoring a class, resuming an integration or reconnecting a provider, is a governed proposal. Beginning consent at a provider re-authenticates you the same way, but it only spends a connection somebody else already approved.

A session act. Recording the administrator access review, changing your language or theme, logging out, logging out everywhere, and setting a new password. These record something about you or your session; they change no authoritative record.

Everything else an administrator reaches is a read.

The contract every governed form shares

Re-authentication. A form that raises a proposal proves who you are. If you signed in through your organisation’s identity provider, the form says so and sends your session’s proof; if that proof is no longer fresh, submitting redirects you through sign-in and back. If you hold an emergency session, the same form shows a field labelled Your password (re-authentication) instead. Some older forms, among them action classes and AI systems, ask for the password in every kind of session.

The button. Every governed form ends in Submit for approval. It never reads Save, because nothing is saved by it.

Refusal. A refused submission comes back to you, not to a dead end. Where a form can re-render itself, it does so with everything you typed still in place and the kernel’s reason marked as an alert. Where the form was a small act inside a register page, you land on a page that says Nothing was submitted. Everything you typed is below — correct it and resubmit, with every field rebuilt and a fresh password field. Only a fault on the kernel’s side ends on an error page, because there is nothing on it for you to correct.

The password budget. Ten password attempts a minute, shared across deciding, rotating, pausing and submitting. Past it, the console answers Too many password attempts. Wait a minute and try again.

Confirmations need scripting. The Continue? dialogs before a destructive act are shown by the browser only when scripting is on. With it off the console still works, but the act proceeds without the dialog. Read the button before you press it.

The acts on the registers

Three register pages carry their governed forms in collapsed Governed actions panels, and a panel appears only when your installation’s authority profile selects that act. When none does, the page says so: No governed actions on this page are selected by the current authority profile.

• Authority: propose a mandate; propose an authority grant beneath one, naming an action of approve, propose, execute, administer or bind; suspend or revoke a mandate; revoke a grant.
• Obligations: record a one-off obligation; register a standing one on a cadence; retire a standing definition; transfer ownership; satisfy with evidence; and one act that waives, cancels or escalates, always with evidence.
• Conflicts: declare, revise or close an interest; assess a conflict against a prospective approver; record its clearance, management or prohibition, with evidence; record a recusal.

Every one of the seventeen is a proposal. None takes effect on the page. The integration pages carry six more governed forms, each in its own collapsed card: open or resolve a remediation case, quarantine a break’s source, lift that quarantine, retire the integration, and propose a provider connection for an integration that connects through OAuth.

What this part does not cover

The host: installing, upgrading, backing up and restoring your installation, and arming emergency access on the box. Those belong to the person who operates the host; the engineering and DevSecOps part covers their installation, integration, security, operations and recovery work.