Intent-Bound Execution
DocIBE-RD-0002
ClassUnclassified // R&D
Rev0.2
StatusWorking Prototype
AI Engineering Assurance Platform · R&D Initiative Notice

Intent-Bound
Execution

The independent authority that determines whether an AI-generated change has earned the right to proceed.

AI agents now write code and reshape live infrastructure at machine speed. IBE is the checkpoint they can’t talk their way past: every change is measured against eight safety checks and is proven — or refused — before it can ship. 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
Verification
67 tests · 0 dependency vulnerabilities · TLA+ model-checked
8
Assurance gates
all must hold
67
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

Why you can trust the verdict

The decision 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.
§5

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
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 subsetnot SLSA-certified, not CMMC.