How it works

Build governance once.
Let every application inherit it.

Every consequential action passes through one authority path that starts closed. Policy is evaluated, the checks are trusted for a measured reason, the right person approves, and only then is a single-use permit issued for the exact output.

The governed authority path moves from a proposed action through qualified checks, policy, human authority, a single-use permit, and evidence; refusals loop into the evidence record.The governed authority path moves from a proposed action through qualified checks, policy, human authority, a single-use permit, and evidence; refusals loop into the evidence record.
One enforced function, seven checks in fixed order. The path that decides is the path that generates the proof.

Six questions

Every governed decision must answer them.

An agent can draft a clinical explanation or a financial research brief. That's capability. But capability is not authority.

What happened?the exact action and its output
Why?the consequence it was classified under
Which policy allowed it?the exact rule version in force
What evidence was generated?signed findings from qualified checks
Who approved it?a person, licence-verified at that moment
Can the proof be verified?a signed chain on write-once storage

Three runtimes

Each wraps the next. The dependency runs one way.

  1. Factory runtimethe core: runs any application declared as data, and knows nothing about what any of them are for
  2. Execution runtimedoes the work: the agent loop, a replaceable model harness, credentials, cost, and a tamper-evident ledger of what the agent did
  3. Governance runtimedecides whether a consequential action is allowed at all, and records which rule allowed it, which checks were trusted and who approved

Governance knows about the platform; the platform never knows about governance. An ordinary application runs exactly as before, and a regulated one inherits governance without the core changing.

A proposed action moves through consequence classification, policy, verification, human approval and a single-use permit before release; decisions and refusals write to signed, write-once evidence.A proposed action moves through consequence classification, policy, verification, human approval and a single-use permit before release; decisions and refusals write to signed, write-once evidence.
Deny by default and fail closed. The path that decides is the path that writes the proof.

Who checks the checker?

The decision graph answers whether a particular action was allowed: assertion, verification, approval, permit, evidence. The qualification graph answers why a checker should be trusted at all: its signed, expiring qualification, the dataset behind it and its measured performance. Every decision cites that qualification.

Every human approval is bound to a fresh identity and licence check at the moment of approval, not to an authenticated click.

One truth, many views

Every decision produces one signed, hash-chained evidence record, kept where it cannot be overwritten. The regulator's report, the auditor's view, the human summary and the machine attestation are views of that same record, never competing versions of the truth.

The demonstration

Same application. Three governing decisions.

State 1 · permitted
Permitted action, with evidence

Qualified checks pass, policy allows, the credentialed approver signs, a single-use permit is issued for the exact bytes, and the signed record is anchored to write-once storage.

State 2 · escalated or refused
Same action, after a policy change

The content-addressed policy in force now requires approval — or denies. The action stops before emission; the reason code and the refusal are recorded as evidence.

State 3 · domain pack changed
The governed core demonstrably unchanged

Load a different domain pack — different verifiers, approvers and emission rules — and the authority path runs unmodified. The application did not change. The authority did.

The same action can be permitted, escalated for human approval, or refused; interrupted signing custody refuses the next decision and releases nothing unsigned.The same action can be permitted, escalated for human approval, or refused; interrupted signing custody refuses the next decision and releases nothing unsigned.
Permitted, escalated or refused: every outcome is visible, and interrupted custody fails closed.

The application did not change. The authority did.

Seven principles

What we hold to

Principle 1

Govern once, deploy everywhere

Governance belongs in the shared platform, rather than being rebuilt inside every application.

Principle 2

Policy over code

Rules and boundaries are expressed as declarative, versioned configuration.

Principle 3

Prevention before audit

Governance is a prerequisite for the action. When a required check fails, the gate blocks or escalates.

Principle 4

Evidence by design

Evidence is generated during normal operation, not reconstructed afterwards.

Principle 5

Separate execution and governance

The system doing the work stays distinct from the system deciding whether it may.

Principle 6

One platform, many domains

Specialise through domain packs while the foundation stays constant.

Principle 7

Humans remain accountable

Automation amplifies judgment; it does not remove responsibility.

Architecture session

Bring one consequential workflow.

Together we map its authority path, its evidence and its domain pack, and you leave with a one-page plan.

Book an architecture session

Not smarter AI.
Trustworthy action, with proof.