{"slug":"business/33-configuration","title":"Configuration Manager","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/33-configuration.mdx","bytes":5197,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nThe Configuration Manager compiles how the platform behaves for a specific deployment, tenant, workspace, role, and policy context.\n\nFor canonical behavior, see `docs/spec/INTEGRATEWISE_CANONICAL_SPEC_v1.0.md` and `docs/platform-specs/` configuration-related specs.\n\n## Purpose\n\nThe Configuration Manager answers: how should this tenant operate right now?\n\nIt does not own secrets. Secrets are resolved by the Secrets Provider and injected at adapter edges.\n\n## Effective configuration precedence\n\nRuntime configuration is compiled from these layers:\n\n1. Platform Default\n2. Deployment Profile\n3. Environment Profile\n4. Tenant Configuration\n5. Tenant Policy\n6. Runtime Feature Policy\n\nNot every layer can override every field. Platform-only fields include:\n\n- mandatory audit\n- governance bypass prevention\n- tenant isolation\n- encryption floor\n- platform safety policy\n\nThese cannot be weakened by tenant configuration.\n\n## CompiledTenantConfig\n\nThe compiled output includes tenant identity, state bindings, Workbench composition rules, feature policy, memory policy, retention policy, AI runtime and provider policy, observability, notifications, capabilities, governance references, and approval policy.\n\nRecompilation is triggered by authorized changes to configuration, deployment profile, tenant policy, provider bindings, feature policy, or schema/version migration.\n\n## Version pinning\n\nCompiled configurations are assigned monotonic version identifiers when used for execution decisions. ExecutionPlans pin the exact config version they were generated under. Mid-flight configuration updates do not change active execution paths.\n\nHistorical configurations are retained for audit and rollback within retention policy windows.\n\n## Runtime materialization boundary\n\nA configuration declaration is not an active runtime. Configuration defines what\nis permitted; it does not itself make a provider, component, or route usable.\n\n```text\nConfiguration Manager\n  → CompiledTenantConfig\n  → Wiring Resolver\n  → ResolvedRuntimeBindings\n  → Activation Manager\n  → ActivatedRuntimeManifest\n  → Routing Manager\n  → InvocationRoute\n```\n\nThe responsibilities are intentionally non-overlapping:\n\n- **Configuration Manager** defines policy, bindings, preferences, fallbacks,\n  and the versioned set of possibilities.\n- **Wiring Resolver** turns that configuration into concrete binding references.\n- **Activation Manager** verifies and materializes those bindings: contract\n  compatibility, health, resource readiness, connection state, and capability\n  registration.\n- **Routing Manager** selects only from the activated manifest for a particular\n  invocation. It cannot invent a provider or a component binding.\n\nHermes receives an authorized plan with an already activated route. It\ncoordinates execution; it never discovers infrastructure. An activation failure\ntherefore removes or degrades a route rather than silently changing the\narchitecture at execution time.\n\n### Current Workbench runtime implementation\n\nThe connected-action path implements this boundary in Gateway today:\n\n1. `tenant_spine_config.connected_connectors` is the current persisted tenant\n   configuration input. It can only narrow the explicit deployment bootstrap\n   profile; it cannot introduce a provider, adapter, endpoint, or capability.\n2. The Wiring Resolver compiles that allow-list into known capability bindings.\n3. Activation matches only `active` or `connected` records from\n   `tenant_integrations`, producing an immutable manifest for the request.\n4. Routing selects a capability only from that manifest. A plan pins its\n   manifest version and Gateway verifies the same activated route again at\n   approval time.\n\nThe shared-D1 migration `sql-migrations/d1/012_workbench_runtime_wiring.sql`\nprovides the configuration, connection, focused-Spine, and active-work-context\ntables required by this path. The next platform increment is a persistent full\n`CompiledTenantConfig` service and durable provider-health activation registry;\nthe current adapter intentionally keeps those responsibilities out of Hermes\nand the browser.\n\n## Swappable provider architecture\n\nThis is not optional. Product code must not import provider SDKs directly. Deployment configuration selects implementations; application architecture does not.\n\nThis rule matters for partners and developers because extension points are contract-based, not SDK-based. Build against contracts. Do not vendor-lock custom adapters to product code paths.\n\n## Extension behavior\n\nExternal configurations and custom integrations should respect tenant policy boundaries. Extension modules should not assume they can override platform safety, governance, audit, isolation, or retention settings.\n\nPartners doing custom deployment profiles must preserve platform-only immutability guarantees.\n\n## Operational considerations\n\nChanges to effective configuration can:\n\n- alter capability availability\n- change provider fallback behavior\n- modify memory or retention rules\n- affect feature exposure\n- invalidate cached runtime state\n\nTreat configuration changes as potentially breaking compatibility with in-flight operations.\n"}