{"slug":"business/20-operations-runbooks","title":"20 — Operations Runbooks","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/20-operations-runbooks.mdx","bytes":6495,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Extracted from:** IntegrateWise Platform Specification Suite\n> **Region:** first_pass\n> **Original line:** 1342\n> **Lines:** 107 | **Chars:** 6,165\n> **Status:** Raw extraction — requires review and canonicalization\n\n20 — Operations Runbooks\n20.1 Daily motion runbook\nMorning brief sanity, Promotion Queue SLAs, Connector healthcheck dashboard review.\n20.2 Incident runbooks\nP0: Twin down → revert to “Last Good Answer” projection.\nP0: Connector down → triage by vendor, Nango re-auth, soft-sync queue flush.\nP1: Spine write failures → DO alarm, retry, manual rebuild.\nP2: Signal lag → check rule DSL hot-reload.\n20.3 Compliance runbook\nQuarterly RBAC review.\nAnnual encryption & key rotation.\n20.4 DR runbook\nR2 snapshot restore flow in https://docs.integratewise.ai/runbooks/dr.\nProduct Specifications (now formalized)\nP-1 Universal Search\nIndexes Spine (02), Memory (07), Knowledge (07).\nCursor pagination, persona-scoped filters.\nSurfaces across Workbench and Command Palette.\nP-2 Global Command Palette\nBound to ⌘K, surfaces Workspace switch, Twin invocation, Capability trigger.\nContextual based on persona and screen state (04).\nP-3 Notification Center\nTriage of Signal surfaced, GovernanceRequested, MemoryApproved events.\nPer-user mute & digest cadence.\nP-4 Activity Center\nUnified feed of tl\\_ events scoped to the workspace.\nFilter by entity kind, actor, connector.\nP-5 Timeline UI\nRead view of Timeline; reverse-chronological with as-of toggle.\nEntity detail “history” tab uses the same component.\nP-6 Entity Detail Framework\nOne component render across all AggregateEntity types.\nTabs: Overview, Activity, Evidence, Signals, Capabilities, Memory.\nP-7 Dashboard Composition Engine\nServer-rendered, declarative JSON → React hierarchy.\nVersioned dashboards per persona.\nP-8 Widget SDK\nCustom widget authoring; binding to Spine reads and Twin intents.\nSandbox iframe with capability allowlist.\nP-9 Extension SDK\nWorkspace-scoped extensions; install via Marketplace (13).\nP-10 Theme / Design Token Specification\nSee 18.1.\nEngineering Specifications (now formalized)\nSpec Doc location Key points\nAPI versioning 19.1 date-based namespaces; 6-mo deprecation\nSDK contracts 17 semver; breaking changes gated by MAJOR + migration\nError model 19.2 stable codes; trace_id correlation\nPagination 19.3 cursor; ≤1000 limit\nCursor strategy 19.3 ?cursor=…&limit=…; opaque, sign+expiry\nFeature flags 19.4 X-IW-Feature-Flags; tenant scope override\nConfiguration system 19.5 server-driven; tenant + experiment + flag\nTesting strategy 19.6 contract tests; synthetic tenant bed\nMigration strategy 15.4 reversible; dry-run; bumping schema_version\nRelease strategy 15.3 flag-gated dark launch; progressive\nCross-spec runtime contracts (consolidated)\nThe user’s most important gap — runtime contracts between components — is now satisfied because every subsystem from 02–13 contains the same Responsibilities / Inputs / Outputs / Events Produced / Events Consumed / APIs / State Transitions / Failure Handling / Extension Points structure. Any engineer updating one component can read the canonical Events Consumed and APIs columns of the consumers/producers and reason about the change surface.\n\nThe single canonical cross-spec rule for evolving the platform:\n\nUpdate the Spine (02) entity or event vocabulary first.\nUpdate producers (03–13) to emit the new event name.\nUpdate consumers (03–13) to declare the new event in Events Consumed.\nBump tenant_spine_config.schema_version (m054+) and write a migration (15.4).\nRoll out under feature flag (15.3 / 19.4).\nEvery doc above follows that rule, so the suite is internally consistent and the existing Marketplace Onboarding & Persona Architecture spec remains the authoritative reference for OAuth, the 12×11 Matrix, L0.5–L4, Memory Pipeline, and Capability Fabric — while the 21 docs here supply the runtime, marketplace lifecycle, observability, security, deployment, and product-surface machinery the platform was missing.\n\nPasted markdown (1).md\n84.36 KB\nOne doc end tn end\nSource file appears identical in size (86388 bytes) to the prior one but at a different wrapper URL. I’ll re-confirm the existing spec via the index from the previous round, then deliver the entire 21-doc suite in one continuous inline document, fully written out with no placeholders.\nIntegrateWise — Unified Platform Specification (00–20)\nCompanion to IntegrateWise — Marketplace Onboarding & Persona Architecture (m054+). The original spec defined Marketplace OAuth, the Onboarding Interstitial, the 12×11 Matrix, L0.5/L1/L2/L3/L4 operating layers, the 8-Layer Memory Pipeline, the Capability Fabric (Soft/Real/Propose sync modes), and the Morning Brief / Twin interaction model. This unified document supplies everything that spec referenced but did not define: the Operational Spine, runtime contracts for every subsystem, SDKs, governance runtime, marketplace lifecycle, security, deployment, observability, and the engineering / product surfaces required to evolve the platform.\n\nThis is a single continuous end-to-end document. Every section below is fully written out in sequence; no “see above” placeholders.\n\nUnifying Doctrines (held constant across every doc below)\nDistribution is ingress — every AI assistant marketplace is a tenant-acquisition channel.\nTruth you own — the Spine is canonical; AI tools are projections.\nAI you rent — the LLM provider is plumbable via Cloudflare AI Gateway; no vendor lock.\nApproval in between — every write that crosses a system boundary passes through the Governance Engine.\nOne capability, every surface — the same cap*id resolves identically in Workbench, Twin, Chat, CLI, Slack, Mobile.\nContinuity over asking — the Spine is the source of context; the Twin never re-asks.\nPersona barrier — tenant_spine_config.industry × department defines the visible universe; users cannot pivot roles by widening scope.\nHard gates are non-negotiable — Soft-sync defaulting, 5-minute first-data-load, Promotion-Queue human approval.\nCanonical ID Prefixes (used in every section below)\nPrefix Domain\ntnt* Tenant\nwsp* Workspace\nusr* User\nent* Entity (any domain object)\nrel* Relationship\ntl* Timeline entry\nact* Activity\nevd* Evidence\nsig* Signal\ncap* Capability\nmem* Memory\nknw* Knowledge\ntw* Twin\nprj* Projection\nevt* Bus event\nwf* Workflow\ngov* Governance token\nobs* Observability record\nmkt* Marketplace listing\nconn\\_ Connector\n"}