Status: Canonical Version: v0.1 Date: September 2026 Authority for: goal decomposition, reusable planning knowledge, planning context assembly, capability resolution, executor binding, policy and Business Instance enrichment, graph validation, planning confidence, and incomplete-plan behavior.

Purpose

This specification defines how the Orchestrator Agent transforms a Goal Instance into a validated Runtime Task Graph Instance.

The Orchestrator is not permitted to invent capabilities, tools, authority, or policy. It may dynamically compose new execution paths only from currently registered and permitted building blocks.

Planning objective

The Orchestrator SHOULD construct the smallest valid executable Task Graph that can satisfy the Goal’s success conditions using currently registered capabilities while respecting authority, policy, Business Instance, data, and execution constraints.

Planning knowledge sources

Planning context is assembled from distinct authoritative sources:

  1. Goal definition and Goal Instance — desired outcome, intent payload, success criteria, priority, Business Instance scope.
  2. Capability Registry — what the system can currently do.
  3. Workflow Registry — reusable governed procedures and their contracts.
  4. Agent Registry — agent task surfaces, authority, availability, versions, and tool/memory permissions.
  5. Tool Registry — executable tools, side-effect class, authorization, idempotency, and runtime availability.
  6. Policy and authority state — what is permitted, blocked, or requires escalation/HITL.
  7. Business Instance / BIE configuration — tenant-specific constraints, thresholds, approvers, enabled/disabled capabilities, and permitted overrides.
  8. Governed memory — historical evidence and prior successful/failed execution patterns retrieved through the Memory Access Broker.
  9. Current runtime state — dependency health, capability availability, tool health, circuit breakers, and other relevant operational facts.

Authority precedence

When planning inputs conflict, the effective precedence is:

Canonical contracts and OS invariants
  > policy and authority
  > current registry availability
  > Domain Pack constraints
  > Business Instance restrictions
  > governed memory / historical evidence
  > LLM reasoning
Illustrative example, not a production implementation. Review and test before use.

Lower-precedence sources may narrow choices but may not override higher-authority constraints.

flowchart TB
    P1["Canonical contracts and OS invariants"]
    P2["Policy and authority"]
    P3["Current registry availability"]
    P4["Domain Pack constraints"]
    P5["Business Instance restrictions"]
    P6["Governed memory and historical evidence"]
    P7["LLM reasoning"]
    P1 -->|"outranks"| P2
    P2 -->|"outranks"| P3
    P3 -->|"outranks"| P4
    P4 -->|"outranks"| P5
    P5 -->|"outranks"| P6
    P6 -->|"outranks"| P7

Planning modes

Every Runtime Task Graph records one of four planning modes:

recipe

An exact reusable Goal Recipe or Task Graph Template matches the Goal Type and applicable constraints. The Orchestrator materializes a new Runtime Task Graph Instance from it.

adapted

A reusable recipe or historical pattern provides most of the plan, but current policy, Business Instance configuration, capability availability, or goal-specific facts require structural adaptation.

composed

No complete recipe matches, but registered workflows and capabilities can be composed into a valid graph.

dynamic

The Goal requires new logical decomposition. An LLM-backed planner may propose logical tasks, but every task must subsequently resolve to registered capabilities and pass deterministic validation.

Planning hierarchy

The Orchestrator MUST prefer deterministic reuse over novel decomposition:

1. Exact registered Goal Recipe / workflow
2. Reusable task pattern suitable for adaptation
3. Composition of registered workflows/capabilities
4. Dynamic logical decomposition
5. Incomplete plan / escalation when required capability coverage is missing
Illustrative example, not a production implementation. Review and test before use.
flowchart TB
    G["Goal"]
    H1["1. Exact registered Goal Recipe or workflow: recipe"]
    H2["2. Reusable task pattern suitable for adaptation: adapted"]
    H3["3. Composition of registered workflows and capabilities: composed"]
    H4["4. Dynamic logical decomposition: dynamic"]
    H5["5. Incomplete plan or escalation"]
    G --> H1
    H1 -->|"no match"| H2
    H2 -->|"no match"| H3
    H3 -->|"no valid composition"| H4
    H4 -->|"capability coverage missing"| H5

A completed Runtime Task Graph from another Goal is not directly reusable. It may only serve as historical planning evidence or as input to a reviewed reusable pattern.

Two-pass decomposition model

Goal decomposition is separated into two conceptual passes.

Pass A — logical work decomposition

Determine what work must be performed to satisfy the Goal, independent of specific agents or workflows.

The planner derives:

  • desired state;
  • constraints;
  • available inputs;
  • success conditions;
  • required facts or state transitions;
  • candidate logical tasks;
  • candidate dependencies and conditional paths.

Example:

Goal: purchase equipment

Logical tasks:
- determine value
- verify budget
- evaluate governance
- obtain approval if required
- execute purchase
- verify result
Illustrative example, not a production implementation. Review and test before use.

Pass B — capability and executor resolution

For each logical task:

  1. classify the required capability;
  2. resolve that capability through the Registry;
  3. prefer an existing governed workflow where appropriate;
  4. bind a concrete executor and version;
  5. enrich the task with policy, approval, side-effect, timeout, retry, idempotency, and Business Instance constraints;
  6. validate the complete graph.

The planner MUST request required capabilities before choosing executors. It must not construct plans by merely enumerating available agents and assigning them arbitrary work.

flowchart LR
    subgraph passA["Pass A: logical work decomposition"]
        A1["Desired state, constraints, inputs, success conditions"]
        A2["Candidate logical tasks, dependencies and conditional paths"]
        A1 --> A2
    end
    subgraph passB["Pass B: capability and executor resolution"]
        B1["Classify the required capability"]
        B2["Resolve it through the Registry"]
        B3["Bind a concrete executor and version"]
        B4["Enrich with policy, approval, side-effect, timeout, retry, idempotency and Business Instance constraints"]
        B5["Validate the complete graph"]
        B1 --> B2 --> B3 --> B4 --> B5
    end
    A2 -->|"for each logical task"| B1

Goal Recipe

A Goal Recipe is reusable planning knowledge for a class of Goals. It is not a runtime graph.

A Goal Recipe may declare:

goal_type: string
recipe_id: string
version: semver
required_capabilities: array
task_pattern: array
dependency_pattern: array
policy_hooks: array
approval_hooks: array
failure_strategy: object
success_mapping: object
Illustrative example, not a production implementation. Review and test before use.

Recipes MAY be owned by OS core only when domain-agnostic. Domain-specific Goal Recipes belong to Domain Packs. Business Instance Extensions may configure or restrict a recipe but must not redefine OS authority.

Runtime task IDs, execution IDs, concrete historical Outcome IDs, and Business Instance secrets MUST NOT be embedded in a Goal Recipe.

Historical graph use

Completed Runtime Task Graph Instances may be queried as planning evidence.

Permitted uses include:

  • finding successful patterns for the same Goal Type;
  • identifying common failure/remediation paths;
  • evaluating which workflows/capabilities historically performed well;
  • proposing candidates for reusable Goal Recipes.

Historical graphs MUST NOT bypass current capability resolution, policy evaluation, executor version binding, or Business Instance restrictions.

For v0.1, promotion of repeated runtime patterns into canonical Goal Recipes requires human/domain-owner review.

Policy-aware planning

Policy is a planning input and an execution gate.

If a proposed side effect requires approval, the graph must contain a legal governance path before the side effect can run.

A planner may not omit a governance step merely because historical executions succeeded without one.

Business Instance policy may narrow authority. It cannot grant authority that OS or Domain Pack policy denies.

Memory use

Memory supplies experience, not authority.

The Orchestrator may retrieve relevant prior patterns or facts through the Memory Access Broker. Memory may influence task selection, ordering, or executor preference only where current registries and policies permit those choices.

Memory that conflicts with current canonical policy, registry state, or Business Instance configuration is ignored for execution planning.

Planning confidence and completeness

Planning produces a structured status:

planning_status: complete | incomplete | invalid
missing_capabilities: array
unresolved_inputs: array
validation_errors: array
planning_notes: array
Illustrative example, not a production implementation. Review and test before use.

complete means every required task can be resolved and the graph passes validation.

incomplete means the Goal is understood but one or more required capabilities, inputs, policy paths, or executors are unavailable.

invalid means the proposed plan violates canonical constraints and cannot be repaired under current authority.

An incomplete plan is preferable to a plausible fabricated plan.

Dynamic decomposition constraints

When an LLM is used to propose logical tasks:

  • output MUST be structured, schema-valid data rather than free-form execution instructions;
  • it may propose logical work and dependencies;
  • it may reference only capabilities presented in its planning context or explicitly mark a capability as unresolved;
  • it must not invent agent IDs, workflow IDs, tool IDs, policy rules, authority grants, or Business Instance configuration;
  • it must not determine final runnability;
  • its output is non-executable until capability resolution and deterministic graph validation complete.

Graph validation

Every candidate plan passes the validator defined by the Synedrix OS — Task Graph Spec.

Validation is deterministic and authoritative. LLM reasoning does not override validation failures.

Replanning

Replanning uses the same pipeline as initial planning but begins with current Goal state, completed Task history, Outcomes, current registry/policy state, and an explicit replan_reason.

Replanning must preserve completed execution history and create a new graph version under the same Task Graph identity, as specified by the Synedrix OS — Task Graph Spec.

Domain Pack responsibilities

A Domain Pack SHOULD supply the reusable planning primitives required for its Goal Types:

  • Goal Type definitions;
  • domain capabilities;
  • workflow contracts;
  • optional Goal Recipes / Task Graph Templates;
  • domain schemas;
  • domain policy hooks;
  • side-effect declarations;
  • failure and compensation rules.

A Domain Pack should not pre-create runtime Task Graph Instances.

Business Instance / BIE responsibilities

Business Instance configuration and BIEs may supply:

  • thresholds;
  • approver mappings;
  • enabled/disabled capabilities;
  • preferred permitted workflows/tools;
  • data scopes;
  • operational limits;
  • model preferences where allowed.

They may not bypass OS governance or expand authority above the Domain Pack/OS ceiling.

Invariants

  • The Orchestrator may create new Task Graph structures at runtime.
  • It may compose only registered, currently valid capabilities and executors.
  • Exact reusable procedures are preferred over unnecessary dynamic decomposition.
  • Every Goal receives a newly materialized Runtime Task Graph Instance; old runtime graphs are not replayed for new Goals.
  • Memory is advisory, not authoritative.
  • Policy and authority are planning inputs, not merely post-plan checks.
  • Missing capability coverage produces an incomplete plan or escalation, never invented functionality.
  • Only a deterministic validator can promote a candidate graph to executable state.