{"slug":"strategy/product-strategy/PLATFORM","title":"PLATFORM","section":"strategy","sectionLabel":"Strategy","status":"unclassified","type":"document","path":"strategy/product-strategy/PLATFORM.mdx","bytes":5143,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: CURRENT\nScope: Platform capability model and boundaries\nCanonical Owner: Platform\nLast Verified: 2026-07-11\nEvidence Basis: docs/platform-specs/00-vision-doctrine.md through 34-system-lifecycle.md, docs/CANON.md, docs/platform-specs/\\_MASTER_INDEX.md, docs/platform-specs/\\_core-features.md, docs/platform-specs/\\_doctrine-and-sales-narrative.md, Option B evidence, wrangler manifests\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. WHAT THE PLATFORM IS\n\nThe platform owns operational capability.\n\nIt turns raw operational signals into canonical operational memory, allows intelligence to reason over that memory, proposes governed actions, executes approved actions, and preserves continuity.\n\nThe platform does not dictate human UX. It provides projection surfaces.\n\n---\n\n## 2. PLATFORM CAPABILITY MODEL\n\n```text\nINGEST\n→ NORMALIZE\n→ SYNTHESIZE\n→ CANONICALIZE\n→ REMEMBER\n→ UNDERSTAND\n→ PROPOSE\n→ GOVERN\n→ EXECUTE\n→ CONTINUE\n```\n\nEach capability may have:\n\n- a code implementation\n- a physical runtime identity or identities\n- a governed write authority\n- an operational boundary\n- a target service boundary\n- a historical service legacy\n\nImplementation existence does not prove operation. Service folder presence does not prove deployment. Deployment does not prove end-to-end activation.\n\n---\n\n## 3. PLATFORM LAYERS (INTERNAL ARCHITECTURE)\n\nThe platform may retain internal architectural layers. Platform internal structure can include:\n\n- Gateway\n- Integration Manager\n- Loader\n- Normalizer\n- Schema Synthesis\n- Spine Writer\n- Continuity\n- Knowledge\n- Hermes\n- Governance\n- Workflow\n- Capability Fabric\n- Store\n- Telemetry\n- Tenant context\n- Identity/session integration\n\nThese layers are not product navigation layers. A user may never directly interact with them. They are governed internal semantics.\n\n---\n\n## 4. PACKAGES AND SERVICES AS PRIMITIVES\n\n### 4.1 Packages\n\nCanonical definition:\n\n```text\nPackages are independently published reusable language or consumer/runtime libraries.\n```\n\nCanon does not require one package per service.\n\n### 4.2 Services\n\nCanonical definition:\n\n```text\nServices are independently deployed runtime identities.\n```\n\nService runtime boundaries follow:\n\n- authority domains\n- scaling domains\n- security domains\n- trigger domains\n- failure domains\n\n### 4.3 Runtime identities\n\nThe repository currently contains service folders that map to runtime identities. The presence of a folder or worker name does not prove that identity is canonical for that semantic stage.\n\nCurrent repository evidence must be verified against:\n\n- wrangler.toml manifests\n- current deployments\n- actual write authority traces\n- product routing evidence\n\nRetired or historical runtime identities include:\n\n- act\n- agent-registry\n- connector\n- folder-watcher\n- govern\n- intelligence\n- iw-agent-runtime\n- l2\n- pipeline\n- signals\n- think\n- twin-orchestrator\n\nEach must be classified:\n\n- CURRENT runtime\n- HISTORICAL runtime\n- PROPOSED collapse target\n- UNKNOWN\n\n---\n\n## 5. CAPABILITY FABRIC\n\nConceptual model:\n\n```text\nINTELLIGENCE\n      ↓\nCAPABILITY SELECTION\n      ↓\nPOLICY / GOVERNANCE\n      ↓\nEXECUTION\n      ↓\nRESULT\n      ↓\nCANONICAL CONTINUITY\n```\n\nCapability Fabric components must be classified individually:\n\n```text\nCapability Registry\nCapability Execution Engine\nWorkflow Router\nContext Builder\nExecution Orchestrator\nMetrics and learning structures\nCapability discovery UI\nCapability shell components\n```\n\nFor each component record:\n\n- Lifecycle: CURRENT | TARGET | MIGRATING | HISTORICAL | PROPOSED | UNKNOWN\n- Implemented: YES | NO\n- Wired: FULL | PARTIAL | UNKNOWN\n- Deployed: YES | NO | DORMANT | UNKNOWN\n- Verified E2E: YES | NO | UNKNOWN\n\nExample format required per component in CAPABILITY-FABRIC.md.\n\n---\n\n## 6. PLATFORM DOCTRINE\n\n1. No model owns canonical truth.\n2. No agent writes to Spine directly.\n3. The product asks WHAT it needs. The platform determines HOW it is produced.\n4. Packages are independently published reusable language and libraries.\n5. Services are independently deployed runtime identities.\n6. Runtime boundaries follow authority, scaling, security, trigger, and failure domains.\n7. The human product is L1.\n8. AI is a silent operational partner.\n9. Governance appears when policy requires it.\n10. Continuity is a system behavior, not merely a page.\n11. Repository presence does not prove operational readiness.\n12. Deployment success does not prove end-to-end operation.\n13. A route or client name does not prove canonical authority.\n14. Observed fact, inference, proposal, approval, execution, and canonical result are distinct semantic states.\n15. Historical implementation is evidence, not automatic architecture.\n\n---\n\n## 7. RETIRED-TECH BOUNDARY\n\nThe current product plane is Cloudflare-only.\n\nSupabase, Postgres, Redis, Vercel application hosting, n8n as IW infra, OpenWebUI, CouchDB, and VPS are retired from the product plane.\n\nHostinger/VPS is permitted for Customer Zero only, never for product operation.\n\nImplementation artifacts referencing retired tech must be documented as HISTORICAL unless actively targeted for migration.\n"}