Status: Derived template
Applies to: Domain-pack authoring in Claude Projects or equivalent build workspaces
Date: May 2026

This template is derived from the existing Synedrix OS canonical documents. It does not redefine OS principles or schemas. It standardizes how a domain pack should be described while inheriting Synedrix OS rules.

1. Purpose

Use this template to define a Synedrix domain pack such as Trading, Commerce, Support, Finance, or Operations.

A domain pack should contribute:

  • domain-specific entities and business logic
  • domain-specific agents
  • domain workflows
  • domain event catalogs
  • domain policies, KPIs, and adapters

A domain pack should not redefine:

  • OS principles
  • shared governance abstractions
  • registry semantics
  • workflow contract rules
  • event envelope standards
  • shared platform responsibilities

2. Domain pack metadata 

metadata:
  domain_pack_id:
  name:
  version:
  status:
  owner:
  primary_steward:
  depends_on_os_version:
  summary:
Illustrative example, not a production implementation. Review and test before use.

3. Domain purpose and scope

3.1 Mission

Describe the business mission of the domain pack.

3.2 In scope

List the business capabilities this pack owns.

3.3 Out of scope

Explicitly list capabilities that remain outside this domain pack.

3.4 Business outcomes

Describe the outcomes this domain pack exists to produce.

4. Domain entities

Document the primary business entities this domain pack introduces.

entities:

  - entity_name:
    description:
    canonical_system_of_record:
    lifecycle_notes:
Illustrative example, not a production implementation. Review and test before use.

Examples may include orders, positions, products, tickets, invoices, suppliers, campaigns, or forecasts depending on the domain.

5. External systems and adapters

List the external systems this domain pack integrates with.

external_systems:

  - system_name:
    purpose:
    adapter_type:
    criticality:
    credentials_owner: business_instance
Illustrative example, not a production implementation. Review and test before use.

Rule:

  • the OS owns the adapter framework
  • the domain pack owns the domain-specific adapter implementations
  • the business instance owns the actual credentials

6. Domain agents

Each domain-pack agent must be defined using the Synedrix OS agent model and registered using the OS registry rules.

domain_agents:

  - agent_id:
    name:
    archetype:
    authority_boundary:
    risk_tier:
    governance_class:
    mission:
    non_goals:
    supported_workflows:
    required_tools:
    required_policies:
    required_memory_layers:
Illustrative example, not a production implementation. Review and test before use.

Authoring rules:

  • use OS agent anatomy and authority concepts
  • register agents through the shared registry model
  • do not bypass policy-aware orchestration for side effects
  • ensure at least one blocking evaluation suite before production activation

7. Domain workflows

Every workflow in the domain pack should be specified using the Synedrix OS workflow contract structure.

workflows:

  - workflow_id:
    name:
    purpose:
    trigger_type:
    trigger_source:
    input_contract:
    validation_rules:
    agent_roles:
    tool_dependencies:
    side_effects:
    approval_requirements:
    output_contract:
    idempotency_strategy:
    retry_policy:
    error_policy:
    observability_signals:
    security_scope:
    version:
Illustrative example, not a production implementation. Review and test before use.

Rules:

  • no implicit side effects
  • no free-form downstream automation outputs
  • high-impact workflows must declare policy and approval requirements explicitly
  • contracts are versioned artifacts

8. Domain event catalog

The domain pack owns domain-specific events but must conform to the OS shared event envelope and naming rules.

events:

  - event_type:
    description:
    entity_type:
    source_type:
    payload_schema:
    severity:
    version:
Illustrative example, not a production implementation. Review and test before use.

Rules:

  • events represent facts, not routing instructions
  • use stable dotted naming such as position.opened or invoice.sent
  • preserve correlation IDs across workflow chains
  • do not conflict with OS-level event naming rules

9. Domain policy and approvals

Document the policy and approval logic specific to this domain.

policy_model:
  approval_points:

    - workflow_id:
      condition:
      approval_type:
      approver_role:
  domain_vetoes:

    - name:
      trigger_condition:
      effect:
  compliance_labels:

    - label:
      rationale:
Illustrative example, not a production implementation. Review and test before use.

Rules:

  • the OS owns the governance framework
  • the domain pack declares its domain policies and veto logic
  • the business instance sets thresholds, approvers, and local overrides within allowed boundaries

10. KPIs and evaluation

Describe how success is measured inside the domain pack.

kpis:

  - name:
    description:
    calculation_owner:
    target_owner:

evaluation:
  agent_eval_suites:

    - agent_id:
      suite_id:
      blocking:
Illustrative example, not a production implementation. Review and test before use.

Rules:

  • the domain pack defines KPI vocabulary
  • the business instance sets targets and thresholds
  • agent quality gates must remain compatible with OS evaluation standards

11. Data and memory usage

Describe how the domain pack uses shared Synedrix OS data and memory layers.

data_and_memory:
  transactional_truth:
  temporal_data:
  graph_context:
  semantic_memory:
  hot_state:
  observability_truth:
Illustrative example, not a production implementation. Review and test before use.

Rules:

  • canonical truth should remain in the designated OS-owned data layer
  • Redis is ephemeral hot state only
  • graph and vector layers are secondary context, not authoritative truth

12. Instance configuration boundary

List what may be configured by a business instance.

instance_configurable:

  - enabled_workflows
  - thresholds
  - approver_mappings
  - secrets
  - environment_routes
  - tenant_overrides
Illustrative example, not a production implementation. Review and test before use.

Rule:

Anything that is only a threshold, credential, tenant setting, or environment value belongs to the business-instance layer, not the domain-pack definition.

12.1 Extension points

List the named hook points this pack explicitly exposes for a Business Instance Extension (BIE) to attach a workflow hook to.

extension_points:

  - name:
    description:
    invocation: event | sub_workflow
    event_name:
    hook_signature:
    allowed_actions:
Illustrative example, not a production implementation. Review and test before use.

Rule:

An extension point is the only place a Business Instance Extension may attach a workflow hook. A pack that declares no extension_points accepts no BIE hooks — instance narrowing of instance_configurable remains unaffected. Use invocation: event (default) for a non-blocking hook — the pack emits a publish-event step at that point in the workflow, tagged with event_name, and the BIE’s hook is a wholly separate, independently-versioned workflow with trigger_type: event subscribing to it. Use invocation: sub_workflow only when the hook must block or influence the parent’s continuation — the pack resolves the sub-workflow via an instance-scoped lookup (Execute Workflow, per the hierarchical execution pattern), no-op when the instance has none registered. Either way the hook is always its own full workflow contract with its own side_effects/approval_requirements — never an edit to this pack’s own workflow. See ADR-OS-005.

12.5 Optional Capability Modules

A domain pack may optionally declare one or more Capability Modules — reusable, independently versioned, entitlement-gated sub-packages of its own agents and workflows, sold or licensed to specific business instances without forking the base pack.

capability_modules:

  - module_id:
    name:
    version:
    depends_on:
    agents:
    workflows:
    entitlement_flag:
Illustrative example, not a production implementation. Review and test before use.

Rule:

A Capability Module contributes agents/workflows to the shared registry using the same schema as the pack’s own agents (§6) — same agent_id prefixing rule, same owner = the domain pack ID (not the module), same escalation and approval invariants. It is enabled per business instance only when that instance’s entitlement_flag for the module is set — never bundled into the base pack’s default-enabled surface. See ADR-OS-005.

13. Completion checklist

Before a domain pack is considered stable, confirm:

  • scope is explicit
  • entities are defined
  • external systems are declared
  • agents follow the OS agent spec
  • workflows follow the OS workflow contract
  • events follow the OS event standard
  • policy and approval points are explicit
  • KPIs and evaluation suites exist
  • OS vs domain vs instance boundaries are respected
  • extension points are explicit and named, not a blanket instance-widening allowance
  • any declared Capability Module follows the domain agent invariants and declares its depends_on pack version range

14. Suggested attachment set for a Claude Project

For a domain-specific Claude Project, attach:

Add domain-specific files after that base set.

Canonical Architecture (read before filling this template)

Naming

Standards this template must conform to

Vocabulary

Business Instance Extension and Capability Module

  • Business Instance layer page — Where a Business Instance Extension attaches at the extension_points declared here.
  • Synedrix OS ADR-OS-005 — Business Instance Extension and Capability Module — The decision record for §12.1 and §12.5.

Synedrix OS · Derived Domain Pack Template · May 2026