Skip to content

06Governance & controls

Autonomy is earned
through evidence.

Accountability is not a policy document sitting beside the system. It is a set of controls inside it: what may run, how far it may go alone, where a human decides, and what is recorded afterwards.

Conceptual model · no client data · no certification claims

01Control architecture

Where each control sits.

A conceptual view of the path from a request to a recorded action. Select any control to read what it does and which artifacts it writes.

Conceptual architecture · illustrative, not a live system

Request → Action → Record

Before an action runs

Policy checks

Rules written as machine-checkable policy, versioned and approved, evaluated against every proposed action before it executes.

Artifacts recorded

  • Policy version
  • Approver
  • Check result per action

This diagram is illustrative. It describes the control pattern we build towards, not a live deployment or a customer configuration.

02Artifacts

What gets written down.

Every control produces something inspectable later, by someone who was not in the room when the system was built.

01Before an action runs

Policy checks

Rules written as machine-checkable policy, versioned and approved, evaluated against every proposed action before it executes.

  • Policy version
  • Approver
  • Check result per action

02How far it may go alone

Autonomy levels

Autonomy set per action rather than per system. An action earns a higher level through evidence, and loses it the same way.

  • Level per action
  • Reason for change
  • Review date

03Where a human decides

Approval gates

High-consequence steps stop and wait for a named human. The gate records who approved, when, and on what information.

  • Gate definition
  • Approver identity
  • Decision timestamp

04After an action runs

Audit trail

Every action writes an append-only record linking output back to inputs, context, policy version and the model that produced it.

  • Input and context refs
  • Model and prompt version
  • Output and effect

05Over time

Monitoring

Outcome, cost, drift and failure watched at action level, with thresholds that trigger review rather than a dashboard nobody opens.

  • Thresholds
  • Alert history
  • Drift signals

06On a schedule

Review loop

Accountable owners revisit policy and autonomy against what actually happened, so the control set moves with the system.

  • Review record
  • Owner
  • Changes applied

03Boundaries

What we do not claim.

Governance language attracts overstatement, so here is the limit of ours.

No certification claims

We do not hold ourselves out as certified or accredited against any standard. Where a framework applies to your sector, we build to be assessable against it.

No customer evidence here

Nothing on this page is drawn from a client system. Engagement evidence stays with the organisation that owns it.

No autonomy by default

Actions start assistive. Autonomy moves up only where behaviour has been measured and an accountable owner signs the change.

The thesis

The next generation of software will not wait to be asked. It will understand, decide, act, and prove what it did.

We’re building that generation from Dubai’s DIFC, for organisations that have to answer for what their systems do.