Business Instance

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

Scope of this page. Reference material for the Business Instance 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 Business Instance Layer configures a concrete runtime. Everything above it — the OS layers and whichever domain packs are selected — is a reusable definition; this layer is where that definition becomes one customer’s actual deployment: which packs are enabled, what credentials it holds, what thresholds and approvers apply, what environment it runs in, and which of the three deployment modes it runs under.

Nothing at this layer is reusable across instances by construction — that is the point of it. A threshold, a credential, or a tenant override is meaningful to exactly one deployment and must never leak upward into a domain pack’s own definition or, worse, into the OS itself. This is also the layer where deployment sovereignty is enforced: the mode a business instance declares is a binding constraint on every agent runtime policy within it, and no domain pack or OS component may override it.

flowchart LR
  n1([Business Instance]):::term
  subgraph What it owns
    n2[Tenant configuration and environment settings]:::agent
    n3[Credentials and secrets]:::agent
    n4[Thresholds and approver mappings]:::agent
    n5[Domain pack selection]:::agent
    n6[deployment mode]:::agent
    n7[domain pack version]:::agent
    n8[Entitlement flags]:::agent
  end
  n1 --> n2
  subgraph What it must not own
    n9[Shared platform abstractions themselves]:::warn
    n10[Synedrix OS]:::term
    n9 --> n10
    n11[Domain-specific entities agents workflows and business logic]:::warn
    n12[Domain Pack Layer]:::term
    n11 --> n12
    n13[The local-model integration interface]:::warn
    n14[Synedrix OS]:::term
    n13 --> n14
  end
  n1 --> n9
  subgraph Interfaces with
    n15[Synedrix OS]:::check
    n16[Selected domain packs]:::check
  end
  n1 --> n15

What it owns link

Per the Layer Taxonomy Table, the Business Instance Layer owns:

• Tenant configuration and environment settings
• Credentials and secrets (including external model API keys)
• Thresholds and approver mappings
• Domain pack selection — which packs are enabled for this instance
• deployment_mode — cloud-connected, self-hosted hybrid, or air-gapped
• domain_pack_version — the pinned version of each enabled domain pack this instance actually runs, updated only via an explicit governed action, never floated to the latest published version automatically
• Entitlement flags — which Capability Modules and which Business Instance Extension (BIE) version are active for this instance

What it must not own link

A business instance configures the platform; it does not get to fork the shared abstractions it configures.

Interfaces with link

A business instance is the point where the OS and a domain pack’s declared configuration surface both meet real values, so it interfaces with both:

• Synedrix OS — the instance declares deployment_mode against OS-owned validation rules; an air-gapped instance is guaranteed air-gapped at the platform level because the OS enforces the invariant, not because the instance promises to honor it.
• Selected domain packs — each enabled pack declares an instance-configurable surface (enabled workflows, thresholds, approver mappings, secrets, environment routes, tenant overrides per the Domain Pack Template §12); the instance supplies the concrete values within that surface and may narrow but never widen what a pack has declared.

Business Instance Extensions link

Per ADR-OS-005, a Business Instance Extension (BIE) is customer-specific, non-reusable content registered inside a single business instance — a governed overlay within this layer, not a numbered layer of its own. A BIE contributes configuration values, tenant policy parameters evaluated by the OS Policy Guard, workflow hooks at extension points a domain pack explicitly declares (§12.1 of the Domain Pack Template), client-specific agents registered through the shared agent registry schema (see Agent Registry §6.1), and adapter/integration mappings.

The line that separates a BIE from a domain pack’s own Capability Module is the same non-reusability rule stated above: a BIE is “meaningful to exactly one deployment” and must never be reused across instances. A Capability Module is the opposite — a reusable, independently versioned, licensable sub-package a domain pack vendor builds once and multiple instances entitle independently. Confusing the two miscategorizes the artifact: single-instance, non-reusable customization is a BIE; anything a vendor intends to sell to more than one instance belongs one layer up, as a Capability Module.

A domain pack workflow hook is never a per-customer edit to the pack’s own n8n canvas. The pack declares a named extension point once, as part of its own version; a BIE’s hook attaches to it either as a decoupled publish-event/trigger_type: event pair (the default, for non-blocking hooks) or, only when the hook must block the parent, as an instance-scoped Execute Workflow sub-workflow lookup. Either way the hook is always its own full workflow contract, governed identically to any other workflow.

Current specification depth link

Current specification depth. No document in this repository is centered on the Business Instance layer itself — there is no single “Business Instance Spec.” What exists is two documents that each cover part of what this layer owns, plus the one-line row in the Layer Taxonomy Table. Treat this page as the honest current state of specification depth, not as a substitute for a unified spec that has not been written.

Deployment Model Spec is the authority for deployment_mode itself. It defines the three canonical modes — Mode 1 (cloud-connected, all platform components self-hosted, model inference over external APIs), Mode 2 (self-hosted hybrid, model inference split per agent between cloud and local via Ollama/vLLM, declared through model_type: cloud | local in each agent’s runtime policy), and Mode 3 (air-gapped, all inference local, no outbound connections; the single accepted external dependency is the inbound managed Hookdeck event gateway) — together with the platform invariant that an instance declared deployment_mode: air-gapped cannot contain any agent runtime policy with a cloud model URI in primary_model or fallback_model. It also carries the open-source component inventory, local-model configuration reference for Ollama and vLLM, and the air-gapped deployment checklist an instance must satisfy before it can be declared Mode 3.

Responsibility Matrix covers the instance-level ownership rows rather than the deployment modes themselves. Its capability table assigns the business instance column ownership of secrets and credentials, tenant branding and policy overrides, thresholds, approver mappings, and — under the three rows added for deployment sovereignty — the deployment mode declaration itself, local model selection and version pinning, and external model API keys. Its own §4 (“Deployment sovereignty is a first-class concern” — not to be confused with Core Principle 11, which this section implements) states the binding-constraint rule directly: the deployment mode a business instance declares constrains every agent runtime policy in that instance, and no domain pack or OS component may override it.

Together the two documents describe this layer’s real behavior; neither one is written as a page about the layer as a whole, which is the gap this page fills descriptively without inventing a spec that does not exist.

Rule of inclusion link

The boundary between this layer and the two layers above 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: a value only ever belongs here if it is a threshold, a credential, a tenant setting, or a deployment-mode choice — anything with cross-instance reusability has already been mis-scoped, whether it should have been an OS primitive or a domain pack default. A governed customization that is specific to this instance and will never be reused elsewhere belongs here as a Business Instance Extension; a governed customization the pack vendor intends to sell to more than one instance belongs one layer up, as a domain pack’s Capability Module.

OS agents at this layer link

No OS-owned agent is assigned to this layer, and none is expected to be. Per the Agent Registry §3, the twelve OS agents sit at Layers 3, 4, 5, 7, 9, and 10 only. Layer 12 is pure configuration — credentials, thresholds, pack selection, deployment_mode — with no execution or reasoning of its own to warrant an agent. Those values are read by agents operating at other layers (for example, an agent’s runtime policy resolving model_type: cloud | local from the instance’s declared deployment_mode, or the Policy Guard Agent evaluating a proposed action against an instance-set threshold); they are never owned or acted on by an agent stationed here.

Related Synedrix OS documents link

• Layer Taxonomy Table — the authoritative row for this layer.
• Deployment Model Spec — the three deployment modes, deployment_mode itself, and the air-gapped enforcement invariant.
• Synedrix OS - Responsibility Matrix — the business-instance ownership rows and the deployment-sovereignty principle.
• Synedrix OS - Domain Pack Template §12 — the instance-configurable surface a domain pack must declare, including §12.1 extension points and §12.5 Capability Modules.
• Domain Pack — the layer immediately above, whose declared configuration surface this layer fills with concrete values.
• Synedrix OS ADR-OS-005 — Business Instance Extension and Capability Module — the decision record for this page’s Business Instance Extensions section.
• Synedrix OS - Agent Registry §6.1 — the schema and invariants every Business Instance Extension agent must satisfy.

Synedrix OS · Layer reference · Business Instance