Domain Pack

Layer 11 of 12·Slice: Domain and runtime config·No dedicated platform

Scope of this page. Reference material for the Domain Pack layer: what it owns, what it must not own, and how Synedrix OS implements it today. It is descriptive, not normative — where this page and the Layer Taxonomy Table disagree, the taxonomy table wins.

What this layer is link

The Domain Pack Layer is where Synedrix OS stops being domain-agnostic. Everything below it — orchestration, agent runtime, registry, tools, memory, events, governance, observability — is reusable across any business domain a customer might run. A domain pack is the package that injects the domain-specific entities, workflows, agents, tools, policies, and KPIs that make the platform actually do something for one business, such as Trading, Commerce, Support, Finance, or Operations.

A domain pack composes on the OS through defined contracts rather than extending it. It contributes agent entries to the shared registry using the same schema every OS agent uses, contributes workflows that satisfy the same Workflow Contract Spec every n8n workflow must satisfy, and contributes events that conform to the same shared envelope. It never redefines OS principles, governance abstractions, registry semantics, workflow contract rules, or event envelope standards — it inherits all of them and adds only what is specific to its own business domain.

flowchart LR
  n1([Domain Pack]):::term
  subgraph What it owns
    n2[Specialist agents scoped to the domain]:::agent
    n3[Domain policies approval points and veto logic]:::agent
    n4[KPI vocabulary for the domain]:::agent
    n5[Tool mappings]:::agent
    n6[Optional Capability Modules]:::agent
  end
  n1 --> n2
  subgraph What it must not own
    n7[Shared OS primitives]:::warn
    n8[Synedrix OS]:::term
    n7 --> n8
    n9[The adapter framework itself]:::warn
    n10[Tool Abstraction Layer]:::term
    n9 --> n10
    n11[Actual secrets and credentials]:::warn
    n12[Business Instance Layer]:::term
    n11 --> n12
    n13[Thresholds approver mappings and tenant-specific overrides]:::warn
    n14[Business Instance Layer]:::term
    n13 --> n14
  end
  n1 --> n7
  subgraph Interfaces with
    n15[Agent Registry]:::check
    n16[Orchestration]:::check
    n17[Governance Controls]:::check
    n18[Business Instance]:::check
  end
  n1 --> n15

What it owns link

Per the Layer Taxonomy Table, the Domain Pack Layer owns:

• Domain-specific entities and the business logic that governs their lifecycle
• Domain events, conforming to the shared event envelope
• Specialist agents scoped to the domain (family: domain or family: customer)
• Domain policies, approval points, and veto logic
• KPI vocabulary for the domain
• Tool mappings — the domain-specific adapter implementations that sit behind the OS’s shared tool adapter framework
• Optional Capability Modules — reusable, independently-versioned, entitlement-gated sub-packages of the pack’s own agents and workflows

What it must not own link

A domain pack composes on shared OS primitives; it does not get to fork or duplicate them for its own convenience.

Interfaces with link

A domain pack is only useful once it is composed into the rest of the platform, so it interfaces with OS layers through defined contracts rather than direct calls:

• Agent Registry (Layer 5) — domain agents are contributed to the shared registry using the same schema OS agents use, so the registry stays the single source of truth for what exists and what it may do.
• Orchestration (Layer 3) — domain workflows execute through the same Workflow Contract Spec as every other workflow, so retries, approvals, and observability are handled consistently regardless of which pack a workflow belongs to.
• Governance & Controls (Layer 9) — every domain agent’s escalation_path must terminate at an OS control agent, and every high-impact domain action still passes through the Policy Guard Agent before it executes.
• Business Instance (Layer 12) — a domain pack declares what a business instance may configure (enabled workflows, thresholds, approver mappings, secrets, environment routes, tenant overrides); the instance supplies the actual values. A pack also declares named extension_points a Business Instance Extension may hook into — a distinct, explicitly-granted surface from the instance-configurable one, per ADR-OS-005.

How Synedrix OS implements it link

The Synedrix OS - Domain Pack Template is the concrete authoring spec for this layer. It standardizes how a domain pack is described while inheriting OS rules, and it requires a domain pack to define, in order: domain purpose and scope (mission, in-scope and out-of-scope capabilities, business outcomes); domain entities (name, description, canonical system of record, lifecycle notes); external systems and adapters (with the rule that the OS owns the adapter framework, the pack owns the domain-specific implementation, and the business instance owns the credentials); domain agents (using the OS agent model and registered through the shared registry); domain workflows (using the full Workflow Contract Spec, with the rule that there are no implicit side effects and high-impact workflows must declare policy and approval requirements explicitly); a domain event catalog (conforming to the shared envelope, using stable dotted naming such as position.opened or invoice.sent); domain policy and approvals (approval points, domain vetoes, compliance labels); KPIs and evaluation (KPI vocabulary owned by the pack, targets owned by the business instance, agent quality gates compatible with OS evaluation standards); data and memory usage (canonical truth stays in the OS-owned data layer; Redis is ephemeral hot state only; graph and vector layers are secondary context, never authoritative truth); an instance configuration boundary listing exactly what a business instance may configure; and, per the template’s §12.1 and §12.5, the named extension_points a Business Instance Extension may hook into and any optional Capability Modules the pack declares.

Domain-pack agents carry real, enforced invariants, not just conventions. Per CLAUDE.md and the Agent Registry §6:

• agent_id must be prefixed with the domain pack’s own layer code, e.g. com-agt-001 for a Commerce pack agent or trd-agt-001 for a Trading pack agent — never an os-agt-* identifier.
• owner must be set to the contributing domain pack’s ID, not synedrix-os.
• family must be domain or customer — domain packs may not register agents in the control or observability families, which are reserved for OS-owned agents.
• Every domain agent must declare an explicit escalation_path whose terminal node reaches an OS control agent — os-agt-001 (Orchestrator) or os-agt-004 (HITL Gateway).
• Any domain agent whose execution_scope includes financial transactions, regulated messaging, or irreversible external writes must declare approval_required.policy: true.

The Trading domain pack is a concrete, real example of this layer in production use: it owns its own market-data ingest, strategy swarm, consensus voting, risk/VETO enrichment, and broker-isolated execution at Layers 11 and 12 — while still escalating into os-agt-001, os-agt-002, and os-agt-004 like any other pack. See Synedrix Trading Domain Pack.

Rule of inclusion link

The boundary between this layer and the two layers on either side of it is stated once, in CLAUDE.md, and repeated as the ownership guidance in the Layer Taxonomy Table:

• If it changes how all domains orchestrate, govern, observe, or communicate → Synedrix OS.
• If it changes how one business domain reasons or executes → domain pack.
• If it changes thresholds, credentials, or instance-specific behavior → business instance.

For this layer specifically: anything that is genuinely reusable across domains does not belong in a domain pack, no matter how convenient it would be to add it there — it gets upstreamed to the OS instead. And anything that is only a threshold, a credential, or a tenant-specific value does not belong in the domain pack’s own definition either — it belongs one layer down, in the Business Instance Layer.

OS agents at this layer link

No OS-owned agent is assigned to this layer. Per the Agent Registry §3, the twelve OS agents sit at Layers 3, 4, 5, 7, 9, and 10 only — none of them owns Layer 11. This is by design, not an omission: Layer 11 is populated entirely by domain-pack-owned agents, which by definition are never OS-owned. A Commerce pack’s com-agt-001 and the Trading pack’s trd-ctl-master-orchestrator-001 are both real agents operating at this layer, registered through the same schema as OS agents, but owned by their respective domain packs rather than by synedrix-os.

Related Synedrix OS documents link

• Layer Taxonomy Table — the authoritative row for this layer.
• Synedrix OS - Domain Pack Template — the authoring spec every domain pack must follow.
• Synedrix OS - Responsibility Matrix — capability-by-capability ownership split between OS, domain pack, and business instance.
• Agent Registry §6 — domain pack agent contribution rules and invariants.
• Workflow Contract Spec — the contract every domain-pack workflow must satisfy.
• Synedrix Trading Domain Pack — a real domain pack, owning its own market-data, strategy, consensus and execution infrastructure at Layers 11 and 12.
• Business Instance — the layer immediately below, where a domain pack’s declared configuration surface is given concrete values, and where Business Instance Extensions attach to this layer’s declared extension_points.
• Synedrix OS ADR-OS-005 — Business Instance Extension and Capability Module — the decision record for this page’s Capability Module bullet and the extension_points interface with Layer 12.

Synedrix OS · Layer reference · Domain Pack