Constitutional Runtime for Autonomous Systems (CRAS)

A pre-execution authorization runtime that requires evidence before autonomous action. Deterministic protocols, not AI model outputs, govern whether an endpoint may execute.

Comment 1

Inspiration

For years I have studied inquiry itself: how questions organize reasoning, what information they require, and what must be resolved before a conclusion becomes justified.

I created my OpenAI account on September 30, 2022, when the product was still the GPT-3 API and Playground. When ChatGPT launched that November, my research turned to Artificial Intelligence. I have since published preregistered MARL experiments, and every result, positive or null, is public on GitHub (https://github.com/btisler-DS), Zenodo (https://zenodo.org/communities/quantum-inquiry/), and https://quantuminquiry.org/

As AI systems grew more capable, I noticed that most autonomous systems still followed the same pattern:

Observe → Plan → Execute

The question that motivated this project:

Should an AI model determine when an action is authorized, or should authorization be governed independently of the model?

That question led to Constitutional Runtime for Autonomous Systems (CRAS), a runtime that separates reasoning from authorization.

I am a researcher, not a professional software engineer. Modern AI development tools turned years of architectural research into a working system and a mechanism for safe delegation that I now use. I joined this hackathon because these tools were built for people like me. Not only programmers and engineers, but domain experts who know exactly what their field is missing and could never build it before. I am a researcher, not a professional software engineer. CRAS exists because that barrier is gone.

What it does

CRAS is a pre-execution authorization runtime for autonomous systems.

Instead of allowing an AI model to determine whether an action should occur, CRAS evaluates required conditions through deterministic protocols.

The runtime follows:

Observation → Inquiry → Evidence → Authorization → Execution

If required evidence is missing, execution remains blocked.

Only after the required evidence is committed does CRAS authorize an endpoint to act.

The demonstration uses medication delivery, but the architecture is applicable to robotics, software agents, workflow automation, and other autonomous systems.

How we built it

The project was developed as a layered architecture.

The runtime maintains inquiry state, evidence records, authorization grants, and execution records independently of the reasoning model.

The demonstration includes:

a deterministic authorization kernel evidence-backed authorization a simulator and physical robot endpoint visual protocol inspection replayable scenarios automated validation through browser and unit tests

OpenAI Codex was used extensively throughout development to help implement the architecture while preserving the intended protocol design.

Challenges we ran into

The largest challenge was resisting the temptation to place decision-making inside the AI model.

Instead, we continually moved responsibility into deterministic protocols where authorization could be inspected, reproduced, and verified.

Building a physical robot demonstration also proved significantly more complex than expected. Hardware integration, QR recognition, navigation, and endpoint coordination required far more engineering effort than the authorization architecture itself.

Another challenge was translating years of theoretical research into software while learning modern development practices during the project.

Accomplishments that we're proud of

We transformed a research concept into a functioning runtime.

The resulting system demonstrates that:

protocol state governs authorization evidence is required before execution language models cannot override deterministic authorization the same architecture can govern different execution endpoints

Most importantly, the project demonstrates an architectural pattern rather than a single application.

What we learned

Developing CRAS reinforced the distinction between reasoning and governance.

Language models are exceptionally capable reasoning engines, but authorization can remain independent of those models.

We also learned that modern AI-assisted development dramatically lowers the barrier between research and implementation. It allowed an architectural idea developed over many years to become a functioning software system in a short period of time.

What's next for Constitutional Runtime for Autonomous Systems (CRAS)

The current demonstration focuses on a single endpoint and a medication delivery scenario.

Future work includes:

multi-endpoint coordination distributed organizational inquiry software agent workflows industrial automation healthcare and regulated environments quantitative comparison against conventional autonomous architectures

The long-term vision is an operating architecture in which deterministic inquiry, evidence, and authorization govern autonomous execution regardless of which AI model or endpoint performs the work.

Built With

Share this project:

Updates

posted an update —

After receiving helpful feedback, I want to state more clearly what this project is and why it differs from current robotic practice.

On the surface it looks like standard software engineering. The novel value, for robotics and autonomous medical systems, is where and how the safety boundaries are enforced.

1. Hard runtime decoupling vs. "policy as code"

Most autonomous systems, including ROS-based setups, rely on internal state machines, rule engines, or local safety nodes running inside the same execution pipeline. If the model or motion planner decides to move, it checks an internal flag.

Standard approach: The planner evaluates conditions locally. A bug, memory corruption, or race condition in the application layer can still let the actuator command fire.

This architecture: The runtime is a strict pre-execution gate. The physical adapter can not receive an instruction unless a cryptographically signed, validated grant is produced and consumed in a single transaction. The robot engine has no path around the gate.

2. Evidence commits as a hard prerequisite for motion

Traditional systems log asynchronously or after execution: fire the motor, then write the record. If the database locks, crashes, or loses connection, the robot keeps moving and the physical event goes untracked.

This architecture: No commit, no movement. The cryptographic evidence entry (the SHA-256 hash chain record) must commit to disk before the hardware adapter receives the payload. If the audit trail fails, physical execution is blocked at the database transaction layer.

3. Fail-closed accountability

In robotics software, "fail-safe" means stopping when an obstacle appears. Fail-closed at the authorization level means the system treats uncertainty of state (unverified patient identity, missing order parameters, an unwritten audit log) as a critical hardware fault.

Summary

The novelty is not SQLite, cryptographic hashing, or REST endpoints. It is the trust boundary: physical actuation sits downstream of a transactional proof.

The architecture treats the autonomous planner as untrusted software. Before any motor turns, it must present verifiable, auditable receipts to a strict runtime.

Log in or sign up for Devpost to join the conversation.

Submission history