A workbench built for governance, not just visibility.

In ModelAIr, every component in your AI system is a typed node with real properties — model family, version, hosting environment, data residency, access controls — rather than a shape labelled 'LLM'.

The same applies across the system: data stores carry retention and sensitivity properties, orchestrators carry execution mode and escalation paths, and human checkpoints carry role, authority scope, and response-time requirements.

That's what the schema buys you. Placing a component on the canvas declares a structured record you can query, export, or hand to an auditor later — no separate documentation pass required.

Every AI component in ModelAIr carries an assertion level — a constraint on what it's permitted to do in the system, separate from what it's technically capable of.

Signal means the output is observed but never acted on autonomously. Advisory means the output informs a human decision. Authoritative means the output triggers downstream action without a human in the loop.

That distinction matters both legally and operationally, and ModelAIr keeps it explicit and exportable from the moment you place the component on the canvas.

Authority boundaries mark the perimeter of autonomous AI action within your system. ModelAIr lets architects model this explicitly — drawing a boundary is a first-class design action, not an afterthought.

Inside the boundary, AI components can act on their own. Step outside it, and a human checkpoint has to sign off before anything proceeds. The boundary is visible in the diagram, encoded in the governance record, and exportable to compliance artefacts.

This is the question regulators and risk teams are actually asking. ModelAIr gives architects a way to answer it with precision instead of guesswork.

In most architecture tools, connections are lines. In ModelAIr, every connection between components is a typed edge carrying structured properties: transport protocol, authentication method, data sensitivity classification, and reliability characteristics.

A connection between a model and a data store carries its own protocol (REST, gRPC, message queue), authentication method (API key, OAuth, mTLS), data classification, and reliability model (sync, async, best-effort, guaranteed).

Edge semantics are part of the governance output too — the connection is as much a governed object as the components it links.

There is no export step and no separate documentation layer. The design workspace in ModelAIr is the governance record — built automatically as architects design, structured, and ready for audit.

The output can be queried directly: which components carry authoritative assertion levels? Which data stores handle sensitive data? Which human checkpoints sit in the critical path? These are answerable from the model itself, not from a PDF someone wrote six months ago.

When a regulator asks for AI system documentation, what you hand over isn't a diagram — it's a structured record of how the system is built and what it's permitted to do.