Part 6 of 6

Governance: humans, approval and the destination

Human approval before irreversible actions, a fully declared prompt loop, and the destination: specification-driven probabilistic software engineering.

Andrej Albrecht By Andrej Albrecht Published 2026-07-29 8 min read
Sections 19–21
19 · Human governance

Human approval before irreversible actions

AI proposes System previews impact Human reviews Approve / Reject / Modify System executes
Actions requiring approval
Publish website Deploy to production Send email Launch campaign Register / transfer domain Charge a customer Spend money Delete data Change DNS Modify legal content Create public content Grant permissions Connect external account
Approval required: publish website IRREVERSIBLE AFTER CDN PROPAGATION
What will happenRevision #418 replaces the live site
Systems that changeCDN · DNS cache · sitemap · search index
Records created1 deployment · 1 audit-log entry
Reversible?Yes, previous revision restorable in ~2 min
Expected cost€0.00
Public outputPreview of revision #418 ↗
Rollback planAutomatic restore of revision #417
Approve and publish Modify plan Reject
What this means for the business
Approval gates are the control, and they must be selective

Human approval before irreversible actions is both your risk control and, in many markets, your compliance story. The two easy mistakes are equally damaging: approving everything destroys the efficiency the system was built for, and approving nothing exposes the business to actions it cannot take back. The workable middle is a short, explicit list of irreversible actions, each with a preview of the impact and a named person accountable for the decision.

Decision Agree the list of irreversible actions, and require an impact preview plus a named approver for each of them.
20 · The program, declared

A prompt loop can be declared like a program

Everything this guide covered, in one program definition. Natural language remains part of the system, but the surrounding behaviour is declared, validated and enforced.

program: website_change program definition · v12
input:
user_request: string
tenant_id: uuid
output:
website_revision: VerifiedRevision
stages:
classify_intent → create_spec →
select_design_direction →
create_plan → request_approval →
implement → verify → repair →
mark_ready
routing:
first_build: build_workflow
ongoing_edit: edit_workflow
redesign: redesign_workflow
module_configuration: module_workflow
question: answer_only
permissions:
planner: repository read
builder: repository write
crawler: restricted_read
publisher: approval_required
invariants:
- tenant_isolation
- preserve_user_content
- no_publish_without_approval
- no_unverified_ready_state
- no_secret_exposure
- no_unapproved_side_effect
verification:
schema · architecture · browser ·
accessibility · visual_regression ·
requirement_coverage · security
repair_loop:
success: all_required_checks_pass
max_iterations: 5
max_cost_eur: 2.00
stop_on_no_progress: 2
rollback_on_regression: true
checkpoint:
after_each_stage: true
before_irreversible_action: true
observability:
record prompts · tool_calls ·
state_transitions · costs · evaluations
Each block connects to…
Typed inputs & outputs §08
State machine & routing §05 · §11
Permissions & effects §10
Contracts & invariants §09
External verification §13
Repair loop & stopping rules §16
Checkpointing §17
Observability §06
What this means for the business
A specification non-engineers can review

When the whole loop is declared, including goal, inputs, permitted tools, limits, stop conditions and verification, the system becomes reviewable by people who do not read code. That matters in practice, because legal, compliance, security and the business owner all have legitimate questions about autonomous behaviour, and a specification is the only artefact that answers them without a walkthrough of the source. It also makes handover between teams a document transfer rather than a knowledge-transfer project.

Decision Adopt one specification format across features so review, audit and handover become repeatable instead of bespoke.
21 · The destination

Specification-driven probabilistic software engineering

The mature form of the discipline: every layer above and below the model is declared, and the model's freedom lives inside them.

Human goal
Typed specification
Deterministic orchestration
Constrained model decisions
Controlled tool effects
External verification
Human governance
Verified outcome
The supporting formula
Reliable AI system =
  typed specifications
+ deterministic orchestration
+ constrained model decisions
+ controlled side effects
+ external verification
+ observable execution
+ human governance

The prompt becomes comparable to a function body: an implementation detail. The durable system is the architecture around it.

What this means for the business
The architecture is the asset, the prompts are not

Specifications, evaluation sets, contracts, capability boundaries and governance keep their value across model generations. Collections of tuned prompts do not, because they are calibrated to a model that will be replaced. This is why the useful measure of progress is not how many prompts or agents are in production, but how much of the system is declared and verified. Teams that internalise this stop rewriting their AI features every time the underlying model changes.

Decision Measure progress by declared and verified surface area, and review your AI roadmap against that rather than against feature counts.
Series

Continue the engineering guide

This is one part of a six-part guide on turning prompts into specification-driven probabilistic software.

Back to the series overview →

App & Cloud Architecture · Book a Product Discovery Call

More articles