IRONLAW is the governance policy gate at the heart of Bastion. What each doctrine covers, how it maps to compliance questions, and where Citadel enforces the same principles at the development substrate.
IRONLAW is not a marketing label. It is a normative doctrine - seven governance rules that constrain what an AI agent may do and how accountability is demonstrated. Each rule answers a specific question that a compliance officer, regulator, or auditor might ask. Together they form a policy gate that makes the difference between an AI system that has governance and one that merely claims it.
Rethunk.AI builds two peer products - Bastion and Citadel - that apply IRONLAW principles at different layers. Bastion enforces the doctrine at run-time against live agent actions. Citadel enforces the same principles at the development substrate: agent identity, namespace permissions, and the audit feed that operator teams consult during review.
Below is what each public IRONLAW doctrine covers and how it maps to questions your legal and risk teams already ask. The sections are grouped for readers, not as an execution recipe. For the names, examples, and artifacts used across this site, see the IRONLAW overview.
Did we treat human blast radius - including indirect, delayed, or omission harm - with explicit objectives, active rules of engagement, and safeguards matched to risk?
Regulated work is full of actions that affect people, data, and safety even when the agent is "only" automating back office or infrastructure. IRONLAW requires that consequential impact be surfaced, bounded, and governed before execution - not explained away after the fact.
Compliance mapping: Impact assessments, RoE documentation, change-risk records, and patient or client safeguards. This is the bridge between "the model can do it" and "we chose this blast radius knowingly." On the Citadel side, namespace grants describe what a development agent may touch, and the audit feed records every action against those declared bounds.
Is the requesting principal authorized to direct this action?
Every action must originate from a principal with documented authority to request it. Authority is not implied by access. A user who can invoke the agent does not automatically have authority to direct every class of action the agent is capable of.
Compliance mapping: Principal authorization logs, delegation records, role-based access control documentation. Citadel extends this principle to agent identity: agent tokens are distinct from human OAuth sessions and revocable through the operator control surface. An agent that can read code is not automatically authorized to write it. In financial services, this maps to "who has signing authority for this transaction class." In healthcare, it maps to clinical privilege documentation. In federal contracting, it maps to delegation of authority orders.
Where policy requires it, is there current, specific consent for this privileged or hazardous act - not only standing trust or stale approval?
Some classes of action need fresh authorization at the moment of execution. Prior trust relationships do not replace documented consent when the doctrine says they cannot.
Compliance mapping: Break-glass workflows, re-approval for production or PHI-adjacent changes, warrant-style grants when policy demands them - CISO authorization for narrow production paths, clinical governance sign-off - expressed as machine-checkable policy where Bastion applies it.
When legality, identity, or scope is below threshold, did we hold or escalate instead of widening the mission?
Agents under pressure must not silently expand scope. Ambiguous targets, undefined resource sets, or unclear legal context should stop the line - not guess and proceed.
Compliance mapping: Scope definitions in change tickets, classification handling in government-adjacent environments, and "no silent scope creep" expectations that map cleanly to supervision and separation-of-duties narratives. Citadel's namespace permission atoms enforce the same boundary at the development substrate.
Did the agent stay inside assigned terrain, data, tooling, and network bounds - without self-granted expansion?
Credentials and grants should match the smallest defensible surface for the task. Broader access requires a new authorization path, not runtime improvisation.
Compliance mapping: Matter-level or environment-level boundaries (legal), least-privilege access reviews (security), and configuration-bound use of models and tools so approved tools stay inside their approved roles.
Can we show who decided, what was decided, when, and why - with evidence that survives tampering and selective omission?
Attribution, tamper-evident records, intent integrity between formation and execution, and ledger structure that refuses new writes when the evidence chain is broken all live under this theme. Regulators ask whether logs can be altered; IRONLAW-backed policy treats broken integrity as a hard stop, not a footnote.
Bastion implements this rule through a hash-chained intent ledger with Merkle checkpoints and a versioned doctrine loader - so the governance configuration in effect at any moment is itself auditable. Citadel carries the parallel obligation: its audit feed records operator attribution for every agent action, covering which token acted and against which namespace.
Compliance mapping: Chain-of-custody expectations, legal hold readiness, forensic admissibility, and the "what did you think would happen?" question when outcome classes are reconciled against intent.
Under stress or disconnect, did continuity stay inside prior mission goals and rules of engagement?
Connectivity is not permission. Partition or outage must not become implicit authorization for new mission shapes.
Compliance mapping: Continuity and disaster-recovery governance, bounded autonomous behavior during uplink loss, and operational doctrine that matches how your industry already writes RoE for humans.
No single rule substitutes for the others. Authority, consent, scope discipline, least privilege, evidence, and RoE-bound continuity all have to read credibly together when an automated action is treated as acceptable. Bastion implements IRONLAW as machine-readable policy at the run-time layer. Citadel applies the same principles at the development substrate. The IRONLAW overview lists the canonical names and examples used on this site.
When policy allows an action, Bastion-style systems write a structured record to the intent ledger. Typical fields include:
This record answers the auditor's questions directly, without requiring post-hoc reconstruction from disparate logs. The answer to "what ran, under whose authority, and can you prove it" is in the ledger entry.
For regulated industries, this is what governance looks like in practice - not a policy document alone, but an enforced technical gate with an evidence path that covers both the development substrate and the production run.
How spec-driven development functions as a control surface for governed engineering - and the tooling that keeps it honest.
An audit trail is only as valuable as its credibility under examination. The architecture behind hash-chained audit posture across Bastion and Citadel.
Interested in working together?
We help teams ship governed AI operations - book a call to discuss your specific needs.
Was this page helpful?
