Governed AI Action

Control Before Consequence.

PBE is a pre-execution governance primitive that checks whether an action is still authorized before it becomes consequence.

Policy-Bound Execution is a bounded proof system for AI-assisted workflows. It tests whether an action is still allowed to execute before it becomes real.

Developed by Nemo Flow Systems
A Cradle Crown Holdings research initiative focused on execution governance, controlled AI action, and proof-before-consequence systems.
Mandateallowed scope
Authoritywho may act
Evidencewhat proves it
Statewhat is true
PBE
Boundary
What PBE is / is not

A narrow execution-boundary primitive.

What PBE is

PBE separates request from approval, approval from release, release intent from execution, consequence from recovery, and evidence from mechanism.

It does not ask only whether a system produced an acceptable answer. It asks whether the system is still authorized to act.

What PBE is not

  • not a chatbot
  • not a dashboard
  • not a prompt filter
  • not a generic audit log
  • not a compliance checklist
  • not an autonomous agent framework
  • not a production enforcement claim
Why this matters now

AI systems are moving from suggestion into execution.

They can draft, send, export, approve, update, trigger workflows, release files, and mutate state. Once systems gain the ability to act, governance cannot remain only at the prompt, policy, or audit layer.

Guardrails help shape interaction.

They help filter prompts, responses, content, and risky outputs.

Logs help inspect history.

They help reviewers inspect what happened after the fact.

PBE governs transition.

The core question becomes: was this action still authorized to execute?

What can break without an execution boundary?

Consequence can arrive before authority is rechecked.

AI systems do not fail only because they generate bad answers. They fail when high-speed decisions overflow human review and become real-world consequence without fresh authority, valid state, or bounded scope.

Without an execution boundary

  • approval may be valid when given, but stale when action occurs
  • a payload may change after review
  • system state may drift after authorization
  • a workflow may bypass the intended human checkpoint
  • repeated small actions may accumulate into major consequence
  • evidence may exist only as screenshots or narrative
  • consequence may occur before anyone can verify authority still exists

PBE governs the gate

PBE exists to govern the gate where intelligence becomes action. It does not inspect every thought. It controls consequential flow.

  • Authorized flow passes.
  • Unsafe overflow is refused.
  • Receipts preserve evidence that can be checked against the governed action.
Boundary law

States that are often collapsed must stay separate.

PBE exists to keep these states separate when automation pressure tries to collapse them.

Request is not approval.
Approval is not release.
Release intent is not execution.
Copy is not move, delete, or overwrite.
Recovery is not erasure.
Evidence is not the engine.
Current development status

A working bounded prototype under controlled completion.

The recovered repository contains an implemented local file-release workflow with explicit ALLOW, HOLD, and REFUSE decisions, adapter-controlled execution, receipts, and independent verification. It is not presented as a production deployment or pilot-ready package.

60tests passing at the recovery checkpoint
1bounded file-release workflow
12locked proof cases to reconcile
7completion stages in the fixed goal
Proof path
Request
A bounded action is proposed inside a controlled workflow.
Approval
Permission is recorded without collapsing into execution.
Release intent
Intent stays separate from consequence.
Copy-only consequence
A harmless fixture is copied without move, delete, or overwrite.
Quarantine recovery
Recovery contains the copied fixture while preserving original history.
Independent verification
Receipts and resulting state are checked against the exact request, approval, decision, and consequence.
Current bounded claim

The public position stays behind the evidence.

Implemented

  • bounded request handling
  • approval separation
  • ALLOW / HOLD / REFUSE decisions
  • adapter-controlled copy consequence
  • receipt creation
  • independent verification

Under reconciliation

  • all twelve locked proof cases
  • fail-closed exceptional states
  • approval authority validation
  • bypass resistance inside the declared boundary
  • receipt fact verification
  • tamper detection

Next proof work

  • compare
  • complete gaps
  • controlled application
  • attack testing
  • hardening
  • final evidence freeze

Not claimed

  • production deployment
  • broad filesystem governance
  • customer-data governance
  • enterprise-wide enforcement
  • non-bypassable production control

What this status means

PBE is no longer only a concept: a bounded prototype exists and its canonical test suite passes. The remaining work is to reconcile the implementation against the locked completion standard, close confirmed gaps, apply the workflow under control, attack the boundary, harden it, and freeze the final evidence.

The current claim remains narrow:

  • one implemented bounded workflow
  • one reproducible test entrypoint
  • working enforcement components inside the declared prototype boundary
  • proof completion still in progress
  • no pilot-readiness claim
  • private mechanism not exposed
Public boundary self-test

AI Workflow Boundary Self-Test

Use the public self-test to identify where an AI-assisted workflow may need a stronger execution boundary.

The self-test helps identify where an AI-assisted workflow may cross from suggestion into consequence without enough authority, payload control, state validation, bypass prevention, replay protection, or evidence.

Local self-test only. No data submitted.

Fixed completion goal

Finish one Minimal Working PBE.

One bounded workflow. One consequential action. One independently checkable proof path.

The goal is to demonstrate that a proposed action cannot produce the intended consequence unless it passes an explicit authority boundary, receives a current ALLOW decision, executes through the authorized adapter, and produces verifiable evidence.

  • Recover: preserve one current authority path and historical evidence.
  • Compare: audit the implementation against the twelve locked proof cases.
  • Complete: repair only confirmed gaps, one bounded change and regression test at a time.
  • Apply: run one controlled real file-release exercise.
  • Attack: test bypass, tampering, replay, expiration, revocation, malformed state, and adapter failure.
  • Harden and freeze: correct confirmed weaknesses and produce the final evidence package.
Current boundary: No pilot offer, production deployment, enterprise-wide enforcement, autonomous authority, or non-bypassable production-control claim is made at this stage.
Why Nemo Flow Systems

Proof-oriented execution governance.

Nemo Flow Systems builds execution-governance primitives for systems that must remain bounded, evidenced, and accountable before action occurs.

Control before consequence.
PBE is the first public primitive in this research line. It is designed to stay narrow, mechanical, and proof-oriented: no hype, no autonomous control claims, no mechanism exposure — only bounded proof.
DPI / PBE clarification:
PBE is the public-facing primitive developed from the DPI research line. DPI remains the internal research lineage; PBE is the clearer public framing for controlled execution review.