A New Framework for Marine AI Systems
Giving AI the ability to talk is relatively safe. Giving AI the ability to act is a different matter: restarting services, changing configuration, installing updates, interacting with hardware. On a boat, where a failed system can mean a dark helm display far from shore, the question becomes urgent:
How do you give an AI system real-world action capability without losing control of what it does?
The AAO (Autonomous Action Operating) Methodology was created to answer that question. It was developed by Dr. Donald Moskaluk at AtMyBoat.com, and the AAO Specification names d3kOS as its reference implementation.
AAO is a framework under active development. It hasn't yet been formally validated or peer-reviewed, and feedback and testing are welcome.
What AAO Means
AAO is an extension to the software development lifecycle and an architectural framework for teams building AI systems that take autonomous actions in the real world. Agile, DevOps and CI/CD were designed before AI systems could act on their own, and they give no guidance for this situation. AAO fills that gap.
Its core principle:
The AI can see everything but can only touch what it is explicitly permitted to touch. Every action is logged. Every risky action requires user confirmation. The base system is always recoverable regardless of what the AI does.
AAO calls this Controlled Autonomy.
Agent Architecture: The Four Layers
AAO separates an AI system into four layers:
LayerNameRole*4AI Conversation LayerThe language model diagnoses, proposes and explains. **It cannot execute anything directly.**3AI Action LayerThe critical boundary.* Only named action functions are allowed. Every request is validated, a snapshot is taken first, everything is logged, health is checked afterwards, and failures roll back automatically.2Runtime LayerConfiguration, services, cache and logs. The AI can operate here, but only through Layer 3.1Immutable BaseApplication code, service definitions, the action whitelist and signing keys. Read-only, and never modified at runtime.
The AI reasons freely in Layer 4 but can only act through Layer 3. It never touches Layer 1.
The Five AAO Framework
The AI can't go beyond its defined action space. Actions are whitelisted by name. The AI calls action functions, not shell commands. Even a successful prompt injection can't request an action that doesn't exist on the whitelist.
Every action is audited before and after it runs. An append-only ledger records what the AI observed, what it decided, what it ran and what happened.
A snapshot is taken before every consequential action. If the action causes problems, the snapshot is restored.
Health checks trigger automatic rollback. If previously running components stop running after an action, rollback happens without human intervention.
The base is always recoverable. No matter what happens in the runtime layer, a reset returns the system to a clean, known base.
Orchestration
AAO also covers how AI work is organized:
Risk levels. Each whitelisted action has a risk level, and higher-risk actions require user confirmation.
Prompt-injection defences. Input sanitisation, isolation of external data, and the action layer as a final barrier.
Failure intelligence. Structured recording of failures and tracking of repeat failures, so the same problem isn't "fixed" over and over.
SDLC requirements. Specific expectations at each stage: plan, design, develop, test, deploy, maintain.
Human sign-off. Records of review and authorization for consequential decisions.
Compliance levels. AAO Core, AAO Standard and AAO Advanced.
Alignment with recognized frameworks, including the NIST AI Risk Management Framework.
Marine Use Cases
Boats are an ideal proving ground for AAO because they combine real hardware, intermittent connectivity and real consequences:
Self-healing systems. Restart a failed service, but only through an approved, logged action that can be rolled back.
Over-the-air updates. Install new software without risking an unusable helm display.
Remote diagnostics. Let an owner trigger fixes from a phone without opening unlimited remote access.
Future vessel automation. Any move towards more automation needs a governance model before it needs features.
The d3kOS Implementation
d3kOS applies AAO principles throughout:
Signed over-the-air updates. Packages are verified with an ECDSA signature and a SHA-256 integrity check, numbered migration scripts are applied in order, and the update rolls back automatically on failure. The installer also refuses to downgrade to an older release.
Health monitoring. Agents check system services and report status through the dashboard health indicator and the RSS alert feed.
Fix My Pi. Remote diagnosis and repair through the companion app uses defined repair actions, not open-ended command access.
Per-device identity. Each d3kOS device authenticates with its own Ed25519 key.
Advisory-first AI. Helm and SafeHelm advise and alert. They don't take control of the vessel.
Why AAO Matters Beyond Boating
The same problem exists anywhere AI meets the physical world: industrial equipment, building systems, vehicles, infrastructure. AAO offers a vocabulary and a set of guarantees that apply wherever "the AI did something" must be followed by "and here is exactly what it did, and here is how we undo it."
The full specification is published at skipperdon.github.io/AAO-Methodology.
Frequently Asked Questions
Is AAO only for marine systems? No. AAO is a general framework for AI systems that take real-world actions. d3kOS is its marine reference implementation.
Does AAO prevent prompt injection? AAO reduces the impact of prompt injection. Even if the AI is manipulated, it can only call whitelisted actions, and every action is logged and recoverable.
Is AAO a finished standard? No. It's a framework under active development, and feedback is welcome.
Top comments (0)