Skip to content
lagstyr.Register interest

The Lagstyr handbook

  1. For the person who decides
  2. What Lagstyr is for you
  3. Reading your console
  4. What needs your attention
  5. Deciding a proposal
  6. After the decision
  7. Operating the work
  8. Agents and their runs
  9. Governing the company
  10. Access, people and language
  11. For the person who administers
  12. Administering your console
  13. Bringing an agent into service
  14. Defining and promoting action classes
  15. Registering AI systems
  16. Emergency access, passwords and sessions
  17. Sources, structure and the operations index
  18. What this installation connects to
  19. For engineering and DevSecOps
  20. Planning an installation
  21. Installing Lagstyr
  22. Securing your installation
  23. Building and commissioning integrations
  24. Commissioning agents and retrieval
  25. Monitoring and routine operations
  26. Upgrading and managing releases
  27. Backups, restoration and recovery
  28. Responding to incidents
  29. Reference
  30. Glossary

Documentation · The Lagstyr handbook

Defining and promoting action classes

An action class is the unit of autonomy: one kind of consequential action, with its execution mode, the limits it may not cross, the evidence that promoted it and the triggers that pause it. The register’s first sentence is the rule for reading every page in it: The class head and its promoted revision are authoritative; limit counters and signal windows are operational state; pause history is the event log. Every lifecycle change is a governed proposal.

Defining a class

Action classes, then Define a new action class. The kernel validates this payload and routes it for approval; the console adds nothing. The form asks for:

  • a stable key, unique in your installation, such as renewal.commitment;
  • the skill the class executes through, the agent, and the accountable owner;
  • the execution mode: t0 retrieves, t2 acts after approval, t3 acts autonomously inside its limits;
  • a scope schema;
  • what happens when the class is out of service: human review, a manual process, or disabling the action, with a fallback-instructions document and, optionally, rollback instructions;
  • the business-effect limits, as a list, drawn from a closed set of kinds: a single value, an aggregate value, a rate, a recipient, a destination, a time window. A t3 class needs a complete envelope;
  • the demotion triggers, likewise from a closed set: a scorecard regression, a feedback error budget, a policy breach, a dependency failure, an effect-verification failure;
  • your rationale, and your password.

The console calls these conditions demotion triggers, but their automatic response is to pause the class and cancel its in-flight runs. Returning it to draft or changing its execution mode requires a separate governed proposal.

The page warns that your session idles out after a period without activity, and that submitting after that returns you to sign-in. Finish or submit before stepping away; the form is long.

Reading a class

A class’s page separates what is authoritative from what is operational. The head and its promoted revision sit under Authoritative state. The limits are shown as the contract, with the counters beside them as operational state. Promotion evidence, demotion triggers, operational signals and pause history each have a section. If somebody has already proposed a change to the class, the page says so before you propose another; otherwise it tells you that you are not about to collide with anybody.

Revising and promoting

Author the next candidate revision opens the same form, filled from the current class, and the approved payload becomes the next candidate revision. Promotion is the act that makes a revision the head, and it is deliberately the heaviest act on the page. In the console’s words: Promotion is write_kernel: it needs accepted evidence, a complete limit/trigger envelope, an approval after the cooling-off window, and — being a material change — a measurement contract or a recorded exemption. You name the revision number, the accepted evidence (each entry naming its role and exactly one scorecard, measurement result or evidence document), and either a measurement contract or a recorded exemption.

The other governed acts are smaller. Demote withdraws the promoted head and returns the class to draft. Retire withdraws the class from service. Both take a reason. Restore appears only on a paused class and returns it to service; Restoration is governed: it goes through proposal and approval, never a direct switch. All of them are proposals.

Pausing a class immediately

This is one of the two acts in the console that skip the prior decision. Break-glass pause pauses the class and cancels its in-flight runs now, skipping only the prior council decision. It re-authenticates you with your password in every kind of session, records the reason you give, and is fully audited. The receipt names the class and how many in-flight runs were cancelled, and reminds you that restoration is a governed proposal from the class page.

The same call, made once per class, is what Pause all on an agent’s page does; nothing is bypassed there either. The pause form and the restore form never appear together: a paused class offers restore, an active one offers pause.

What promotion does not mean

A promoted t3 class is a class that may act inside its limits without a case-by-case decision. It is not a claim that the class has been exercised in your installation, and it says nothing about a connector, a source or a provider that has not been commissioned. Sampling and exception review after the fact are what keep it honest; see Agents and their runs.

Previous chapter Next chapter
lagstyr.
ContactSecurityPrivacyTerms