AI Studio Concepts & Operator DAG
Understand the directed acyclic graph (DAG) behind STRATUM AI Studio and how typed nodes compile specialist behavior, Skills, policy, authority, execution and verification into an AI infrastructure operator.
AI Studio is a DAG-based operator designer
STRATUM AI Studio builds the AI infrastructure operator that sits behind everyday STRATUM AI requests. The center of the interface is a directed acyclic graph (DAG): a visual dataflow model in which nodes represent specific functions or decision stages, and typed wires carry data or control forward from outputs into compatible inputs.
Directed means information moves in a defined direction. Acyclic means the dependency graph does not loop back on itself. That matters in infrastructure automation: STRATUM can determine what depends on what, evaluate policy in a predictable order, compile an execution path, and show exactly how a request moved from intent to proof.
In AI Studio, nodes are not arbitrary visual decorations. A Role can contribute recommendations or required verification. A Skill contributes capability. Context nodes contribute live infrastructure or provider context. Guardrails contribute authority and policy. Execution nodes turn those inputs into a plan, policy decision, approval, Mission DAG, verification and reconciliation.
User Intent is the runtime ingress to the Operator DAG. It represents the request entering STRATUM AI and is normally supplied by the AI interaction rather than manually dragged from the palette.
AI Studio is not a drawing tool wrapped around AI. The DAG is a typed configuration/compiler model for the operator STRATUM AI will use: what it knows, what it may touch, what policy it must obey, what approval it needs, and what evidence defines “done.”
Operator DAG vs. Mission DAG
AI Studio uses a DAG to define the Operator. That Operator DAG is the reusable, versioned intelligence/policy graph selected for STRATUM AI.
A Mission DAG is different. It is generated for a specific approved request and contains the ordered/parallel execution steps required to carry out that Mission. The Operator DAG decides how the request should be interpreted and governed; the Mission DAG is the concrete runtime work produced for that request.
Keeping those layers separate is what lets STRATUM be both flexible and controlled: administrators design the reusable operator once, while each Mission still has a deterministic execution graph and its own evidence trail.
Typed ports give every wire meaning
Ports are typed. Intent, Capability, Context, Policy, Authority, Evidence, Plan, Approval, Mission, Verification and Desired State are different kinds of graph data. AI Studio highlights valid connection targets and prevents meaningless wiring between incompatible ports.
That is the critical difference between a visual diagram and an operational DAG: every edge means something to the compiler/runtime. The same structure can later explain why a specialist changed the plan, why a policy blocked an action, why approval was required, or why verification demanded another check.
Compose specialist behavior without multiplying models
AI Studio is built around roles, capabilities and policy, not a palette of model names. Infrastructure Architect, Network Engineer, Cybersecurity Engineer, ISSM and the other specialist nodes do not have to represent separate LLMs. They are specialist behavior/policy modules that shape how the active STRATUM AI provider/model reasons and what the Mission compiler requires.
The provider and model remain configured in STRATUM AI Administration. AI Studio selects and versions the Operator profile that uses that AI service.
The LLM reasons. STRATUM executes.
The model is not handed an unrestricted shell. The Operator DAG shapes reasoning and compiles a typed Mission. STRATUM then applies authority checks, policy gates, user approval, server-side execution and verification through the platform capabilities already available to STRATUM.
That separation is what makes AI Studio an infrastructure control plane rather than a prompt-workflow toy: the model can propose sophisticated work, but STRATUM remains the system that decides whether the work is allowed and how it is executed.