{"slug":"business/application-boundaries","title":"IntegrateWise application boundaries","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/application-boundaries.mdx","bytes":5661,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nStatus: **Frozen for implementation**\n\n## Canonical applications\n\n| Application             | Responsibility                                                 | Primary users                                                      |\n| ----------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------ |\n| `apps/marketing`        | Public website, blog, changelog and public connector catalogue | Prospects and public visitors                                      |\n| `apps/docs`             | Public product, API, SDK and MCP documentation                 | Customers and developers                                           |\n| `apps/platform-console` | IntegrateWise platform control plane                           | Platform operators, support engineers and delegated administrators |\n| `apps/workspace`        | Complete customer-facing continuity product                    | Customer users and workspace administrators                        |\n| `apps/desktop`          | Native shell over Workspace contracts                          | Customer users                                                     |\n| `apps/mobile`           | Mobile shell over Workspace contracts                          | Customer users                                                     |\n\n`apps/web` is a transitional mixed application. It remains available until every route has an explicit owner and parity has been verified in its destination application.\n\n## Platform Console ownership\n\n`apps/platform-console` owns administrative projections for:\n\n- organizations and tenants\n- identity infrastructure and access policy\n- Integration Manager administration\n- connector registry, manifests, adapters and runtime health\n- MCP servers, tools and routing\n- gateways, AI Gateway and model routing\n- workers, queues and workflow execution\n- Spine ingestion and projection health\n- capability fabric\n- memory and knowledge services\n- governance policies and audit\n- provider configuration and credentials infrastructure\n- feature flags, billing, entitlements and deployment health\n\nIt must not contain normal customer workbenches.\n\n## Workspace ownership\n\n`apps/workspace` owns:\n\n- Home and My Work\n- operational workbenches\n- Account, Contact, Case, Project and other entity collections\n- Entity 360\n- activity and conversations\n- Awareness Drawer\n- Twin\n- knowledge and memory\n- proposals, approvals and handoffs\n- customer connection activation and simplified health\n- workspace settings, organization settings and billing\n\nIt must not expose worker topology, queue internals, gateway routing rules, model-provider credentials, connector-runtime internals, deployment internals or projection compiler details.\n\n## Administration scopes\n\n| Scope                    | Location                                | Operates                                                                   |\n| ------------------------ | --------------------------------------- | -------------------------------------------------------------------------- |\n| Platform administration  | `apps/platform-console`                 | The IntegrateWise platform and its infrastructure                          |\n| Workspace administration | `apps/workspace` under Settings         | One customer workspace, its members, permissions, policies and connections |\n| Personal settings        | `apps/workspace` under user preferences | One user's profile, notifications, sessions and preferences                |\n\nThere is no separate ambiguous `apps/admin` application.\n\n## Integration Manager projections\n\nThe Integration Manager is one service with two projections:\n\n- **Platform projection:** provider definitions, OAuth applications, adapter selection, connector manifests, scope templates, runtime health, tenant overrides, rate limits, synchronization policies, credential infrastructure and diagnostics.\n- **Workspace projection:** connect a provider, select permissions, review policy, inspect simplified health, pause or disconnect, and request additional access.\n\n## Connector marketplace layers\n\n- Public catalogue: `apps/marketing`\n- Authenticated activation catalogue: `apps/workspace`\n- Connector administration: `apps/platform-console`\n- Runtime implementation: `services/connector-runtime`, `services/integration-manager`, `packages/connectors` and `packages/connector-contracts`\n\n## Dependency rule\n\nApplications consume platform APIs, SDKs and contracts. Platform services and packages must never import application code.\n\n## Migration sequence\n\n1. Establish deployable `platform-console` and `workspace` shells without deleting `apps/web` routes.\n2. Inventory every route in `apps/web` and assign one canonical owner.\n3. Move shared behavior into services or packages before moving presentation routes.\n4. Migrate Platform Console routes and verify operator parity.\n5. Migrate Workspace routes and verify customer-product parity.\n6. Move public marketing, documentation and connector-catalogue routes to their public applications.\n7. Retire `apps/web` only after route, permission, telemetry and deployment parity is proven.\n\n## Vercel project mapping\n\n| Vercel project                        | Root directory          |\n| ------------------------------------- | ----------------------- |\n| `integratewise-live-platform-console` | `apps/platform-console` |\n| `integratewise-live-workspace`        | `apps/workspace`        |\n\nThe existing `integratewise-live-web` project remains during migration. It must not be repointed until replacement routes are verified.\n"}