Intent-Bound Execution
DocIBE-RD-0002
ClassUnclassified // R&D
Rev0.3
StatusWorking Prototype
Assurance for AI-Assisted Work · R&D Initiative Notice

Intent-Bound
Execution

The independent authority that determines whether a consequential action, or a decision, has earned the right to proceed.

AI agents now write code, reshape live infrastructure and draft the analysis behind engineering decisions, all at machine speed. IBE is the checkpoint they can’t talk their way past. A change is measured against eight safety checks before it can ship; a decision is measured against eight more before it can be signed. Either way the result is proven, or refused, with a signed reason. Automatic, explainable, and impossible to rubber-stamp.

Document
IBE-RD-0002 · Assurance Dossier
Prepared by
MacTech Solutions · Assurance Engineering
Determination method
Deterministic kernel, no LLM in the decision
Posture
Fail-closed by construction
Profiles
Execution · Decision
Verification
109 tests · 0 dependency vulnerabilities · TLA+ model-checked
16
Assurance gates
8 execution · 8 decision
109
Tests
unit / integration / security
152
Model states
machine-checked
0
Known-safe
bypasses
01

Nothing ships unproven.

Every AI change has to pass all eight safety checks. One failure and it’s stopped, automatically, every time.

02

Refuse by default.

Anything unclear, unsafe, or unauthorized is blocked, and comes back with a signed, plain-English reason you can act on.

03

No AI grading AI.

The verdict is a fixed, formally-verified rule. It can’t be persuaded, rushed, or rubber-stamped. Only satisfied.

§1

How it decides

A change ships only if every check passes. A single failure means it’s refused. No exceptions, no overrides. The same change always gets the same answer. Flip the eight checks below and watch the verdict change in real time.

  Authorized AND Model-traceable AND Within scope AND Policy-compliant
AND Causally valid AND Independently verified AND Evidence-complete
AND Recoverable  OR  REFUSE
Assurance gate register8 / 8 holding
Load determination:
Determination
ACCEPTED
8 / 8 gates · certified
Gates holding8 / 8
DeterminationAccepted
InstrumentSigned certificate
§2

What happens to every change

One path, no shortcuts. Every proposed change runs the same ten steps, from the original request to a signed verdict, and each step leaves tamper-proof evidence behind. Only after all of it does IBE decide.

§3

Watch it catch real mistakes

Three real AI proposals: a broken rate limiter, code that quietly edits the wrong file, and infrastructure that would expose sensitive data. IBE caught and refused all three, each with a signed receipt you can re-verify. Open any one to see exactly why.

§4

Decisions that can refuse

The same kernel answers a second question. Not has this change earned the right to execute, but has this decision earned the right to be signed. An engineering trade study or an acquisition decision becomes structured data: objectives, options, criteria, constraints, assumptions, risks and bias checks, each one explicit and testable. Eight checks then decide whether it can be signed. The answer is a signed Decision Package, or a signed refusal naming exactly what is missing.

  Options-complete AND Criteria-sound AND Assumptions-explicit
AND Risks-assessed AND Bias-checked AND Evidence-complete
AND Human-authority AND Sensitivity-bounded  OR  REFUSE
What a signer gets
  • ✓The recommended option, and how close the call was.
  • ✓Exactly which single input would have to move, and by how much, to reverse the answer.
  • ✓Every assumption owned, based, and consequenced, so it is clear what breaks if one is wrong.
  • ✓The bias checks that were run, with their findings on the record.
  • ✓A signature anyone can verify without our software.
What an AI agent can never do
  • ✗Decide who approves the decision.
  • ✗Approve a decision it drafted.
  • ✗Mark an assumption validated.
  • ✗Record how a bias check came out.
  • ✗Accept a knife-edge result on anyone’s behalf.
One decision, three episodes

A ground-vehicle platform choice, run on notional data and carried through a change in its assumptions. Every figure below comes from an actual run.

Episode 1Trade study. Three platforms, five weighted criteria. One is screened out by a maturity floor before it is ever scored. The tracked platform is recommended, and the package states plainly that protection would have to move 11% to reverse the result.Accepted
Episode 2The world moves. The buy quantity is cut, so the assumption the cost estimate rested on is invalidated. Not a single score has changed. The earlier recommendation can no longer be relied on, and a replacement cannot honestly be issued yet.Blocked
Episode 3Re-decided. Cost is re-estimated at the new quantity. The answer moves to the wheeled platform, and a new signed package supersedes the first, carrying the reason it moved.Superseded

Episode 2 is the one that matters. A decision held in a document has no way to notice that its premise has expired, so the old recommendation goes on looking signed. Here the decision is part of the engineering model itself. Change anything it rests on and the signature stops verifying.

§5

Why you can trust the verdict

The verdict isn’t a judgment call. It’s math. The rules that grant permission and allow promotion are written as formal specifications and machine-checked, so we can prove the unsafe shortcuts simply can’t happen.

Formal verification
Capability lifecycle28 states · safe
Capability · fault injected44 states · caught
Promotion lifecycle34 states · safe
Promotion · fault injected46 states · caught
Proven properties
  • ✓A revoked or expired capability cannot be used.
  • ✓A single-use capability cannot be used twice.
  • ✓A builder cannot issue its own capability.
  • ✓Promotion cannot occur before verification.
  • ✓A refused change cannot be promoted.
  • ✓The builder cannot mark itself verified.
  • ✓A failed deployment reaches rollback or a safe state.
§6

Maturity & disclosures

A working, coherent, production-oriented platform, not a finished product. It is deliberately explicit about what is real versus planned, and makes no false security or certification claims.

Capability maturity
IBE doctrine proofImplemented
Generic assurance kernelImplemented
Causal runtime assuranceImplemented
Capability security · single-processImplemented
Decision profileImplemented
Context packs · domain as dataImplemented
Structured elicitation · LLM elicitorPartial
MBSE integrationPartial
Supply-chain provenancePartial
Compliance evidence · OSCAL / 800-171Partial
Production SaaS / PaaS readinessResearch
Disclosures
  • Execution isolation. The Docker runner is real; where Docker is absent the honestly-labeled local runner runs and certificates record isolated = false. IBE never claims isolation it did not get.
  • Policy. The deterministic TypeScript engine is authoritative; Rego / OPA is a specification mirror.
  • Formal methods. TLA+ specifications are authoritative; the TypeScript checker is the CI gate.
  • Provenance & compliance. in-toto / SLSA-structured and an OSCAL subset. Not SLSA-certified, not CMMC.
  • Decision profile. One evaluation method is implemented, a screened weighted sum. It is transparent and auditable, and it is not right for every decision; every package records which method produced it. Score confidence is recorded and reported, not propagated as probability.
  • Elicitation. The seam that lets an AI agent draft a decision, and the screen that stops it recording judgment, are real and tested. The shipped elicitor is deterministic. An LLM elicitor is not yet implemented.
  • SysML v2. Still an interface with a documented mapping that refuses rather than guesses. Decision objects cannot yet be imported from or exported to SysML v2.