{"slug":"architecture/LIFECYCLE_CONTINUITY_AND_PROJECTION_MAP","title":"Lifecycle, Continuity and Frontend Projection Map","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/LIFECYCLE_CONTINUITY_AND_PROJECTION_MAP.mdx","bytes":12689,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Normative  \n**Date:** 2026-08-11  \n**Parent:** [`INTEGRATEWISE_ARCHITECTURE_v2.2.md`](INTEGRATEWISE_ARCHITECTURE_v2.2.md)\n\n## Core rule\n\nIntegrateWise user flow and execution are **phase-, lifecycle- and continuity-driven**, not page-first.\n\nThe frontend projects backend tenant tables, relationships, lifecycle state, work, Governance, continuity and effective Tool Capabilities into the Workbench.\n\n```text\nbackend tenant tables\n+ lifecycle_stage / status / phase\n+ relationships + work state\n+ continuity + evidence + memory\n+ connector/capability availability\n+ Governance/RBAC\n→ Projection Engine\n→ Workbench phase projection\n→ user/Twin intent\n→ Tool Capability\n→ Governance\n→ execution\n→ reconciliation\n→ lifecycle transition\n→ continuity update\n→ projection rehydrate\n```\n\n## Lifecycle, phase and continuity\n\n**Lifecycle** is the durable progression of an entity/process and is represented by backend state such as `lifecycle_stage`, `status`, timestamps, events, relationships and domain fields.\n\n**Phase** is the current operational slice of that lifecycle. It determines the work, context and Tool Capabilities relevant now. Phase must be derived from backend lifecycle/state; it is not a frontend-only flag.\n\n**Continuity** is the bounded state required to resume the work across sessions, people, systems, hosts and agents. It includes current phase, last material event, open work, approvals, blockers, evidence, prior outcomes, freshness, promoted memory/knowledge and available capabilities. Continuity does not replace canonical truth.\n\n## Tenant lifecycle phases\n\n| Phase | Lifecycle                                     | Primary backend tables                                                                                                                                                                                         | Primary frontend projections                                                                                           |\n| ----- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |\n| 1     | Identity & Membership                         | `spine_organizations`, `spine_users`, `spine_memberships`, `spine_user_roles`, `spine_role_permissions`, `spine_policies`                                                                                      | onboarding, organizations, users, roles, permissions, security, profile                                                |\n| 2     | Activation & Connector Consent                | `spine_connector_catalog`, `spine_connectors`, `spine_activation_runs`, `spine_mcp_routes`, `spine_model_registry`, connector bindings                                                                         | connector marketplace, integration manager, activation hub, data sources, integrations, capabilities, platform health  |\n| 3     | External Intake & Communication               | `spine_events`, `spine_messages`, `spine_calendar_events`, `spine_meetings`, `spine_calls`, `spine_documents`, `spine_document_chunks`, `spine_source_links`, `spine_evidence`                                 | activity feed, email, calendar, meetings, calls, documents                                                             |\n| 4     | Triage, Continuity & Organizational Memory    | timeline, signal, memory, continuity, knowledge, brainstorm and canvas tables                                                                                                                                  | triage, brainstorming, notes, knowledge, memory & continuity, company/wiki projections                                 |\n| 5     | Operational Work & Execution                  | `spine_work_items`, `spine_commitments`, `spine_work_queues`, `spine_tasks`, `spine_projects`, `spine_objectives`, `spine_outcomes`, `spine_approvals`, `spine_decisions`, `spine_projection_views`            | home, inbox, tasks, queue, approvals, notifications, recent work, favorites, projects, Execution                       |\n| 6     | Commercial & Customer                         | `spine_accounts`, `spine_leads`, `spine_opportunities`, `spine_subscriptions`, `spine_invoices`, `spine_renewals`, `spine_contracts`, `spine_budgets`, `spine_expenses`                                        | accounts, account health, contacts, renewals, pipeline, deals, forecast, revenue, invoices, reports, budget            |\n| 7     | Product, Delivery & Operating Systems         | `spine_processes`, `spine_workflows`, `spine_tickets`, `spine_incidents`, `spine_products`, `spine_features`, `spine_releases`, `spine_sprints`, `spine_assets`                                                | roadmap, features, bugs, sprints, releases, incidents, systems, tickets, SLA                                           |\n| 8     | Vendor, Procurement & Partner                 | `spine_vendors`, `spine_orders`, `spine_contracts`, `spine_expenses`, relevant `spine_accounts`                                                                                                                | vendors, orders, contracts, spend, savings, partnerships                                                               |\n| 9     | Governance, Security, Billing & Observability | `spine_policies`, `spine_audit_log`, `spine_security_events`, `spine_capabilities`, `spine_capability_executions`, `spine_pipeline_runs`, `spine_observability_signals`, `spine_deployments`, `spine_api_keys` | governance, observability, audit, billing, deployments, API keys, security, pipelines, automation, AI models, MCP pool |\n\nThese are semantic lifecycle groupings over tenant-level tables, not separate physical schemas.\n\n## Frontend projection contract\n\nEvery frontend route/view must have an explicit backend projection map equivalent to:\n\n```ts\ntype WorkbenchProjectionDefinition = {\n  id: string;\n  lifecycle: string;\n  phase: string;\n  primaryTables: string[];\n  supportingTables: string[];\n  relationshipTypes?: string[];\n  continuityInputs: string[];\n  filters: {\n    tenant: true;\n    workspace?: boolean;\n    role?: string[];\n    businessDomain?: string[];\n    lifecycleStage?: string[];\n  };\n  capabilities: string[];\n  output: \"table\" | \"record\" | \"timeline\" | \"canvas\" | \"queue\" | \"dashboard\" | \"execution\";\n};\n```\n\nThe implementation may differ, but the mapping semantics must exist.\n\n## Table → projection → surface\n\nEvery UI surface must be explainable as:\n\n```text\ncanonical table families\n→ joins/relationships\n→ lifecycle + phase filter\n→ tenant/RBAC scope\n→ continuity enrichment\n→ capability projection\n→ UI surface\n```\n\nExamples:\n\n| Surface     | Primary truth                         | Supporting context                                                                 | Phase logic                            | Capability examples                           |\n| ----------- | ------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------- | --------------------------------------------- |\n| Home        | work items, tasks, approvals, signals | timelines, messages, meetings, outcomes                                            | active/blocked/pending attention       | assign, approve, update, open context         |\n| Account 360 | `spine_accounts`                      | persons, opportunities, renewals, contracts, invoices, messages, meetings, signals | customer stage + current risk          | update account, prepare renewal, create task  |\n| Pipeline    | `spine_opportunities`                 | accounts, persons, activities, meetings, signals                                   | opportunity stage                      | advance stage, forecast, create follow-up     |\n| Renewals    | `spine_renewals`                      | accounts, subscriptions, contracts, invoices, signals                              | renewal stage/risk                     | prepare renewal, assign owner, propose action |\n| Roadmap     | features, releases, sprints           | objectives, projects, tickets, incidents                                           | discovery/planned/in-progress/released | prioritize, assign, schedule                  |\n| Incidents   | `spine_incidents`                     | signals, assets, tickets, activities, timelines                                    | detected/triaged/mitigating/resolved   | assign, escalate, remediate                   |\n| Approvals   | approvals + Governance records        | target entity, capability proposal, evidence                                       | requested/approved/rejected/expired    | approve, reject                               |\n| Execution   | capabilities + capability executions  | connector projections, policies, target context                                    | availability + Governance policy       | dry-run, execute, propose                     |\n\n## User flow contract\n\nEvery lifecycle uses the same continuity loop:\n\n```text\nResume\n→ Orient\n→ Decide\n→ Govern\n→ Execute\n→ Reconcile\n→ Transition\n→ Continue\n```\n\n1. **Resume** — load current lifecycle stage and continuity packet.\n2. **Orient** — show what changed, pending work, blockers, evidence and context.\n3. **Decide** — select or prepare work/Tool Capability.\n4. **Govern** — evaluate authority and approval requirement.\n5. **Execute** — run the authorized operation.\n6. **Reconcile** — observe the actual downstream result.\n7. **Transition** — update canonical lifecycle/status when evidence supports it.\n8. **Continue** — update timeline/continuity and re-project the next phase.\n\nA returning user should continue from the durable current state rather than reconstructing the task manually.\n\n## Phase-aware Tool Capabilities\n\nCapability availability is derived from lifecycle/phase plus connector, RBAC and policy state:\n\n```text\nentity + lifecycle_stage + phase\n+ effective connector capabilities\n+ tenant policy\n+ principal/RBAC\n→ available Tool Capabilities\n```\n\nDo not expose a capability merely because the connector technically supports it. It must also be valid for the current business lifecycle phase.\n\n## Continuity packet\n\nThe Projection Engine should be able to assemble a bounded packet equivalent to:\n\n```ts\ntype ContinuityPacket = {\n  tenantId: string;\n  workspaceId?: string;\n  subject: { entityType: string; entityId: string };\n  lifecycle: string;\n  phase: string;\n  lifecycleStage?: string;\n  status: string;\n  lastMaterialEvent?: unknown;\n  openWork: unknown[];\n  pendingApprovals: unknown[];\n  blockers: unknown[];\n  risks: unknown[];\n  relevantRelationships: unknown[];\n  evidence: unknown[];\n  priorOutcomes: unknown[];\n  promotedMemory: unknown[];\n  capabilityAvailability: unknown[];\n  freshness: unknown;\n};\n```\n\nThe packet is a projection, not a new truth store.\n\n## Write path\n\nThe frontend never writes a projection back as canonical truth.\n\n```text\nuser action\n→ command / Tool Capability intent\n→ backend validation\n→ Governance\n→ deterministic write or authorized execution\n→ outcome/evidence\n→ canonical table update/promotion\n→ lifecycle transition if valid\n→ continuity/timeline update\n→ projection invalidation\n→ frontend rehydrate\n```\n\n## Mandatory backend map for every frontend route\n\nEvery new route/view must identify:\n\n1. lifecycle\n2. phase\n3. primary backend table(s)\n4. supporting tables/relationships\n5. lifecycle/status filters\n6. tenant/RBAC filters\n7. continuity inputs\n8. projected Tool Capabilities\n9. write/command path\n10. invalidation/rehydration trigger\n\nA frontend route without this map is incomplete.\n\n## No page-shaped truth tables\n\nDo not create physical truth tables named after UI destinations such as `home`, `inbox`, `account-health`, `finance-manager` or `roadmap-view` solely for frontend convenience. Use semantic tenant-scoped entity/work/governance tables and compose projections.\n\n## Continuity invariant\n\nEvery meaningful lifecycle transition must leave enough durable state to answer:\n\n- What are we doing?\n- What phase are we in?\n- What changed and why?\n- What is pending or blocked?\n- What authority is required next?\n- What capabilities are available now?\n- What evidence supports the current state?\n- What happens next?\n\nThat is the operational definition of continuity.\n"}