{"slug":"internal/architecture/PRODUCT_STATEMENT_RECONCILIATION_2026-08-13","title":"Product Statement Reconciliation — 2026-08-13","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"document","path":"internal/architecture/PRODUCT_STATEMENT_RECONCILIATION_2026-08-13.mdx","bytes":7827,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Product-source input and reconciliation record. Not an independent\narchitecture authority.  \n**Precedence:** [`INTEGRATEWISE_ARCHITECTURE.md`](INTEGRATEWISE_ARCHITECTURE.md), as\namended by [`SPEC_AMENDMENTS_v1.md`](SPEC_AMENDMENTS_v1.md), remains authoritative.\n\n## Purpose\n\nThis record translates the founder product narration supplied on 2026-08-13 into\ntestable product and architecture decisions. It gives product, design, and implementation\nwork one concise interpretation without replacing the canonical architecture or turning\nruntime support systems into customer-facing products.\n\n## Product, in one sentence\n\n**IntegrateWise Workbench is a connected, self-organizing workspace that assembles the\nright context from approved sources, projects it for each person's role, and keeps people\nin control of every consequential action.**\n\nThe Spine, OneAuth, Loader, Normalizer, MCP pool, intelligence, pipeline, governance,\nand provider execution are the runtime that makes that experience possible. They are not\nseparate end-user products.\n\n## Confirmed product decisions\n\n| Decision                                                                             | Product consequence                                                                                                                                                    | Canonical basis            |\n| ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- |\n| One connected Workbench replaces tool-juggling for daily work.                       | Public product language leads with a single operational surface, not a suite of departmental apps.                                                                     | Architecture §§2.4, 11, 16 |\n| A tenant has one connected Spine.                                                    | Role, department, and task change projections; they do not create databases or separate products.                                                                      | §§2.4, 9, 11               |\n| Flow D precedes every observation.                                                   | Identity, tenant, policy, connection binding, and grants resolve before A/B/C ingestion.                                                                               | §9                         |\n| Flow A/B/C classify input authority.                                                 | Structured observations, evidence/unstructured material, and model interpretations have distinct promotion paths. Flow C is candidate material, never automatic truth. | §9                         |\n| Loader and Normalizer reduce source-specific material into governed, useful context. | The Workbench and Twin consume projections and bounded context, never raw provider tables as product truth.                                                            | §§7–9                      |\n| The Twin is contextual and proactive only within a Workbench task.                   | It prepares grounded context and proposals; it is not a generic public chatbot and cannot act on its own.                                                              | §§2.5, 12                  |\n| Connected-tool actions return to their source through governed capability execution. | No provider mutation without a capability, policy/approval, Hermes coordination, outcome capture, re-ingestion, and reconciliation.                                    | §10                        |\n| MCP/Plugin distribution connects hosts to the same governed runtime.                 | Marketplace listings and MCP Pool are activation/distribution channels, not parallel workspaces or authority bypasses.                                                 | §16                        |\n\n## The experience to build and market\n\n1. A person opens one Workbench rather than reconstructing work across mail, CRM,\n   support, documents, project tools, and AI chats.\n2. Their role-scoped projection shows the relevant account, task, timeline, evidence,\n   connected records, freshness, and permitted next actions.\n3. Context assembly uses the canonical subject/task identity to retrieve relevant bounded\n   operational context.\n4. The Silent Twin may surface a concise preparation or draft alongside that work.\n5. The person approves or rejects a consequential proposal. Governance and Hermes execute\n   only the approved capability; the observed outcome returns through ingestion and\n   reconciliation.\n\nThis is the visual story for marketing and the acceptance story for product delivery. A\nmarketing page must not present Brand Store, Book of Records, Org Memory, Hermes, or raw\nstorage as a public solution. Brand Store and Book of Records/Org Memory remain internal\nsurfaces/projection concepts under the current public/internal taxonomy.\n\n## Reconciliation required before changing the canonical storage model\n\nThe supplied product narration says the Spine is a combination of databases and JSONB,\nwith a protected canonical store and an operational store accessible to bounded consumers.\nThe current canonical architecture says **Neon is canonical truth** and D1/KV are bounded\noperational state/projections. These are compatible only if “Spine” means the overall\ngoverned data system while **one writer/authority remains canonical**.\n\nUntil a formal amendment says otherwise, implementation must preserve these rules:\n\n- No LLM, external agent, MCP client, or browser receives direct canonical-store access.\n- The operational store is a bounded, tenant/actor/policy-scoped read model; it is not an\n  alternative canonical writer.\n- JSONB, vector/search indexes, documents, caches, and event material can support context\n  assembly but do not bypass provenance, promotion, or governance.\n- Model-generated conversation interpretation is Flow C and requires the established\n  promotion path before it becomes organisational truth.\n\n## Acceptance checks derived from the statement\n\n- Flow D is required before each Flow A, B, or C ingestion route accepts data.\n- A projection is tenant-, actor-, policy-, and freshness-aware; a missing live view does\n  not become seed/demo data.\n- A Workbench exposes projections and permitted capabilities, never raw credential,\n  canonical-store, or provider-execution controls.\n- A Twin proposal carries its bounded context/evidence and has no execution path that\n  skips governance.\n- A provider outcome is re-ingested, reconciled, and reflected through a refreshed\n  projection rather than assumed successful by the UI.\n- Public marketing routes describe the Workbench and its use cases; internal control\n  surfaces remain outside the public solution taxonomy.\n\n## Follow-up decisions\n\n1. **Canonical storage wording:** Confirm whether the intended “multi-store Spine” is an\n   implementation topology with Neon retaining canonical-writer authority, or a deliberate\n   replacement of that authority model. This is a governance decision, not a copy edit.\n2. **Operational access contract:** Define the exact service/API contract by which approved\n   models and external agents receive bounded operational context; direct database access is\n   not implied by the product statement.\n3. **Initial creamy-layer connectors:** Select the first source set and the concrete Flow\n   A/B classifications, schema mappings, revocation behavior, and reconciliation evidence.\n4. **MCP Pool tenancy:** Confirm whether its publication/binding unit is tenant, user, or a\n   tenant-scoped user grant. This must follow Flow D and cannot be inferred from hostname.\n"}