Sigma proposes, humans decide: designing AI behind approval gates

The principle

Sigma proposes, humans decide is not a slogan we settled on for marketing. It is the constraint that every Sigma feature is built against. A proposal is a draft object with a target, a diff or payload, an explanation, and a status. It has no effect on an application model, a record or a configuration until a person with the right permission approves it. Approval is an explicit action that is written to the audit ledger with the approver, the timestamp, the proposal identifier and the resulting change.

The consequence is that Sigma can be ambitious in what it suggests without being dangerous in what it does. It can draft an entire application blueprint from a paragraph of description. It can rewrite a decision table. It can summarise a case file. None of those outputs is trusted by the system; they are trusted, or not, by a reviewer.

Why not let the AI act directly

The tempting design is to let the model act and let people undo. It produces impressive demos. It is also the wrong default for systems of record in regulated environments, for three reasons. First, undo is rarely clean when a change has already triggered notifications, webhooks or downstream decisions. Second, accountability requires a named person to have made the call, and a reviewer who rubber-stamps after the fact is not the same as a reviewer who decides before. Third, model outputs are probabilistic, and a process that works nine times out of ten is not acceptable for the tenth applicant.

Putting the gate before the effect rather than after it changes the failure mode. A bad proposal costs a reviewer a minute. A bad action can cost an agency a complaint, a correction letter and an audit finding.

What a proposal contains

Every Sigma proposal carries the same envelope regardless of what it targets. The envelope makes proposals reviewable in a consistent interface and auditable in a consistent format.

• Target: the model, record, decision table or configuration the proposal would change.
• Payload: a structured diff for model changes, or a typed value for summaries and insights.
• Explanation: the reasoning Sigma offers in plain language, including the inputs it considered.
• Confidence and caveats: what Sigma is unsure about, so reviewers know where to look.
• Provenance: the prompt, the model version and the context that produced the proposal.
• Status: proposed, approved, edited-and-approved, rejected, or expired.

Approval is a permission, not a formality

Who can approve depends on what the proposal targets. A change to a data model requires a builder role in the workspace. A change to a rule that affects eligibility can be configured to require a second approver. A summary attached to a case record can be approved by the case officer. These permissions are part of the same persona model that governs everything else in the application, so an organisation does not maintain a separate policy for AI.

Reviewers can edit a proposal before approving it. The edited version is what gets applied, and the ledger records both the original proposal and the edit, so it is always possible to see what Sigma suggested and what a person actually accepted.

Sigma in Studio

In Studio, the most visible Sigma feature is blueprint generation. A builder describes an application, for example a permit process with two review stages and a fee, and Sigma proposes a data model, workflow stages with suggested SLAs, a first pass at rules, personas and pages. The proposal appears as a draft version that can be inspected element by element. Nothing is written to the workspace until the builder accepts it, and acceptance creates a normal unpublished version that goes through the same tests and publish flow as any hand-built change.

Sigma also proposes incremental changes: a missing index, a rule that contradicts another, a page that references a field the model no longer has. These are small, frequent proposals, and the review interface is designed to make accepting or dismissing them quick without making them automatic.

Sigma in Interact and the Console

In the Interact runtime, Sigma produces summaries and insights on records: a digest of a long case history, a flag that a submission resembles previously rejected ones, a suggested next action. These appear in a side panel marked as proposals. A case officer can attach a summary to the record, which writes it to the ledger with their name, or ignore it. The runtime never displays a Sigma output to an end user of a published application as if it were a fact about their case.

In the Console, Sigma watches usage and configuration and proposes attention items: a domain whose certificate renewal is approaching a failure state, a tenant whose worker queue is growing, an integration whose signed webhook has been rejected repeatedly. Again, these are proposals for an administrator to act on, not actions.

Designing for reviewer fatigue

A gate that people click through without reading is worse than no gate, because it produces a false record of oversight. We take a few concrete steps against that. Proposals are batched and prioritised so that reviewers see the consequential ones first. Explanations are short and specific rather than long and generic. Proposals expire if they are not reviewed, so stale suggestions do not accumulate. And the ledger records how long a proposal was open and how long the reviewer spent on it, which gives an organisation a way to notice when review has become perfunctory.

None of this makes the gate perfect. It makes the gate honest: a real decision, by a named person, recorded in a form that can be examined later. That is the standard we think AI in government systems should be held to, and it is the one Peek Platform enforces.