{"slug":"strategy/product-strategy/PRODUCT","title":"PRODUCT","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/product-strategy/PRODUCT.mdx","bytes":5711,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Tier C — Historical.** This document is a point-in-time snapshot preserved for reference. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\nStatus: CURRENT\nScope: Product identity, target grammar, boundaries\nCanonical Owner: Product\nLast Verified: 2026-07-11\nEvidence Basis: docs/CANON.md, docs/architecture/PRODUCT_ARCHITECTURE.md, docs/architecture/WORKBENCH_DOCTRINE.md, docs/platform-specs/\\_MASTER_INDEX.md, Option B evidence\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. WHAT INTEGRATEWISE IS\n\nIntegrateWise is operational continuity infrastructure with governed intelligence.\n\nIt preserves unified operational context across fragmented systems, normalizes that context into canonical form, and allows intelligence and action to be proposed, governed, executed, and remembered.\n\nProduct name in current canon: IW Continuity Bridge\nCategory: The Operational Continuity Platform\n\nJurisdiction: human operational context\nAudience: tenants, operators, internal system actors\nExperience surface: L1 Workbench\n\n---\n\n## 2. PLATFORM AND PRODUCT DISTINCTION\n\n```text\nPLATFORM = capability\nPRODUCT  = L1 experience\n```\n\nPLATFORM delivers capability:\n\n- ingest, normalize, synthesize, canonicalize, remember, understand, propose, govern, execute, continue\n\nPRODUCT delivers human experience:\n\n- context lens, entity collection, entity 360, activity, intelligence, action, governance when required, execution state, continuity\n\nThey share data and behavior. They are not the same surface and must not be documented interchangeably.\n\n---\n\n## 3. PRODUCT TARGET ARCHITECTURE\n\n### 3.1 Surface Target: L1 Workbench\n\nThe human product is L1.\n\nCurrent repositories and documentation contain multiple app directories and multiple workbench narratives. Those are implementation evidence and historical choice, not target product architecture.\n\nTarget product boundary:\n\n- one L1 Workbench surface\n- one tenant context at a time\n- one entity collection/entity 360/activity/intelligence/action/execution/continuity grammar\n- Twin buttons (OODA): Store in Spine, Ask Your Twin, Assign Your Twin, Approve Twin's Action\n\nTwin is a silent partner inside L1, not a separate chat surface.\n\n### 3.2 What L1 is not\n\nL1 is not:\n\n- a separate Department Workbench product per department\n- a separate Twin Workbench product\n- a separate Governance Workbench product\n- L2/L3 as separate user-visible layers\n- CRM merely because Lead entities exist\n- Backend itself exposed as product surface\n- Service runtime exposed as product surface\n\nDepartment knowledge is a Context Lens unless repository evidence separately authorizes a product boundary.\n\n### 3.3 Product grammar\n\n```text\nCONTEXT LENS\n→ ENTITY COLLECTION\n→ ENTITY 360\n→ ACTIVITY\n→ CONTEXTUAL INTELLIGENCE\n→ ACTION\n→ GOVERNANCE WHEN REQUIRED\n→ EXECUTION STATE\n→ CONTINUITY\n```\n\nThis grammar applies to all roles and contexts. Same entity, different lens = different operational emphasis.\n\n---\n\n## 4. ENTITY AND KNOWLEDGE BOUNDARIES\n\nDomain knowledge such as Account Success, Revenue Operations, Sales Operations, Finance, Marketing, HR/People, Product and Engineering, Business Operations, IT Administration, Services, and Procurement are Context Lenses.\n\nThey are not separate products unless a separately authorized boundary is established.\n\n---\n\n## 5. FRONTEND APP REALITY\n\nCurrent repository contains:\n\n- apps/web\n- apps/workspace\n- apps/desktop\n- apps/mobile\n- apps/docs\n\nCanonical target is `apps/web`.\n\nIf another app directory currently hosts the strongest corpus, that is an implementation-state observation, not a target boundary.\n\nClassification table:\n\n| App            | Lifecycle                | Deployment Status | Product Role                                | Canonical Target | Notes                                                                                    |\n| -------------- | ------------------------ | ----------------- | ------------------------------------------- | ---------------- | ---------------------------------------------------------------------------------------- |\n| apps/web       | TARGET                   | UNKNOWN           | canonical L1 product application            | YES              | Must be evaluated against Next.js/Vercel entanglement and Vite target                    |\n| apps/workspace | CURRENT/CURRENT_EVIDENCE | UNKNOWN           | integrated runnable product corpus evidence | IF holds corpus  | Separate evaluation required; preserve evidence, do not declare canonical until verified |\n| apps/desktop   | HISTORICAL/UNKNOWN       | UNKNOWN           | Electron wrapper                            | NO               | Wraps web app; does not establish product boundary                                       |\n| apps/mobile    | HISTORICAL               | placeholder       | placeholder                                 | NO               |                                                                                          |\n| apps/docs      | UNKNOWN                  | UNKNOWN           | docs-only app                               | UNKNOWN          |                                                                                          |\n\nDo not document department surfaces as separate product architectures.\n\n---\n\n## 6. RELEVANT DOCUMENT CLASSIFICATION\n\n- `docs/architecture/PRODUCT_ARCHITECTURE.md` — primary product front door\n- `docs/architecture/WORKBENCH_DOCTRINE.md` — L1 projection grammar\n- `docs/architecture/WORKBENCH_DOCTRINE.md` must be read alongside this document and reconciled to eliminate separate Human/Twin/Governance/Knowledge/Domain Workbenches as product boundaries.\n"}