Documentation · The Lagstyr handbook

After the decision

The receipt

Every decision ends on a page headed Decision recorded. It names the proposal and the approval it created, and it tells you in one sentence what happened next. The sentences are worth knowing by sight, because they are the difference between a decision and an effect:

• Your approval is recorded. Approvals now in: 1 of 2. The route needs more than you; nothing has executed.
• Your approval was the last one required; the proposal is approved. The decision is final and its event is named.
• The change was executed. The effect ran, and its event is named.
• Nothing was executed: this proposal type names no active skill, so approval is the record and there is no effect to run.
• Nothing was executed: the resolver is approval-only, so execution happens out of band. Somebody, or some system, still has to act.

A rejection ends the same way: The rejection was recorded.

If somebody else decided the proposal a moment before your submission arrived, you land on Nothing to decide instead. It is not an error. The proposal is no longer pending and nothing changed.

The decided register

Decided lists the most recent decided proposals, newest first, with their outcome and the reasons given. Its heading sentence is the rule for reading it: A decided proposal is a record, not a decision opportunity. Opening one shows the full card you decided from, and offers no buttons.

A link on that page downloads the register as a CSV file: the same rows, in the same order, for the auditor who asked for them. It is one of two exports the console offers; the other is the administrator-access inventory described in Access, people and language. There is no PDF or spreadsheet export and no print view.

Sending a decision’s evidence out

Sometimes one decision has to leave the building: for an auditor, an insurer or a regulator who wants to see the proposal, the evidence, the approvals and the effect as one verifiable bundle. Lagstyr produces that bundle as a decision evidence pack: the decision reconstructed through the kernel’s read surface, written as a directory of files with a content-addressed identity and checksums, including control mappings in the formats assessors ask for.

The pack is produced by a command-line tool that the person who operates your installation runs on your behalf; there is no download button in the console. Ask your operator for it by proposal identifier. Two honesties come with it. The pack maps the decision to your assessment plan and control identifiers, which you supply; it does not certify anything. And where history is missing, the pack says so explicitly, because an incomplete pack is a result, not a failure.