{"slug":"documentation/DOCUMENTATION_CONTRADICTION_MAP","title":"DOCUMENTATION CONTRADICTION MAP","section":"documentation","sectionLabel":"Documentation","status":"unclassified","type":"document","path":"documentation/DOCUMENTATION_CONTRADICTION_MAP.mdx","bytes":14779,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"> **Tier C — Historical.** This document is a point-in-time snapshot. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\n# DOCUMENTATION CONTRADICTION MAP\n\nStatus: CURRENT\nScope: Integratewise-live repository contradictions between documented claims, Tier A canon, repository manifests, and Option B evidence\nCanonical Owner: Hermes / Documentation reconciliation\nLast Verified: 2026-07-11\nEvidence Basis: docs/ + root markdown inventory, wrangler manifests, Option B branch divergence audit, docs/CANON.md, docs/FINAL_E2E_SYSTEM.md\nSupersedes: none\nSuperseded By: canonical docs reconciliation set in later phases\n\nThis file records contradictions only. It does not prescribe order. Do not treat any “warning” as a recommendation to delete docs. When contradictions are related to code/docs divergence, prefer preserving documents as evidence and routing actual mutation to remediation branches.\n\n---\n\n## 1. HOW TO READ THIS MAP\n\nEach entry records a contradiction domain, the docs/claims involved, the repository/branch evidence, and the classification. Where multiple docs state conflicting truths, they are preserved but flagged. The goal is not to destroy history — the goal is to stop contradictions from being presented as coherent canonical truth.\n\n---\n\n## 2. README RUPTURE\n\n### 2.1 Unresolved merge conflict markers\n\n- Document: `README.md`\n- Contradiction: Contains `<<<<<<< HEAD ... ======= ... >>>>>>> origin/claude/projection-facade-layer-o3yg9o` conflict markers. The file therefore simultaneously presents two different architectural narratives: a legacy Supabase/Dual-write memory model and an alternate projection-facade narrative.\n- Retired-tech claim: HEAD side still references `VITE_SUPABASE_URL`, Fortress DB, and direct database paths.\n- Canon retaliation: `docs/CANON.md` and Tier A docs state Cloudflare-only product plane, no Supabase, DECISION 22.\n- Evidence: `README.md` line 11 to line 118 contains unresolved conflict markers.\n- Classification: CONTRADICTORY / STALE\n\n### 2.2 Supabase in README vs Cloudflare-only doctrine\n\n- Retired-tech claim: README declares “Fortress DB (Supabase SSOT)” and direct writes prohibited only by convention.\n- Canon retaliation: `docs/CANON.md`, Tier A canon, current `AGENTS.md` state no Supabase in the product plane.\n- Classification: CONTRADICTORY / HIGH\n\n### 2.3 Service directory dropdown mismatch\n\n- Document: `README.md`\n- Claim set A: services under `services/gateway`, `services/pipeline`, `services/connector`, `services/intelligence`, etc. plus historical `service` docs.\n- Claim set B: `apps/web`, `apps/desktop`, `apps/mobile`, and some nonexistent `services/projection-engine`, `services/capability-resolver`, `services/projection-registry`.\n- Runtime evidence: `services/projection-engine`, `services/capability-resolver`, `services/projection-registry` are not present as directories in current branch.\n- Classification: CONTRADICTORY / PARTIAL\n\n---\n\n## 3. DOCUMENTED SERVICE TOPOLOGY VS WORKER INVENTORY\n\n### 3.1 26-service canonical mesh vs repository reality\n\n- Document: `docs/FINAL_E2E_SYSTEM.md` §6\n- Document: `docs/CANONICAL_STATE.md` claims stable launch state\n- Claim: 26 services wired into Gateway as Cloudflare service bindings.\n- Evidence: Wrangler inventory shows service folders and `wrangler.toml` files for many services, some named inconsistently with claimed canon:\n  - Still present as runtime identities: `gateway`, `pipeline`, `connector`, `loader`, `normalizer`, `intelligence`, `think`, `act`, `govern`, `signals`, `l2`, `twin-orchestrator`, `iw-agent-runtime`, `mcp-connector`, `webhook-ingress`, `folder-watcher`, `knowledge`, `continuity`, `workflow`, `tenants`, `admin`, `billing`, `store`, `telemetry`, `hermes`\n  - Missing/unclear runtime identity vs target: `spine-writer`, `schema-synthesis`, `governance`, `huggingface-inference`\n- Document side claims runtime ownership that has not been verified in worker inventory; names have not been reconciled.\n- Classification: CONTRADICTORY / UNKNOWN\n\n### 3.2 Historical/cognitive runtime clusters vs Hermes\n\n- Documents claiming runtime ownership:\n  - `docs/ip/tech/TWIN_AS_COGNITIVE_ORCHESTRATOR.md`: claims Twin is canonical cognitive orchestrator.\n  - `docs/ip/tech/ENTITY_360_TWIN_TRIGGER_SCORING_GUARDRAILS.md`, `LAYER_OWNERSHIP_AND_TWIN_RUNTIME.md`: assign cognitive orchestration to Twin.\n  - `docs/platform-specs/06-twin-runtime.md`, `docs/platform-specs/23-agent-runtime.md`: target docs that likely attribute runtime responsibilities.\n- Canon retaliation:\n  - Canon/Hermes doctrine states Hermes is the cognitive orchestration runtime.\n  - Hermes is authoritative for context coordination, reasoning orchestration, tool and agent selection, and proposal generation.\n  - Twin is a silent partner inside L1, not a separate cognitive runtime.\n- Wrangler evidence: both `twin-orchestrator` and `iw-agent-runtime` exist as deployed Worker names; `hermes` is also deployed as `integratewise-hermes`.\n- Classification: CONTRADICTORY / HISTORICAL vs CURRENT\n\n---\n\n## 4. SPINE WRITER AUTHORITY RUPTURE\n\n### 4.1 Sole-writer doctrine vs historical pipeline\n\n- Document: `docs/platform-specs/02-operational-spine-canonical-highest-priority.md` declares governed Spine Writer as the sole path to canonical state.\n- Document: `docs/architecture/SPINE_MODEL.md` declares canonical Spine and Adaptive Spine tables.\n- Wrangler/manifest evidence: `services/pipeline` exists as a deployed Worker named `integratewise-pipeline` and AGENTS.md claims it is the Active Spine Writer.\n- Canon gap: Target service `spine-writer` is not present as a service identity in the repository.\n- Classification: CONTRADICTORY / UNKNOWN\n\n### 4.2 D1 as Spine vs Spine abstraction vs Supabase claims\n\n- Multiple docs describe Spine as D1, Fortress/Supabase, D1 cache, KV, or a conceptual abstraction:\n  - `docs/FINAL_E2E_SYSTEM.md` §20.2 states D1 is operational only; Postgres/HyperDrive is SSOT.\n  - `docs/FINAL_E2E_SYSTEM.md` §6.4 writes Spine as D1 operational tables.\n  - `docs/architecture/SPINE_DOMAIN.md`, `docs/architecture/SPINE_MODEL.md`, `docs/architecture/SPINE_INTELLIGENCE_AGENT.md` treat D1 as canonical state.\n  - `README.md` and historical docs treat Supabase as Fortress SSOT.\n- Result: Spine is at once D1 operational store, Postgres SSOT, and Supabase — without a single unified authority documented.\n- Classification: CONTRADICTORY / UNKNOWN\n\n---\n\n## 5. GOVERNANCE vs GOVERN RUNTIME\n\n### 5.1 Semantic stage vs Worker identity\n\n- Document target: `docs/platform-specs/09-governance-engine.md` projects governance as a platform capability.\n- Runtime evidence: deployed Worker is named `integratewise-govern` with wrangler.toml still referencing Supabase URL secrets.\n- Target topology expects separate runtime identity `governance`. Historical docs discuss semantic stages think → act → govern, but the current Worker name is `integratewise-govern`.\n- Classification: CONTRADICTORY / MIGRATING\n\n---\n\n## 6. CUSTOMER ZERO ACTIVATION STATE\n\n### 6.1 Frontend flow completion vs platform activation\n\n- Documents: `docs/CANONICAL_STATE.md`, `docs/architecture/ONBOARDING_FLOW.md`, `docs/internal/operations/CUSTOMER_ZERO_FLOW_TEST.md`, `quicky_start_preview_and_tests.md`\n- Claims in repo: many docs use “complete”, “final”, “LOCKED”, “signed” language around Customer Zero and end-to-end system completion, but no repository README or canon doc distinguishes between UI flow simulation, real Spine hydration, or production runtime verification.\n- `docs/FINAL_E2E_SYSTEM.md` claims §14 conflicts “resolved” and P0 blockers defined with closure criteria, but `docs/architecture/l1-reality-check.md` documents that Supabase entanglement, Auth thrashing, Capability-first APIs missing, and P0 cross-tenant leak are not bridged.\n- Classification: CONTRADICTORY / PARTIAL to STALE\n\n---\n\n## 7. L1-only PRODUCT VS MULTI-WORKBENCH / L2 NAVIGATION\n\n### 7.1 Workbench Doctrine multi-Workbench narrative\n\n- Document: `docs/architecture/WORKBENCH_DOCTRINE.md`\n- Canon retaliation: Product doctrine states L1 Workbench only; L2/L3 are panel states inside L1; Human, Twin, Governance, Knowledge, and Domain Workbenches are Context Lenses or panel states, not separate surface boundaries.\n- Document declares Human Workbench, Twin Workbench, Governance Workbench, Knowledge Workbench, and Domain Workbenches as separate Workbenches.\n- Classification: CONTRADICTORY / HISTORICAL vs CURRENT doctrine\n\n### 7.2 Department surfaces as separate products\n\n- Documents: `docs/ip/tech/ACCOUNT_SUCCESS_FLOW_TRACE.md`, `docs/internal/operations/VERIFICATION_ACCOUNT_SUCCESS_AND_BIZOPS.md`, `docs/internal/status/knowledgework_28d1.md`\n- Canon retaliation: Account Success, BizOps, Finance, etc. are Context Lenses unless repository evidence demonstrates a separate product boundary. No separate product boundary is currently canonically frozen.\n- Classification: CONTRADICTORY / HISTORICAL\n\n### 7.3 L2 Twin Surface Contract vs L1 Twin Button Doctrine\n\n- Document: `docs/ip/tech/L2_TWIN_SURFACE_CONTRACT.md`\n- Canon retaliation: L1 Twin surface has only three buttons: Ask your Twin, Assign your Twin, Check with your Twin. L2 contracts must be panel states, not separate navigation surfaces.\n- Classification: CONTRADICTORY / HISTORICAL\n\n---\n\n## 8. MCP ROLE AND AUTHORIZATION\n\n### 8.1 MCP as primary ingress vs product data plane\n\n- Document and chan claims: `docs/FINAL_E2E_SYSTEM.md` and only one MCP entry claim MCP is primary ingress.\n- Canon retaliation: MCP is a bidirectional protocol/tool boundary. L1 product data plane is Gateway/projection architecture. MCP is not the normal product data plane.\n- Document evidence: Client documentation paths under `apps/mcp-server/` not reported; downstream routing for Customer Zero activation under `iw-mcp[...]` is unverified.\n- Classification: CONTRADICTORY / UNKNOWN\n\n### 8.2 Tenant auth 403 recurrence\n\n- Reported in session memory/evidence as `tenant: integratewise`, `client: kiro-iw` returning 403 against MCP.\n- Classification: BLOCKED / UNVERIFIED unless reproduction is repeated with manifest-grounded evidence.\n\n---\n\n## 9. FRONTEND REALITY VS DECLARED CANON\n\n### 9.1 apps/live vs apps/web/apps/workspace ambiguity\n\n- `README.md` Alternate includes: `apps/web`, `apps/desktop`, `apps/mobile`; missing `apps/workspace`.\n- Folder evidence: `apps/web`, `apps/workspace`, `apps/desktop`, `apps/mobile`, `apps/docs` all exist. There is no `apps/live` directory at this branch’s top-level apps listing.\n- Canon retaliation: Canonical target is `apps/web`. If `apps/workspace` currently contains the strongest corpus, it must be documented explicitly, not silently assumed.\n- Classification: CONTRADICTORY / UNKNOWN\n\n### 9.2 Next.js/Vercel claims vs Cloudflare Pages stance\n\n- `docs/architecture/l1-reality-check.md` reports Next.js 16 server components and Supabase entanglement still in codebase.\n- Tier A docs/claims describe Vite + React + Cloudflare Pages.\n- Classification: CONTRADICTORY / UNKNOWN\n\n---\n\n## 10. RETIRED-TECH ABSORBED IN CURRENT DOCUMENTS\n\nThe following technologies are claimed as current or canonical by documents that were not tagged historical:\n\n- Supabase / Postgres as canonical SSOT in multiple architecture and README docs\n- Redis/caching semantics in older docs\n- Vercel hosting for canonical product in platform spec style narratives\n- OpenWebUI provisioning docs\n- CouchDB setup docs under packages\n- Application-layer Durable Object global IDs\n- MCP-server app directory not present\n\nClassification: STALE / CONTRADICTORY\n\n---\n\n## 11. READINESS LANGUAGE VIOLATIONS\n\nThe repository contains many documents using operational-readiness language despite indefinite gaps:\n\n- `docs/FINAL_E2E_SYSTEM.md` declares “LOCKED — all conflicts resolved” while `docs/architecture/l1-reality-check.md` flags 10 blockers, with P0 #1 cross-tenant leak present.\n- `docs/CANONICAL_STATE.md`, `docs/archive/FINAL_DELIVERY_SUMMARY.md`, `docs/archive/DEPLOYMENT_READY.md`, `docs/archive/IMPLEMENTATION_COMPLETE.md`, `docs/archive/PHASE_*_COMPLETE.md`, `docs/internal/status/L05_PHASE1_DEPLOYMENT_READY.md`, etc. use “complete”, “ready”, “signed”, “delivered” semantics.\n- Canons: No deployment success proves end-to-end operation. No route proves Spine authority.\n- Classification: CONTRADICTORY against readiness maturity\n\n---\n\n## 12. CONTRADICTION SUMMARY\n\n| Identifier | Domain | Contradiction | Lifecycle/State |\n|------------|--------|---------------|-----------------|\n| C-01 | README | Unresolved merge markers; Supabase + projection-facade alternative | CONTRADICTORY |\n| C-02 | README | Service listing includes non-existent directories | CONTRADICTORY |\n| C-03 | Runtime topology | Declared 26-service mesh vs observed + unverified runtime identities | UNKNOWN/CONTRADICTORY |\n| C-04 | Cognitive runtime | Twin/official docs claim cognitive orchestration vs Hermes doctrine | CONTRADICTORY |\n| C-05 | Spine authority | Declared sole Spine writer vs pipeline vs no `spine-writer` service identity | UNKNOWN/CONTRADICTORY |\n| C-06 | Spine storage | D1 vs Postgres vs Supabase all claimed as canonical | CONTRADICTORY |\n| C-07 | Governance runtime | `integratewise-govern` Worker vs target `governance` identity | MIGRATING/CONTRADICTORY |\n| C-08 | Customer Zero | Frontend/test flow declared complete vs platform activation unresolved | CONTRADICTORY |\n| C-09 | Product navigation | Multi-Workbench/L2/L3 doctrine vs L1-only product target | CONTRADICTORY |\n| C-10 | Department surfaces | Separate department products/surfaces vs Context Lens doctrine | CONTRADICTORY |\n| C-11 | L1 Twin surface | Separate L2 Twin Surface Contract vs L1 panel-state rule | CONTRADICTORY |\n| C-12 | MCP protocol role | MCP as primary L1 data plane vs protocol/boundary doctrine | CONTRADICTORY/UNKNOWN |\n| C-13 | Frontend app routing | `apps/web` canon target vs `apps/workspace` likely strong corpus | UNKNOWN |\n| C-14 | Frontend host | Next.js/Vercel evidenced vs Cloudflare Pages/L1 target | CONTRADICTORY |\n| C-15 | Retired tech | OpenWebUI, CouchDB, Supabase, Vercel canonical claims in active docs | STALE/CONTRADICTORY |\n| C-16 | Readiness language | “Complete”, “LOCKED”, “final” claims vs structural gaps in audit docs | CONTRADICTORY |\n\n---\n\n## 13. REQUIRED D1 OUTPUTS\n\n1. Confirm each contradiction with primary file reads.\n2. Reorder contradictions by production risk, not by document order.\n3. Identify documents that should become Tier C Historical due to retired-tech content.\n4. Map required evidence for each unknown: Cloudflare Worker runtime truth, MCP route authority trace, Spine write authority trace, Customer Zero activation path trace.\n"}