Purpose

Defines the split of responsibilities between Synedrix OS, domain packs, and business instances. The goal is to prevent architectural drift by making ownership explicit.

Responsibility matrix

Who owns what: the full split of responsibilities between Synedrix OS, domain packs, and business instances, capability by capability.

Capability / ConcernSynedrix OSDomain PackBusiness Instance
Orchestration runtimeOwnsUsesConfigures
Workflow registry modelOwnsContributes workflow entriesSelects enabled workflows
Agent registry schemaOwnsContributes agent entriesEnables/disables per instance
Shared event envelopeOwnsExtends with domain event typesConsumes/configures routing
Policy engine frameworkOwnsContributes domain policiesSets thresholds and overrides
HITL approval frameworkOwnsDeclares approval pointsAssigns approvers and thresholds
Observability standardsOwnsEmits domain metrics/logsSets alerting rules
Tool adapter frameworkOwnsAdds domain adaptersProvides credentials
Transactional data abstractionsOwns shared patternsDefines domain schemasOwns tenant data
Vector/graph memory abstractionsOwns shared patternsDefines domain retrieval usageOwns tenant memory scope
Memory tier modelOwns. The eight tiers, what each means, and which store is write-authoritative for itMust not add or redefine a tier. May define the shape of content for its own entitiesMust not redefine
Memory lifecycle mechanismOwns. Formation, consolidation, reflection, promotion, recall mediation, decay, erasure — and the agents that drive themMust not implement its own memory lifecycle or write durable memory except by proposing to os-agt-010Must not bypass
Memory promotion thresholdsOwns the mechanism — that a threshold is consulted before promotionMay declare recommended defaultsOwns the values. Minimum corroborating episodes, confidence floors, trajectories before a skill is distilled
Retention classes and erasure SLAsOwns the classes and the tombstone semanticsMay declare which class its entity types default toOwns the values. Window lengths, regulated floors and ceilings per jurisdiction, erasure response time
Per-agent memory scope (memory_profile)Owns the schema and the enforcement path through os-agt-012Declares each of its agents’ tier access and recall_scopeMay narrow a pack’s declaration, never widen it
Domain-specific entities & logicMust not ownOwnsConfigures
Domain-specific external adaptersMust not ownOwnsProvides credentials
Domain prompts/evaluatorsMust not ownOwnsMay tune instance-specific values
Domain KPIsProvides metric frameworkDefines KPI vocabularySets targets and alert thresholds
Secrets and credentialsMust not store domain secretsDeclares secret requirementsOwns actual secrets
Tenant branding and policy overridesMust not ownMay expose configurable fieldsOwns
Production execution permissionsOwns permission frameworkDeclares required scopesGrants actual scopes
Deployment mode declarationDefines the three modes and their validation rules. Owns air-gapped enforcement invariant.Must declare compatibility with business instance deployment mode. Must not declare cloud model URIs in air-gapped instances.Declares deployment mode (cloud-connected, self-hosted-hybrid, or air-gapped). Constrains all agent runtime policies in the instance. Cannot downgrade mode declared at OS level.
Local model selection and versionDefines the local inference integration interface (Ollama/vLLM). Does not own model selection.May recommend local model classes suitable for domain agent archetypes.Selects and pins specific local model versions. Owns local model infrastructure (hardware, GPU, model storage). Never sets model selection in OS-owned components.
External model API keysMust not own or store. Must not be referenced in OS-level configuration.Must not own or store. Must not be hard-coded in domain pack definitions.Owns and manages all external model API keys. Keys are environment secrets — never committed to source control or stored in canonical memory.
Domain-pack version pinningOwns the mechanism — the append-only registry and the rule that a new artifact version never propagates without an explicit pin.Publishes new versions to the shared registry; does not affect any running instance by publishing.Owns the value — declares and updates its own domain_pack_version pin via a governed, audited action.
Capability Module entitlementOwns the entitlement-flag mechanism and the rule that a module is inactive by default.Builds, versions, and declares depends_on for each Capability Module it offers.Owns the value — licenses/enables specific modules per instance via an explicit entitlement flag.
Business Instance Extension (BIE) registration and governanceOwns the registration schema (same agent registry schema) and governs every BIE-registered agent/workflow/hook through Policy Guard and Audit & Lineage.Declares the extension_points a BIE is permitted to hook; must not accept BIE hooks at undeclared points.Owns and authors the BIE itself — Extension ID, version, dependencies, agents, workflows, tools, policies, memory scope, events, hooks used, permissions, security scope. Non-reusable across instances.
Tenant definition and isolation boundaryOwns the model: the tenant as the contracting organisation, its relationship to a business instance, and the scoping rules every control-plane table must meet.Must not add tenant concepts, or read or write across tenants.Belongs to exactly one tenant and operates inside it. Does not define tenancy.
Tenant scoping of data tablesOwns the rules: non-null tenant_id, forced row-level security, tenant-led keys and composite same-tenant keys, and the reserved platform value for shared rows.Tables a pack adds must follow the same rules. Must not add columns to OS-owned tables. Where in the schema pack tables are classified is open.Does not alter the rules. Its business_instance_id is the inner scope key within its tenant.
Control-plane and data-plane boundary, and the data plane hosting variantDefines the boundary, the self-operated and managed variants, and the rule that Mode 3 is self-operated and a data plane is never pooled.Not applicable.Declares data_plane_operator (customer or synedrix), within the variants its deployment mode allows.
Identity: principals, organisations and users (draft)Defines principal types, the organisation as the tenant, and the credential claims. Does not hold personal data a pack or instance has no need to give it.Not applicable.Owns the user population inside its tenant and the choice of identity provider, within the limits for its deployment mode.
Role assignment (draft)Owns the six control roles, their derivations and the assignment record. Adds no role without a derivation.Declares approval points and reviewer roles for its workflows. May name pack roles, which map to control roles at the instance.Owns who holds each role, and the mapping from instance role names to control roles. Keeps at least one business instance owner at all times.
Service credentials between the planes (draft)Defines the rules: tenant-scoped, narrowest scope, rotatable, revocable, secret values never in a control-plane table.Declares required scopes.Provisions, rotates and revokes the credentials and owns the secret values.
Delegated authority and approval chains (draft; delegation, the chain model and separation of duties are proposals)Defines delegation (time-bound, same tenant, no re-delegation, approvals only), the chain model and separation of duties. Human approval never overrides Policy Guard.Declares the approval chain a workflow needs, by reviewer role.Assigns holders, sets timeouts and thresholds, and may revoke any delegation in its instance.
Support access to a managed tenant (draft)Defines the rule: granted by the tenant, time-bound, scoped, audited. No standing bypass role is reachable from a tenant path.Not applicable.Grants, scopes and ends the access.

The tenant is not a fourth column. A tenant is the boundary the three tiers operate inside, not a tier that owns capabilities of its own. Where a rule above says Business Instance, the instance acts within its tenant, and a tenant with several business instances does not gain authority over any of them that the instances do not already have. Where a managed offering is in use, Synedrix acts as the operator of the data plane and the pooled control plane, under the rules in the Tenancy Spec and the Identity and Access Spec, and holds no more access to a tenant’s data than those documents allow.

Draft rows. The five rows marked draft record the intended ownership from the Identity and Access Spec, which is itself a Draft. Delegation, the approval-chain model and separation of duties are proposals there, and separation of duties still needs a decision and possibly an emergency path. These rows are provisional until that specification is accepted, and they do not make the proposals canonical.

Not yet covered. Metering, the billing unit and entitlement enforcement are not given rows here. They wait for the metering decision (ADR-OS-012, not yet drafted), and adding rows now would assert ownership that has not been decided.

Human and agent accountability

The matrix above splits ownership across three tiers. It does not say who is accountable for a decision, as opposed to who owns the capability. ADR-OS-015 adds that second axis. Accountability sits with humans through the six OS-level control roles; execution sits with agents. The reading, the role derivations and the traced flows are in the AI-Native Org Chart, which defers to this matrix for tier ownership.

Control roleDerived fromDefined byHolder assigned by
human operatorescalation_path terminal of os-agt-001, os-agt-003, os-agt-009, os-agt-010, os-agt-011, os-agt-012Synedrix OSBusiness instance
human risk ownerescalation_path terminal of os-agt-002Synedrix OSBusiness instance
human domain stewardescalation_path terminal of os-agt-005, os-agt-006, os-agt-007, one per business functionSynedrix OS (the role); domain pack (that function’s behaviour, KPI vocabulary and approval points)Business instance
human compliance ownerescalation_path terminal of os-agt-008Synedrix OSBusiness instance
senior reviewernamed within os-agt-004’s escalation pathSynedrix OSBusiness instance
business instance ownerthis matrix, Business Instance column (Layer 12)Synedrix OSBusiness instance

Rules that follow from the split:

  • Synedrix OS owns the role set and its derivations. A role is added only with a derivation of the same kind. Domain packs and business instances instantiate these roles (trading-operator, mrd-owner) and never add to the set.
  • Which person, or how many people, hold a role is Business Instance configuration. This matrix and the AI-Native Org Chart do not specify it.
  • No agent holds accountability. An agent with decision_scope recommend, approve or execute acts inside its declared authority boundary, and every escalation path ends at a named human role or reaches os-agt-001 or os-agt-004.
  • Nothing here moves domain logic into the OS layer or relaxes an invariant.

Responsibility principles

1. OS owns the rules of the game

Framework-level concerns all domains depend on: orchestration, registry semantics, governance framework, observability model, shared contracts, and deployment mode validation rules.

2. Domain packs own business logic

Any logic requiring domain entities, domain tools, or domain policies.

3. Business instances own configuration and accountability

Secrets, enabled workflows, thresholds, approver mappings, tenant data, environment-level settings, deployment mode declaration, and local model infrastructure.

4. Deployment sovereignty is a first-class concern

The deployment mode declared by a business instance is a binding constraint on all agent runtime policies within that instance. No domain pack or OS component may override the deployment mode declared by a business instance. An air-gapped business instance is guaranteed to be air-gapped at the platform level — no component may make external API calls on its behalf.

flowchart LR
    OS["Synedrix OS: owns the rules of the game. Orchestration, registry semantics, governance framework, observability model, shared contracts, deployment mode validation rules"]
    DP["Domain Pack: owns business logic. Domain entities, domain tools, domain policies"]
    BI["Business Instance: owns configuration and accountability. Secrets, enabled workflows, thresholds, approver mappings, tenant data, environment settings, deployment mode declaration, local model infrastructure"]
    OS -->|"framework used by"| DP
    DP -->|"contributions configured by"| BI

Decision rule examples

  • New approval engine feature → Synedrix OS (shared governance primitive).
  • Domain-specific scoring heuristic → the relevant domain pack.
  • Per-store discount threshold → business instance.
  • New adapter contract type → OS owns the framework; the domain pack owns each specific implementation.
  • Choice of local model for a specific agent → business instance (model selection is tenant configuration).
  • Enforcement rule that air-gapped instances cannot use cloud URIs → Synedrix OS (deployment mode validation is a platform invariant).
  • OpenAI API key → business instance only. Never in the domain pack or the OS.
  • New Capability Module for an existing pack → the domain pack vendor (contributes to the shared registry, gated by entitlement).
  • A one-off refund workaround for a single customer → Business Instance Extension, never the domain pack.

Boundary enforcement rules

  • Domain packs must not bypass OS governance or observability.
  • Business instances must not fork shared OS abstractions for convenience.
  • Shared capabilities should be upstreamed into Synedrix OS rather than duplicated.
  • Pack-specific logic should never be merged into the OS without proving cross-domain reuse.
  • Domain packs must not declare cloud model URIs in agents that will be deployed in air-gapped business instances.
  • Model API keys must never appear in OS configuration, domain pack definitions, or source control. They belong exclusively to business instance secrets management.
  • Business instances must not register a BIE hook at an extension point the domain pack has not explicitly declared.
  • A domain pack must not silently affect a running instance by publishing a new version — activation requires the instance’s own pinned-version update.

Classification process

For any new capability:

  1. Is it reusable across multiple domains? → Synedrix OS
  2. Does it require domain-specific entities or tools? → Domain Pack
  3. Is it only a threshold, credential, environment setting, or deployment configuration? → Business Instance
flowchart TB
    N["New capability"]
    Q1{"Reusable across multiple domains?"}
    Q2{"Requires domain-specific entities or tools?"}
    Q3{"Only a threshold, credential, environment setting or deployment configuration?"}
    OS["Synedrix OS"]
    DP["Domain Pack"]
    BI["Business Instance"]
    N --> Q1
    Q1 -->|"yes"| OS
    Q1 -->|"no"| Q2
    Q2 -->|"yes"| DP
    Q2 -->|"no"| Q3
    Q3 -->|"yes"| BI

Versioning

  • Version: 0.7
  • Supersedes: v0.6

Canonical Reference

Core Principles and Taxonomy

Deployment

Agent Specifications

Domain Pack

Business Instance Extension and Capability Module

  • Synedrix OS ADR-OS-005 — Business Instance Extension and Capability Module — The decision record for this version’s three new rows.
  • Business Instance layer page — Expands the Business Instance column of the three new rows into the full BIE/Capability Module reference.

Synedrix OS · April 2026