Unclassified

IntegrateWise Source-Pack Reconciliation

Status: Controlled reconciliation record

Date: 2026-07-28

Purpose: Record how the supplied Markdown, JSON, CSV, XLSX, DOCX, PDF and
archive sources were interpreted against the frozen architecture and the live
repository.

1. Review rule

The attachment set is evidence, not one undifferentiated source of truth.
Material was classified using these rules:

An explicit final decision is reconciled into the current contract when it
can be expressed through the frozen kernel terms.
Frozen architecture and implementation contracts remain authoritative until
an explicit, versioned correction is recorded.
The live repository is implementation evidence. Code archives are dated
snapshots and never overwrite newer live code automatically.
A generated workbook or document may define a target contract without
proving that the target is implemented or deployed.
Exact duplicates are reviewed once. Compressed/rendered copies are treated
as the same source when their extracted content is equivalent.
Recovery codes, credentials, installers and possible secret-bearing
configuration are excluded from content review.

The terms Defined, Implemented and Live verified retain the meanings
in CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md.

2. Final reconciled decisions

Topic	Reconciled decision
Product	IntegrateWise is one Workbench over one stable logical Core Spine, with a contextual Silent Twin and governed capabilities.
Schema	Canonical storage is entity-, relationship-, event-, evidence-, policy-, capability- and execution-based. A frontend route or sidebar label never creates a truth table.
Projection	Role, department, industry, connector category, active context, availability and policy alter the projection, not canonical identity or a tenant-specific physical schema fork.
Normalizer	Deterministic parse, mapping, validation, identity resolution, deduplication and write-candidate preparation.
Triage	Adaptive classification and promotion of Flow C/knowledge/memory candidates. Confidence never grants authority.
Writers	Loader is the sole outer ingestion controller. Only internal governed writers/Pipeline promotion commit persistent canonical truth.
Flow A	Structured operational entities, relationships, metrics, events and lifecycle state.
Flow B	Documents, communications, attachments, transcripts and unstructured evidence.
Flow C	AI sessions, model outputs, plans, proposals, tool calls and candidate memory/knowledge/decisions. Flow C cannot directly mutate operational truth.
Flow D	Identity, tenant, workspace, membership, role, configuration, connection, credential-reference, capability, policy and runtime binding context. Governed external execution is downstream of Governance and Hermes, not Flow D business data.
Click behavior	A material click refreshes the Active Context Bundle and may perform lightweight mapping, availability, policy and OODA-state evaluation. It does not automatically open a Twin panel or run expensive reasoning.
Twin behavior	The Twin remains silent by default. Visible output occurs only for an explicit Ask/Assign/review action or a material proactive signal.
Auto-tuning	Bounded, versioned optimization of projection/configuration/runtime parameters inside existing Configuration, Projection, Governance and observability contracts. It is not a fourth product concept or an authority bypass.
Customer Zero	Same logical platform/schema contracts as customers, but separate production-grade infrastructure, credentials, data, queues, evidence, audit and operational bindings.
Storage	Neon owns canonical truth; R2 owns evidence bytes; D1/KV are bounded and reconstructable; vector/search is derived; credentials remain behind the credential wall.
Marketplace	Publish IW-Spine-Network Plugin in plugin marketplaces/directories and IW-Spine-Network MCP in MCP marketplaces/registries. Both use the exact 19-tool IW Spine Tools interface; the Plugin adds sandboxed host UI/skills, while the MCP lane provides the browser Workbench.

3. Conflict resolutions

Source conflict	Resolution
`ARCHITECTURE_LOCK.md` described Flow D as approved external actions, while the final runtime pack defines Flow D as Platform binding and control.	The final runtime definition is recorded as a post-lock correction: Flow D is binding/control. The approved-action path is `Twin/user intent → Capability → Governance → Hermes → provider → re-ingest → reconciliation`.
Role workbook says `Record click → ... → Twin detail`.	Record click builds permitted context. Twin detail opens only after an explicit Twin action or material signal.
Role workbook says Loader writes operational truth.	Loader controls outer ingress; internal governed writers/Pipeline promotion own commits.
Some source documents combine Normalizer and Triage.	They are separate runtimes with separate deterministic/adaptive authority boundaries.
Some legacy sources use D1 or Supabase as truth.	Superseded. Neon is canonical truth; D1 is bounded operational state only. Supabase is not in the frozen product path.
Role workbooks list tuple fields as if they define schema.	Workbooks are projection and implementation-control references. Canonical domain/entity contracts and migrations define storage.
Some PDFs say a connector writes new fields to the Spine on installation.	Connector installation registers mappings, sources, availability and approved additive extensions. It does not execute ad-hoc physical DDL.
Older UI sources use L1/L2/L3 or a permanent Twin panel.	Engineering genealogy only. These labels and a permanent Twin destination are prohibited in user-facing product UI.
Older plans recommend mock-first production behavior and silent live-to-seed fallback.	Mock/fixture data is Development-only. Production must render explicit loading, partial, stale, degraded or unavailable state.
Some documents describe Customer Zero as “not separate.”	It is not a separate product or logical schema contract, but it is a separate operational environment and data/credential partition.
Auto-tuning packs describe a new control-plane service.	Initial implementation must remain a package/responsibility inside existing Configuration/Projection/runtime services; service extraction requires scale evidence and a new decision.
New lifecycle attachments use D1 as the Canonical DB and describe per-customer or per-domain canonical D1 instances.	Rejected. Neon Postgres is the Canonical Spine/Fortress. D1/KV remain bounded, reconstructable operational state. Department never creates a storage partition.
New lifecycle attachments use age, lifecycle close or retention expiry as a promotion trigger.	Rejected. Aging expires, compacts, transitions or rebuilds operational/evidence material. Canonical promotion is evidence-, schema-, provenance-, policy- and authority-driven.
New lifecycle attachments describe Triage as promoting or rejecting truth and allow low-risk candidate auto-promotion.	Corrected. Triage classifies and routes candidates. It cannot self-authorize. Flow C canonical promotion requires the governed promotion record and applicable human approval.
New lifecycle attachments model Twin and Co-worker as separate runtimes and refer to an on-demand Twin panel.	Corrected. Twin is the contextual, silent AI Co-worker behavior inside the Workbench. It is not a permanent panel, sidebar destination or separate Co-worker service.
New lifecycle attachments make Workers for Platforms and one Worker per tenant the default multi-tenant compute model.	Rejected as a default. Shared stateless Platform Workers remain sufficient for ordinary tenant-isolated SaaS. Workers for Platforms is reserved for customer-supplied or agent-generated code that requires isolated deployment.
New lifecycle attachments place Search entirely inside Normalizer/Triage before persistence.	Corrected. Normalizer/Triage prepare classified and linked material; authority-filtered hybrid retrieval and ranking assemble Active Context at projection/Twin read time.

4. Primary normative inputs reviewed

Source	Treatment
`Final Canonical Runtime Model` attachment, 2026-07-28	Current explicit runtime decision, reconciled with the Silence Law.
`IntegrateWise_Spine_Documentation_Pack_v1_1.zip`	Primary modular runtime, flow, projection, Workbench, Twin, capability, governance, reconciliation and acceptance reference.
`14A_ADAPTIVE_SPINE_EXPANSION_ALGORITHM.md`	Adopted algorithmic reference for additive mapping, availability and projection compilation.
`IntegrateWise_Canonical_Update_2026-07-27.zip`	Current product, lifecycle, MCP/ADK, deployment, terminology and auto-tuning target reference.
`IntegrateWise_Canonical_Update_2026-07-27 (1).zip`	Companion topology, frontend/backend/memory/schema and enriched workbook reference.
`IntegrateWise_Canonical_Mapping_Register_2026-07-27 (1).xlsx`	Preferred mapping workbook because it adds API contracts, detailed FE/BE mapping, schema registry, memory map and repository topology.
`IntegrateWise_Role_Workbench_Mapping_Package.zip`	Twelve role projection/control workbooks and master index; not physical-schema authority.
`IntegrateWise_Consolidated_Canonical_Document_Set_v1.0.zip`	Product experience, platform runtime and commercial/release synthesis.
`IntegrateWise_Consolidated_Document_Set_2026-07-27.zip`	Product, architecture, tuning, Customer Zero and release synthesis.
`00_IntegrateWise_Consolidated_Canonical_Product_and_Platform_Spec_v1.0.docx`	Concise canonical synthesis; corroborating input.
`IntegrateWise_Spine_Master_Specification_v1_1.docx`	Rendered master form of the Spine documentation pack.
`IntegrateWise_Triage_Gateway_AI_Memory_Spine_Architecture.docx`	Strong multi-store and governed-write reference; storage claims filtered through the implementation contract.
`Customer Zero: Four-Flow Data Lifecycle` attachment, 2026-07-29	Lifecycle and environment detail reconciled into `TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md`; conflicting storage, promotion, Twin and Cloudflare claims were not adopted.
`Four-Flow Data Lifecycle Across Dev, Customer Zero, and Product` attachment, 2026-07-29	Three-environment comparison and release-boundary input; retained after correcting D1-as-canonical, per-domain partitioning, age promotion and Workers-for-Platforms defaults.

5. Mapping and schema inputs reviewed

Role workbook package

The package contains one master workbook plus twelve role workbooks:

Founder, Customer Success, Sales, Support, Project Management,
Marketing, Business Operations, Technology, Human Resources, Finance,
Legal and Personal.

Every role workbook contains:

Overview;
Entity Catalog;
Tuple Fields;
Workbench Sections;
Canvas & Pages;
Click Context Map;
CRUD Capabilities;
Docs & Knowledge;
Backend Mapping;
Governance Sync;
Acceptance Tests;
Sample Records.

The master workbook contains 192 role/entity mapping rows and 192 delivery
tracking rows after the title/header rows. This is substantial coverage, but
all build states are generated or not started; it is not implementation proof.
Workbook keys using underscores must be normalized to the live hyphenated role
IDs in packages/workbench-config/src/roles.ts.

Schema and memory sources

04_FRONTEND_BACKEND_MEMORY_SCHEMA_MAP.md defines a target logical schema and
explicitly warns that migrations must be reconciled against the live repo.
IntegrateWise-Spine-Memory-Schema.zip correctly separates raw intake,
working session state, promotion proposals, review, canonical memory,
evidence, vector references and cache invalidation. Its claim that D1 can be
a truth store is not adopted.
Archive-with-Spine-Memory-Schema.zip is a UI/schema snapshot that contains
the same memory package plus Account Success views. It is reference only.
records.csv contains 100 rows with the columns ID, Name, Email,
Status, Category, Created At, Updated At and Value. Row values were
not ingested because they are fixture/record data, not architecture.

6. PDF and wiki sources reviewed

Source	Treatment
`IntegrateWise - Company Wiki.pdf` and compressed copy	Same 93-page wiki content in different encodings. Source snapshot for page-by-page regeneration; generic template authorship/images and status claims are not canonical.
`Workbench IA & Spine Projection Map`	Strong surface→projection rule and sidebar traceability reference. Corrected so tables are storage implementations, not the semantic Spine itself.
`IntegrateWise — The Mental Model`	Strong Projection/Spine/Evidence model; connector physical-field mutation and Postgres-only language are superseded.
`Account Intelligence — Schema v1.0` and `Untitled page.pdf`	Account/CS field inventory and historical source mapping; not universal canonical schema authority.
`IntegrateWise Universal Tenant Spine Schema v1.pdf`	Strong one-tenant/one-logical-Spine and projection doctrine; provider/layer labels are implementation references.
`Account Success — Spine Schema`	Domain schema reference. “Pipeline writes it” is interpreted as governed Pipeline promotion, never direct UI/Twin/provider writes.

Representative pages were rendered and visually inspected in addition to text
extraction. The PDFs are readable, but they remain source snapshots rather than
automatically updated repository documentation.

7. Historical and corroborating documents

The following were reviewed for decisions, headings and conflict patterns but
remain history or supporting reference:

MCP-Routing-Implementation-Review.md;
Branch-·-Adaptive-Workbench-Auto-Tuner.md;
Adaptive-Workbench-Auto-Tuner.md and its non-identical revision;
IntegrateWise-Evolution-Overview.md;
all unique Continuity-Issues-and-Apology and branch exports;
Canonical-update-pack.md;
Platform-Architecture-Overview.md;
Architecture-Core-Documentation.md;
Centralized-Secret-Management.md;
IntegrateWise-OS-architecture-and-implementation-plan.md;
Final-IntegrateWise-Consolidation.md;
Weekly-Docs-Maintenance.md;
[Pasted 839 lines].txt;
domain-apps-and-repository-architecture-planning-20260727.json;
both architecture-documentation-plan JSON exports;
IntegrateWise_Workspace_User_Journey_and_Product_Moat_v1.0.docx;
IntegrateWise_Platform_Documentation_v5.0.docx;
IntegrateWise_End_to_End_Canonical_Blueprint_v5.0.docx;
the ten DOCX files inside files.zip;
IntegrateWise-AI-Workspace-Specification-v3.3.docx inside files (1).zip.

Useful detail was retained only where it agrees with the reconciled decisions.
Stale elements include named multi-agent product pillars, Supabase truth,
permanent Twin surfaces, L1/L2/L3 product layers, direct agent-to-agent routing,
direct provider/UI writes, mock-first production behavior and schema-per-domain
or connector-install DDL.

8. Code and UI archive treatment

The following archives were inventoried but are not merged because the live
repository is newer and is the implementation authority:

work-bench-main.zip;
work-bench-main (1).zip;
data-management-interface.zip;
twin-workspace-platform.zip;
twin-workspace-platform (1).zip;
UIBench-0-integratewi-c8e93db9.zip;
integratewise-live-main.zip;
integratewise-live-main (1).zip;
integrate-wise-connector-platform.zip;
file12s.zip.

The archives remain useful for locating prototype surfaces, templates and
historical implementation ideas. Any desired code must be diffed file-by-file
against the live repo and reimplemented behind current contracts.

9. Exact duplicates collapsed

The Copilot and iCloud copies of
IntegrateWise_Role_Workbench_Mapping_Package.zip are byte-identical.
MCP-Routing-Implementation-Review.md and (1) are byte-identical.
Branch-·-Adaptive-Workbench-Auto-Tuner.md and (1) are byte-identical.
Continuity-Issues-and-Apology.md and (1) are byte-identical.
Branch-·-Continuity-Issues-and-Apology (1).md and (2) are byte-identical.
IntegrateWise_Consolidated_Document_Set_2026-07-27.zip and (1) are
byte-identical.
The Company Wiki PDFs contain the same 93 pages; the compressed file is a
smaller rendering, not a newer source.

The two canonical mapping workbooks and two canonical-update archives are not
duplicates. The larger workbook/archive variants contain additional mappings
and are preferred for reconciliation.

10. Deliberate exclusions

The following were not opened:

npm_recovery_codes.txt;
config-github-models.toml;
ChatGPT.dmg;
Lovable-1.4.0-mac-arm64.dmg;
Superhuman-Docs-universal.dmg.

Reason: recovery codes and possible credential-bearing configuration are
sensitive; installers do not contain product architecture source material.
The repository must never copy these artifacts into documentation, fixtures or
release packages.

11. Repository consequences

The source review requires the current documentation to:

state the corrected Flow A/B/C/D contract;
preserve Normalizer/Triage separation;
distinguish per-click context hydration from visible Twin activation;
preserve the stable Core Spine/additive-expansion algorithm;
classify role workbooks as projection references;
keep Auto-Tuning inside existing bounded responsibilities;
maintain Neon/R2/D1/KV/credential-wall ownership;
maintain Development, Customer Zero and Customer Production isolation;
keep frontend reads projection-based and Gateway-only;
track implementation and live verification independently from document
completeness;
keep aging independent from canonical promotion and govern all retention,
deletion, archival and legal-hold behavior by tenant and record class;
use Workers for Platforms only when customer/agent code deployment requires
it, not as an assumed requirement for ordinary multi-tenant Platform
services.

The missing WORKBENCH_ROLE_CAPABILITY_MAP.md reference was restored from the
live 12-role registry and the supplied role-workbook package. It distinguishes
projection availability from RBAC authority and active connector state.

Older files that directly declared conflicting D1-truth, layered Product,
always-active Twin or v2 deployment claims as canonical now carry explicit
supersession banners. Their useful detail remains available as lineage.

No attachment, archive or workbook by itself changes a repository status from
Defined to Implemented or Live verified.