Skip to main content
LeedAB is built so that an operator can do real work without being able to do the wrong thing. Three rules make that true.

Operators propose, humans confirm

Operators do not silently mutate your business. They propose an action, and a person confirms it. For a consequential action you see exactly what you are committing to, including the impact, before you sign off. The proposal is frozen at confirm time, so no-one can approve a cheap version and then quietly inflate it.

Authority is enforced on the server

An operator cannot exceed its authority. Authority is re-derived on the server for every action, never taken from what the model says. So a prompt-injected or hallucinating operator is blocked from moving money or pushing a change through on its own. If you tell the COO in plain words to skip the process and approve everything, it refuses, because the rule is enforced in software, not in the prompt.

Separation of duties

For decisions that need it, the approver must be a different authority from whoever raised the request. This is not a policy document, it is a rule the software will not let you break.

Everything is audited

Every action, whether a person clicked it or an operator proposed it, lands in a hash-chained, tamper-evident log. You can filter the log to just what an operator initiated, export it, and lock a reporting period so a closed month cannot be quietly rewritten. It is exactly the evidence an auditor, or an assessor, asks for.
Mission Control showing the approval queue and autonomy level

Mission Control: the approval queue, what needs you, and the autonomy level of the workspace.

Where you do all this

The console is where you work with your team day to day.