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

Operating the work

The Operate section is where work that is not a decision lives: work that is waiting, blocked, overdue or unverified, and the pages that show how the installation is doing.

Work queues

Work queues sorts everything in flight into six neutral queues: awaiting approval, awaiting input, blocked, resumable, overdue, and failed effects. A queue is a view over authoritative rows, not a place work is put; an item leaves a queue when its record changes.

Tickets

A ticket is a unit of work with an owner and a lifecycle. Tickets lists those awaiting human input, and a ticket’s own page shows its facts, its history, and the moves open to you under Move it on and Or abandon it. The moves are approve, assign, block, claim, close, promote, reject, resume and submit for review. The console offers only the moves the kernel allows for the ticket’s current state, and the kernel decides. Rejecting a ticket returns it for re-specification; a terminal ticket says so and offers nothing.

External effects and verdicts

An external effect is a change Lagstyr made, or asked a connected system to make, outside its own record: a payment instruction, an email, a record written to another system. External effects shows the receipt for each and, above it, the effects awaiting a verdict.

The governing rule is printed on the page and is worth repeating here:

A provider’s write acknowledgement is not a completed effect: each receipt stays pending until read-back verification from the owning system, and an unresolved deadline is shown overdue. Failed and overdue receipts open reconciliation work rather than disappearing.

When an effect cannot be verified automatically, a person records what happened. You choose The effect occurred or The effect did not occur, attach evidence, and Record outcome. If you cannot tell, you say why — the request went out and the answer was lost, or nothing came back at all — and record that the outcome cannot be established, which opens a reconciliation for your operator.

An effect bound to an obligation never closes the obligation by itself. A partial or failed effect keeps one reconciliation record, and compensation resolves it only when a separate governed effect is itself verified. The receipt row shows that chain.

Cash and commitments

Cash and commitments joins receivables from your accounting system to the governed operations around them: ageing, the cash case, the next action, and the communications decided. The page says which side owns what: the accounting system owns invoices and payments; Lagstyr owns the mandate, the communication decision, the exception, the evidence and the verified effect. Nothing here is a second ledger.

Operating outcomes

Operating outcomes is the closest thing your console has to a report: every retained record in the installation, as at the moment you load it, summarised as a management projection with its calculation definitions beside the numbers. Its Proportional autonomy section shows, per action class and per workflow, how much work ran straight through at T3, how much was reviewed, and what T2 approval cost in burden and latency. It is a read-time projection, not a second metric store, and every figure can be traced to its definition on the page.

Designed reports — a board pack with named sections, indicators and recipients — are set up through the Task designer in Tools, which turns a scripted interview into a structured ticket draft that you submit for approval. Their rendering and delivery happen outside the console.

Previous chapter Next chapter
lagstyr.
ContactSecurityPrivacyTerms