Visual deck
Capability boundaries for AI.
Visual material for explaining AIR and AirGate concepts. The public documentation, release notes, and package contracts remain the technical source of truth.
Capability boundaries
A visual overview of verified contracts, bounded execution, and controlled effects. It is an explanation of the architecture, not a claim that a prompt can grant authority.
Why boundaries remain necessary
Prompt injection, authority drift, and implementation slop are distinct risks. AIR makes a component boundary inspectable; it does not grant a host extra authority.
Untrusted input stays untrusted
Raw prompts, files, and model output are host input. A host must normalize a proposal, provide grants, and reject work outside the declared contract.
From proposal to host action
The flow is conceptual. A host, rather than AIR Core, interprets untrusted input, supplies a contract and grants, rechecks live state, and executes any allowed effect.
Understanding is not permission
A model response or inferred intent does not create authority. The host controls authority; AIR contributes bounded, inspectable decisions only where it is deliberately composed.
Hosts compose bounded decisions
Robotics and ML are illustrative applications. Hardware, sensors, physical controls, and device permissions remain explicit host responsibilities.
Product hosts retain product control
Vela is a downstream product concept. Its native application owns files, player behavior, UI, devices, and model-provider integrations.
Roadmap archive
This slide is retained as historical visual material. Its release labels are not current status; use the changelog and npm package for published version information.