Product Statement Reconciliation — 2026-08-13

Status: Product-source input and reconciliation record. Not an independent
architecture authority.
Precedence: INTEGRATEWISE_ARCHITECTURE.md, as
amended by SPEC_AMENDMENTS_v1.md, remains authoritative.

Purpose

This record translates the founder product narration supplied on 2026-08-13 into
testable product and architecture decisions. It gives product, design, and implementation
work one concise interpretation without replacing the canonical architecture or turning
runtime support systems into customer-facing products.

Product, in one sentence

IntegrateWise Workbench is a connected, self-organizing workspace that assembles the
right context from approved sources, projects it for each person's role, and keeps people
in control of every consequential action.

The Spine, OneAuth, Loader, Normalizer, MCP pool, intelligence, pipeline, governance,
and provider execution are the runtime that makes that experience possible. They are not
separate end-user products.

Confirmed product decisions

Decision	Product consequence	Canonical basis
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
A tenant has one connected Spine.	Role, department, and task change projections; they do not create databases or separate products.	§§2.4, 9, 11
Flow D precedes every observation.	Identity, tenant, policy, connection binding, and grants resolve before A/B/C ingestion.	§9
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
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
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
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
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

The experience to build and market

1. A person opens one Workbench rather than reconstructing work across mail, CRM,
   support, documents, project tools, and AI chats.
2. Their role-scoped projection shows the relevant account, task, timeline, evidence,
   connected records, freshness, and permitted next actions.
3. Context assembly uses the canonical subject/task identity to retrieve relevant bounded
   operational context.
4. The Silent Twin may surface a concise preparation or draft alongside that work.
5. The person approves or rejects a consequential proposal. Governance and Hermes execute
   only the approved capability; the observed outcome returns through ingestion and
   reconciliation.

This is the visual story for marketing and the acceptance story for product delivery. A
marketing page must not present Brand Store, Book of Records, Org Memory, Hermes, or raw
storage as a public solution. Brand Store and Book of Records/Org Memory remain internal
surfaces/projection concepts under the current public/internal taxonomy.

Reconciliation required before changing the canonical storage model

The supplied product narration says the Spine is a combination of databases and JSONB,
with a protected canonical store and an operational store accessible to bounded consumers.
The current canonical architecture says Neon is canonical truth and D1/KV are bounded
operational state/projections. These are compatible only if “Spine” means the overall
governed data system while one writer/authority remains canonical.

Until a formal amendment says otherwise, implementation must preserve these rules:

• No LLM, external agent, MCP client, or browser receives direct canonical-store access.
• The operational store is a bounded, tenant/actor/policy-scoped read model; it is not an
  alternative canonical writer.
• JSONB, vector/search indexes, documents, caches, and event material can support context
  assembly but do not bypass provenance, promotion, or governance.
• Model-generated conversation interpretation is Flow C and requires the established
  promotion path before it becomes organisational truth.

Acceptance checks derived from the statement

• Flow D is required before each Flow A, B, or C ingestion route accepts data.
• A projection is tenant-, actor-, policy-, and freshness-aware; a missing live view does
  not become seed/demo data.
• A Workbench exposes projections and permitted capabilities, never raw credential,
  canonical-store, or provider-execution controls.
• A Twin proposal carries its bounded context/evidence and has no execution path that
  skips governance.
• A provider outcome is re-ingested, reconciled, and reflected through a refreshed
  projection rather than assumed successful by the UI.
• Public marketing routes describe the Workbench and its use cases; internal control
  surfaces remain outside the public solution taxonomy.

Follow-up decisions

1. Canonical storage wording: Confirm whether the intended “multi-store Spine” is an
   implementation topology with Neon retaining canonical-writer authority, or a deliberate
   replacement of that authority model. This is a governance decision, not a copy edit.
2. Operational access contract: Define the exact service/API contract by which approved
   models and external agents receive bounded operational context; direct database access is
   not implied by the product statement.
3. Initial creamy-layer connectors: Select the first source set and the concrete Flow
   A/B classifications, schema mappings, revocation behavior, and reconciliation evidence.
4. MCP Pool tenancy: Confirm whether its publication/binding unit is tenant, user, or a
   tenant-scoped user grant. This must follow Flow D and cannot be inferred from hostname.