Frequently Asked Questions

Bastion is designed around a hash-chained intent ledger where every operator directive is recorded with cryptographic chaining. This audit trail is offline-verifiable, meaning you can prove the sequence of actions independent of any live system. The evidence path ties every action back to the operator intent that authorized it, creating an immutable record that boards and regulators can inspect.

Authority starts with operator intent. Before Bastion executes any directive, it routes the request through IRONLAW - a file-backed policy gate that evaluates whether the directive aligns with your governance rules. The TheatreManager (on the edge) holds command-and-control authority for its hosts; Bastion does not command theatres directly. This chain of custody is structural by design, not a claim about permissions later.

That is the design goal. The hash-chained intent ledger, combined with optional Ed25519 directive signing and server-side verification, creates an evidence trail that proves what ran, who authorized it, and when. This is not logging after the fact; it is cryptographic proof architecture. Operator runbooks and evidence-pack tooling are documented under engagement so you can verify the chain offline.

We start with a discovery call to understand your regulatory environment, existing architecture, and what governed agent operations look like in your context. We then scope a dedicated team to design or integrate Bastion into your platform, deliver implementation artifacts, and stay hands-on through to launch. This is not staff aug; it is outcome-accountable delivery.

Both. Some engagements are fixed-scope (build and hand off), others evolve into retainer relationships where we maintain platform health, roll out new Bastion features, or expand governance coverage as your roadmap changes. We prefer engagements where we leave behind useful platform and tooling artifacts that your team can own.

Your organization owns the IP created during engagement - code, documentation, governance schemas, and deployment configurations. We may open-source patterns and generalizable tooling (like our IRONLAW governance rules framework) under permissive licenses, but engagement-specific work is yours to keep, modify, and commercialize as you see fit.

Bastion is designed for deployment in your VPC, air-gapped environment, or other infrastructure you control. We do not run a SaaS instance of Bastion or hold operational data in a Rethunk.Tech-managed service. Technical materials and governance schemas shared under engagement may be stored securely, but your runtime data stays in your control. See our Trust & security page for more details.

Yes. Bastion is designed for deployment in restricted networks. We work with your infrastructure, PKI, and security posture. During engagement, we provide runbooks for TheatreManager enrollment, edge integration patterns, and policy gate setup in your environment. We do not require internet access or external dependencies for core governance operations.

We are in the process of pursuing additional compliance certifications aligned with regulated industry requirements. For the most current status, details on SOC 2, FedRAMP, or other frameworks your organization requires, reach out to [email protected]. We are transparent about what we do and do not claim; security is architecture, not a slide.

Bastion as a whole is not open source, but we ship open components that reflect our engineering style and philosophy. The Bastion component overview on our open-source page shows what we publish and why. Core platform work is delivered under engagement with source-code access tied to partner agreements, not as anonymous public repositories.

Yes. Bastion is designed for deployment in your own infrastructure. We work with you during engagement to stand up Bastion in your VPC, air-gapped network, or other controlled environment. Self-hosting includes your own PKI, policy gate management with IRONLAW, and operational runbooks specific to your deployment.

Bastion is architecture-first. It does not try to be a catch-all compliance dashboard; instead, it routes every operator intent through a policy gate (IRONLAW), hands execution to AI, and leaves a cryptographically-verifiable evidence path. We talk about chain of command on the wire, not permissions as an afterthought. This structural approach is informed by our team's delivery experience in regulated industries, not academic theory.

We open-source tools and libraries that reflect how we think about governed systems and developer experience - utilities for policy validation, governance schema tooling, and patterns for integrating governed workflows. We keep the view deliberately small to avoid turning the site into a directory; see our open-source page for the current portfolio. We open-source when the work helps the broader community and aligns with our delivery philosophy.

Yes. Our open-source libraries and utilities are licensed under permissive terms and designed to be composable. IRONLAW governance schemas and policy validation tooling, for example, can be integrated into other systems. Our philosophy is that good governance patterns should propagate beyond our platform if they help organizations build safer, more auditable systems.