DocsBook a demo

Platform

Platform overviewArchitectureWorkflow orchestrationGitOps configurationGovernance and AAAAI and MCPKnowledge and contextRuntime and executionEvidence and monitoring

Use cases

All use casesProduction incidentRelease preparationHotfix to productionSecurity scan triage
Why NopsAIIntegrationsSecurity

Resources

All resourcesAI agent governanceMCP governanceMCP securitySelf-hosted platforms
PricingGitHub

Company

How a run worksAboutContactBook a demo

How a run executes

From trigger to final deliverable: validation, authorization, dispatch, agent execution, and finalization.

ConceptAutomation authorOperatorDeveloper

Key points

  • Validation happens before anything is queued: schema, structural limits, dependency graph, profile references, and scope access are all checked up front.
  • AAA authorizes the original caller for every referenced resource, not just the pipeline.
  • The dispatcher selects a runner by scope, capacity, and reachability, then assigns the run over gRPC.
  • The agent resolves variables, secrets, knowledge, and profiles, then executes the graph respecting depends_on.
  • Approval steps pause the run durably and release runner capacity instead of holding it.
  • Final outputs are generated after execution finishes and stored separately from raw task logs.

How it works

Dependency order comes from the graph, not from list position. A step or task starts as soon as every dependency has completed, so independent branches run concurrently up to runner capacity.

Runtime output references such as $steps.<step>.<task>.outputs.<name> are valid when the graph guarantees the producer runs first. A direct depends_on edge is not required if a transitive upstream path already provides that ordering.

A failed step normally fails the run. With ignore_failure, the failure is recorded as failure (ignored), the step renders as a warning, and an otherwise successful run finishes with status warning.

Approval and explicit policy or guardrail enforcement failures always fail closed, regardless of ignore_failure.

Blocking Knowledge Context (policy and guardrail) is pinned by scope at run start, then recomputed as pipeline, step, and task scopes begin. Emergency policy response cancels active runs rather than mutating already-resolved policy.

Examples

Watch a run move through its statesbash
# lightweight: status only, safe to poll
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/runs/$RUN_ID/status" | jq

# full detail once it settles
curl -s -H "Authorization: Bearer $NOPSAI_TOKEN" "$NOPSAI_URL/v1/runs/$RUN_ID" | jq '{status, started_at, finished_at}'
Result

A run is queued, dispatched to a runner, executed step by step, possibly paused at an approval, then finalised with its deliverables.

Implementation evidence

  • doc/runtime-flows.md

    Step-by-step execution flows for each entry point.

  • services/nopsai/pkg/validation/pipeline.go

    The validation performed before a run is accepted.