Status: Canonical Version: v0.3 Date: October 2026 Authority for: goal types, goal instances, goal lifecycle, goal identity, business-instance scoping, success criteria, terminal states, and the relationship between goals and task graphs.

Purpose

This specification defines the canonical goal model for Synedrix OS. A goal expresses a desired business or operational outcome. Goals are not executable work; they are transformed by the Orchestrator Agent into executable runtime task graphs.

This spec closes an architectural gap already implied by the Synedrix OS — Agent Registry, whose Orchestrator contract accepts goal_id and goal_type and returns a task_graph.

Core concepts

Goal Type

A Goal Type is the reusable semantic definition of a class of desired outcomes understood by Synedrix OS or a Domain Pack.

Examples:

  • procurement.purchase
  • incident.resolve
  • customer.refund
  • content.publish

A Goal Type defines the input intent schema, expected success conditions, owning scope, and optional decomposition guidance. It does not represent a running transaction.

Canonical fields:

goal_type: string
version: semver
owner: synedrix-os | domain-pack-id
description: string
intent_schema: schema-ref
success_conditions: array
allowed_terminal_states: array
planning_profile_ref: string | null
status: draft | active | deprecated | retired
Illustrative example, not a production implementation. Review and test before use.

Rules:

  1. Goal Types are versioned definitions.
  2. Domain-specific Goal Types belong to Domain Packs, not Synedrix OS core.
  3. A Goal Type may reference reusable planning knowledge, but must not embed runtime task IDs or executor instance IDs.
  4. A Goal Type defines the meaning of success; the Orchestrator determines the executable path.

Goal Instance

A Goal Instance is one concrete requested outcome created from a Goal Type.

Example:

{
  "goal_id": "goal-7f91",
  "goal_type": "procurement.purchase",
  "goal_type_version": "1.0.0",
  "tenant_id": "acme",
  "business_instance_id": "acme-procurement",
  "intent_payload": {
    "item": "developer-laptop",
    "quantity": 20,
    "max_budget_eur": 20000
  },
  "priority": "normal",
  "status": "planning",
  "correlation_id": "corr-123"
}
Illustrative example, not a production implementation. Review and test before use.

Canonical fields:

goal_id: string                  # globally unique durable ID
goal_type: string
goal_type_version: semver
tenant_id: string                # mandatory; the owning tenant; immutable
business_instance_id: string | null   # a business instance of this tenant
requested_by:
  type: user | agent | workflow | external_system | schedule
  id: string
intent_payload: object
priority: low | normal | high | critical
status: received | accepted | planning | executing | waiting_approval | completed | partially_completed | failed | blocked | cancelled
correlation_id: string
created_at: timestamp
updated_at: timestamp
deadline_at: timestamp | null
terminal_reason: string | null
metadata: object
Illustrative example, not a production implementation. Review and test before use.

Goal lifecycle

Canonical lifecycle:

flowchart TD
  R([received]):::term --> A[accepted]:::agent --> PL[planning]:::agent --> EX[executing]:::agent
  EX --> W[waiting_approval]:::check
  W --> EX
  EX --> C([completed]):::term
  EX --> PC([partially_completed]):::term
  EX --> F([failed]):::warn
  EX --> B([blocked]):::warn
  EX --> X([cancelled]):::warn

Rules:

  1. waiting_approval is non-terminal.
  2. completed, partially_completed, failed, blocked, and cancelled are terminal.
  3. A Goal Instance must reach exactly one terminal state.
  4. Goal state is durable runtime state and is mutable until terminal.
  5. Goal outcomes and execution outcomes are distinct concepts. Goal state is not an Outcome Envelope status.

Goal success semantics

A Goal Type defines success conditions. A Goal Instance is complete only when the Orchestrator can prove those conditions from task outcomes and canonical state.

A successful execution path is not sufficient by itself if the declared business outcome was not achieved.

Example:

success_conditions:
  - purchase_exists: true
  - requested_quantity_satisfied: true
  - total_cost_lte_intent_budget: true
  - required_governance_completed: true
Illustrative example, not a production implementation. Review and test before use.

Relationship to task graphs

A Goal Instance is planned into one Runtime Task Graph Instance.

flowchart TD
  GT[Goal Type]:::term --> GI[Goal Instance]:::term --> R[Runtime Task Graph Instance]:::agent --> T[Tasks]:::agent --> E[Executions]:::agent --> O[Outcomes]:::term

The same Goal Type may produce structurally different Runtime Task Graph Instances because planning is evaluated against current capabilities, policies, Business Instance configuration, memory, and runtime state.

A Goal Instance may have multiple versions of the same runtime task graph when governed replanning occurs. It must not silently replace execution history with an unrelated graph identity.

Tenant and Business Instance scoping

A tenant is the isolation boundary above the Business Instance (ADR-OS-008, Tenancy Spec).

  1. tenant_id is mandatory on every Goal Instance. It is taken from the authenticated credential that submitted the goal, never from the request, and it does not change afterward.
  2. A goal whose submitting credential does not resolve to exactly one tenant, such as a platform-scope credential or a delegated credential spanning several, is rejected.
  3. When a Goal Instance belongs to a Business Instance, business_instance_id is mandatory, and that Business Instance must belong to the Goal’s tenant. A Goal Instance never carries a business_instance_id without its tenant_id.
  4. tenant_id and business_instance_id must propagate to all business-sensitive runtime records derived from that Goal, including its Runtime Task Graph, whose tenant is the Goal’s (Synedrix OS — Task Graph Spec).
  5. The requester recorded in requested_by is a principal of the same tenant. For external_system it is a service principal of that tenant. A schedule or a workflow requester runs under a service principal of one tenant, and the goal’s tenant is that principal’s. An agent requester carries the tenant of the invocation that raised the goal. In every case the tenant still resolves to exactly one, or the goal is rejected (rule 2).
  6. A Goal Instance is a tenant-owned record: its table must carry a non-null tenant_id, forced row-level security and tenant-led keys, following the tenant boundary rules in the Synedrix OS - Agent DB Schema. Normative DDL is in § Persistence below.

Business Instance configuration may narrow permitted execution behavior but may not expand authority beyond OS or Domain Pack policy.

Correlation and causation

correlation_id is created or inherited when the Goal Instance enters Synedrix OS and remains stable across the entire execution path.

causation_id belongs to events, invocations, executions, and outcomes rather than to the Goal Instance itself. It records the direct predecessor in the causal chain, as defined by the Synedrix OS — Event Taxonomy Standard and Synedrix OS — Outcome Spec.

Persistence

Goal Types are versioned definition state. Goal Instances are authoritative runtime state and MUST be persisted in canonical relational truth (Supabase PG17 per the Synedrix OS — Tech Stack). Redis may cache or coordinate hot Goal state, but loss of Redis must not destroy or invalidate Goal recovery.

Tables live in the public schema alongside Agent DB Groups A–G and follow the tenant boundary in the Synedrix OS - Agent DB Schema. goal_types is mixed (tenant_id = 'platform' for OS/domain-pack shared types; tenant-owned for BI extensions). goal_instances is tenant-owned.

runtime.task_graphs.goal_id MUST reference an existing goal_instances.goal_id for the same tenant_id (Task Graph Spec). Application integrity enforces the join when a cross-schema FK is impractical.

Invariants

  • A Goal expresses desired outcome, not executable steps.
  • Every Goal Instance references exactly one Goal Type version.
  • Every accepted Goal Instance receives a durable goal_id and correlation_id.
  • Every Goal Instance reaches exactly one terminal state.
  • A Goal may not be marked completed unless its declared success conditions are satisfied.
  • Runtime execution details belong to Task Graphs, Tasks, Executions, and Outcomes, not to the Goal definition.
  • Business Instance configuration may restrict a Goal execution path but may not bypass OS governance.
  • Every Goal Instance belongs to exactly one tenant, and its Business Instance, if any, belongs to that tenant.

Versioning

  • Version: 0.3
  • Supersedes: v0.2