Build the behavior of the application, not just the sequence of steps
Enterprise AI processes involve more than moving from one task to another. A step may need to answer what data is eligible, which contract applies, which capability may run, under whose authority, which policy must be evaluated, whether a person needs to intervene, and what evidence must remain afterward.
The Execution Graph keeps those relationships connected to the application path itself. A node represents more than "do this next." It can participate in data, contracts, authority, policy, state, capability eligibility, failure behavior, side effects, versions, and evidence.
Two graphs: what the application may do, and what it did
A governed application should be answerable in two directions. Before anything runs, teams should see what this version is permitted to do. After it runs, they should see what actually happened against the same model.
See what the application permits before it runs
The Published Graph represents approved application behavior: paths, contracts, conditions, capability eligibility, policy gates, waits, review requirements, fallback paths, effect boundaries, and evidence obligations.
Benefit: Give teams an inspectable definition of permitted behavior.
See what actually happened while it runs
The Realized Execution Graph shows which nodes executed, branches taken, context assembled, capability selected, policy decision occurred, reviewer acted, event resumed, retries occurred, and effect committed.
Benefit: Keep intended and realized behavior distinct while preserving the relationship.
Inspect the running graph in the same conceptual model used to design it
At runtime, the same application structure can provide an operational projection showing completed nodes, active node, waiting state, human task, policy result, retries, attempts, and effect state.
Completed nodes
What has finished.
Active node
Where work is currently executing.
Waiting state
What the application is waiting for.
Human task
Who or what decision is required.
Policy result
Which control affected the route.
Retries and attempts
What execution or external-operation attempts occurred.
Effect state
Whether a consequential operation is confirmed, ambiguous, failed, reconciled, or compensated.
Evidence
What must remain afterward.
Contract validity
Do connected nodes agree on the data they exchange?
Dependency validity
Are required capabilities and definitions available?
Policy coverage
Are required controls present where they belong?
Authority continuity
Can authority be carried or re-established across the path?
Route validity
Are capability and deployment paths eligible?
Durable-state requirements
Can waits, events, and resumptions preserve state?
Effect safety
Are consequential operations represented with side-effect semantics?
Evidence coverage
Will decisions and effects remain explainable afterward?
Give dynamic agents room to reason inside governed boundaries
Agentic behavior does not require surrendering application authority to whatever route the model generates. An agent may propose a plan, choose among eligible tools, request more information, revise an approach, generate bounded work, or invoke an approved reusable pattern.
Benefit: Use agentic reasoning where it creates value while keeping consequential behavior bounded by explicit authority, policy, capabilities, and effects.
Connect every kind of application step in one graph
Queries
Retrieve governed operational information.
Deterministic logic
Calculate, validate, classify, transform, or apply rules.
Models
Invoke eligible probabilistic capabilities.
Policy
Evaluate conditions, obligations, approvals, and effect eligibility.
APIs and tools
Call external or internal capabilities under governed authority.
Waits and events
Preserve and resume the process through time.
Human interaction
Pause for review, investigation, information, or authorization.
External effects
Commit consequential business actions with explicit operation state.
Reusable subgraphs
Compose validated patterns inside larger processes.
Keep the contracts between steps explicit
Execution Graph nodes can operate against typed contracts describing what a step receives and what it produces: fields, data types, required values, business entities, proposals, actions, outputs, validation, and mappings.
Benefit: Catch mismatched assumptions at design and publication time.
Carry authority with the execution
As work crosses nodes, the graph can retain initiating subject, current actor, workload identity, tenant, purpose, scope, delegated authority, assurance, and policy state.
Explore Identity & SecurityPut policy directly on the path to action
A policy node or enforcement point can determine which data may be used, which capability may run, whether review is required, whether assurance is needed, and whether an external action may commit.
See the Execution Graph in one business process
The supplier bank-account-change application can coordinate supplier proposal, evidence retrieval, risk checks, policy obligations, human review, waits, revalidation, business operation identity, and effect evidence in one graph.
Proposal submitted
A supplier bank-account change enters as a typed business proposal.
Evidence gathered
Eligible supplier, payment, document, and risk context is assembled.
Risk and policy evaluated
Deterministic checks and policy obligations shape the route.
Human review waits
The process pauses while preserving authority and exact proposal state.
Effect revalidated
The account update is checked before commit.
Evidence remains
The completed path connects policy, approval, action, and effect.
Explore the connected Control Plane
Behavior Intelligence
Follow realized behavior, causality, replay, and evidence.
Explore Behavior Intelligence