orchestrator package

Reviewed against commit 8a2cb42ad on 2026-10-23.

Reference: generated package page orchestrata_ultimate.orchestrator (42 modules, 15,904 lines of code); key modules engine, intent_broker, pipeline_runner, graph_audit, verification_gate, and the impact subpackage. How the intent pipeline, the kernel and the gateway fit together is in the orchestrata overview; the Postman it routes through is postman.

The story

Every piece of work that flows through orchestrata — a user request, an agent task, a governance question — eventually needs someone to decide who does it, whether it is allowed, and in what order it happens. That someone is orchestrata_ultimate.orchestrator, the Orchestrator volk (U:Ox): the governance and policy management engine of the system. The package exists because the surrounding pieces are deliberately dumb about policy — the gateway just moves WebSocket messages, Postman just delivers CXP packets, and the volks just do their specialty — so a single component has to own staffing decisions, policy evaluation, escalation handling, and routing. The top-level Orchestrator class (and its UltimateOrchestrator extension in orchestrator.py) implements the IOrchestrator interface and owns exactly that: volk staffing (VolkStatus, VolkInstance, VolkDefinition), governance decisions (PolicyContext, PolicyDecision), and escalations (EscalationIssue, EscalationResult).

The first major flow through the package is the intent pipeline. A raw natural-language request arrives at the IntentBroker (intent_broker.py), which walks it through a fixed sequence of collaborators. Free text is first run through the natural-language evaluator (IntentEvaluator in intent_classifier.py, which classifies with NLIntentClassifier against the term tables in intent_vocabulary.py and maps the result onto a workflow via WorkflowMapper); a formally-typed intent string is instead parsed by IntentParser (intent_parser.py, backed by nlp.py tokenization/NER and parameter_extractor.py). From there the broker applies security checks — authentication, authorization, injection prevention, and rate limiting in IntentSecurity (intent_security.py) — then Prolog-based validation (intent_validator.py), routing to a target volk (IntentRouter in intent_router.py), and finally dispatch as a CXP packet by IntentDispatcher (also defined in intent_router.py, wired to a real Postman transport by intent_broker_factory.py). Each stage produces a typed outcome from intent_results.py; state transitions are enforced by the intent_lifecycle.py state machine, every intent is persisted to dual Redis+graph history by intent_history.py, and intent_metrics.py instruments the whole run. Reusable intent patterns live in intent_template.py, and multi-step compositions are executed by intent_workflow.py.

The second major flow is pipeline execution. Once work is accepted, pipeline_router.py maps a WorkType (e.g. review, analysis, documentation) to a sequence of StageSpecs keyed by agent Capability, and PipelineRunner (pipeline_runner.py) executes those stages one by one through Postman routing — each volk stage produces a stage result, retryable failures are classified internally, and the whole run is summarized in a PipelineResult. Stage outputs land in the thread-safe ArtifactStore (artifact_store.py); a stage that escalates can INTERRUPT the pipeline via the EscalationInterruptMixin in pipeline_escalation.py; knowledge-graph absorption is folded in through PipelineKGMixin (defined in kernel/pipeline_kg.py, outside this package); and pipeline_kernel.py provides PipelineKernelClient, the in-process bridge that lets the Gateway hand work directly to the runner and stream events back over pub/sub.

Underneath both flows sits the governance substrate. engine.py's UOxEngine evaluates a PolicyContext against Prolog rules and returns a GovernanceResult/GovernanceDecision; the rules run on the janus-swi engine behind prolog_worker.py's single thread-safe PrologWorker, fronted by the PrologBridge fact/query abstraction (prolog_bridge.py). Policies themselves are versioned and tracked in policy_registry.py. Everything the engine decides is auditable: graph_audit.py (GraphAuditTrail; named neo4j_audit.py until the 2026-07-27 Neo4j retirement) writes the durable audit trail to the operational KG, fact_store.py/fact_manager.py/fact_graph.py (the last was fact_neo4j.py until then) keep governance facts in dual Redis+graph storage, and the redis_state.py session-state module is no longer in the package (removed; the table below lists what exists at 8a2cb42ad). The PrologBridge fact/query abstraction now lives in infra/prolog_bridge.py, not in this package. Finally, the impact/ subpackage answers "what will this intent break?" — IntentImpactAnalyzer classifies the intent, queries the graph (orchkg) for blast radius, and produces parallel execution plans. Neighboring packages depend on all of this: the gateway calls in via PipelineKernelClient, Postman carries the CXP packets the dispatcher and runner emit, the governance package's Prolog gate is invoked from the runner, and the knowledge graph both feeds impact analysis and receives audit writes.

Source: the orchestrata_ultimate.orchestrator package — 42 modules and 15,904 lines of code at commit 8a2cb42ad, including the 7-module impact/ subpackage (an earlier revision of this page counted 34).

Module inventory (8a2cb42ad)

Module Purpose
__init__, orchestrator Facade and the Orchestrator / UltimateOrchestrator classes (U:Ox governance and policy management).
engine UOxEngine, Prolog-based policy evaluation.
prolog_worker Single thread-safe PrologWorker on janus-swi.
policy_registry Versioned policy tracking.
graph_audit GraphAuditTrail — durable audit trail in the graph (new name; formerly neo4j_audit).
fact_store, fact_manager, fact_graph Governance facts in Redis plus the graph; fact_graph holds the graph operations (formerly fact_neo4j).
intent_broker, intent_broker_factory The intent pipeline and its production factory.
intent_classifier, intent_vocabulary, intent_normalizer NL classification, keyword registries, and the Haiku normalization stage that cleans the sentence before Prolog sees it (new).
intent_parser, nlp, parameter_extractor, ambiguity_resolver Typed-intent parsing, tokenization/NER, parameter extraction, and ambiguity detection and resolution (ambiguity_resolver new).
intent_security, intent_validator, intent_router, intent_lifecycle, intent_history, intent_results, intent_types, intent_enums Security checks, Prolog validation, routing and dispatch, state machine, history, result and type vocabulary (intent_enums new).
intent_metrics, intent_template, intent_workflow Metrics, reusable templates, multi-step workflows.
pipeline_router, pipeline_runner, pipeline_escalation, pipeline_kernel, artifact_store Pipeline planning and execution, escalation interrupt, the Gateway bridge, and the artifact-store re-export.
verification_gate PipelineVerificationGate — production wiring of the verification subsystem into the pipeline (new; see verification).
impact/ analyzer, classifier, dependency_analyzer, planner, types, cli.

Key responsibilities

Class diagram

Governance core

The staffing/escalation façade (Orchestrator, extended by UltimateOrchestrator, implementing the IOrchestrator interface) alongside the policy engine UOxEngine, which evaluates decisions through the PrologBridge fact/query abstraction over the single thread-safe PrologWorker:

Diagram projects-orchestrata-ultimate-modules-orchestrator-1

Intent pipeline

IntentBroker composes the stage collaborators. Free text goes through IntentEvaluator (which delegates classification to NLIntentClassifier); every intent is then guarded by IntentSecurity, validated by IntentValidator, routed by IntentRouter, and dispatched by IntentDispatcher:

Diagram projects-orchestrata-ultimate-modules-orchestrator-2

Pipeline execution

PipelineRunner mixes in PipelineKGMixin (KG absorption) and EscalationInterruptMixin (escalation-as-interrupt), plans stages with PipelineRouter, and collects outputs into ArtifactStore. PipelineKernelClient is the in-process bridge the gateway uses to drive it:

Diagram projects-orchestrata-ultimate-modules-orchestrator-3

Impact analysis (impact/)

IntentImpactAnalyzer composes three collaborators: IntentClassifier categorizes the intent, DependencyAnalyzer queries the dependency graph in orchkg for the affected scope, and ParallelPlanner produces the parallel execution plan:

Diagram projects-orchestrata-ultimate-modules-orchestrator-4

Notes

Class map (generated)

Generated from the live source AST by scripts/gen-module-class-diagrams.py — do not hand-edit. Abstract classes have a green border; members listed are those defined on the class itself (inherited members excluded). Solid empty-triangle arrows = in-package inheritance; dashed arrows into dashed boxes = external/stdlib/cross-package bases; filled diamond = composition (constructed in __init__); open diamond = aggregation (annotated/injected reference); diamond edge labels name the owning attribute.

orchestrator class map