Lifecycle, Continuity and Frontend Projection Map
Status: Normative
Date: 2026-08-11
Parent: INTEGRATEWISE_ARCHITECTURE_v2.2.md
Core rule
IntegrateWise user flow and execution are phase-, lifecycle- and continuity-driven, not page-first.
The frontend projects backend tenant tables, relationships, lifecycle state, work, Governance, continuity and effective Tool Capabilities into the Workbench.
backend tenant tables
+ lifecycle_stage / status / phase
+ relationships + work state
+ continuity + evidence + memory
+ connector/capability availability
+ Governance/RBAC
→ Projection Engine
→ Workbench phase projection
→ user/Twin intent
→ Tool Capability
→ Governance
→ execution
→ reconciliation
→ lifecycle transition
→ continuity update
→ projection rehydrate
Lifecycle, phase and continuity
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.
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.
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.
Tenant lifecycle phases
| Phase | Lifecycle | Primary backend tables | Primary frontend projections |
|---|---|---|---|
| 1 | Identity & Membership | spine_organizations, spine_users, spine_memberships, spine_user_roles, spine_role_permissions, spine_policies | onboarding, organizations, users, roles, permissions, security, profile |
| 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 |
| 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 |
| 4 | Triage, Continuity & Organizational Memory | timeline, signal, memory, continuity, knowledge, brainstorm and canvas tables | triage, brainstorming, notes, knowledge, memory & continuity, company/wiki projections |
| 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 |
| 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 |
| 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 |
| 8 | Vendor, Procurement & Partner | spine_vendors, spine_orders, spine_contracts, spine_expenses, relevant spine_accounts | vendors, orders, contracts, spend, savings, partnerships |
| 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 |
These are semantic lifecycle groupings over tenant-level tables, not separate physical schemas.
Frontend projection contract
Every frontend route/view must have an explicit backend projection map equivalent to:
type WorkbenchProjectionDefinition = {
id: string;
lifecycle: string;
phase: string;
primaryTables: string[];
supportingTables: string[];
relationshipTypes?: string[];
continuityInputs: string[];
filters: {
tenant: true;
workspace?: boolean;
role?: string[];
businessDomain?: string[];
lifecycleStage?: string[];
};
capabilities: string[];
output: "table" | "record" | "timeline" | "canvas" | "queue" | "dashboard" | "execution";
};
The implementation may differ, but the mapping semantics must exist.
Table → projection → surface
Every UI surface must be explainable as:
canonical table families
→ joins/relationships
→ lifecycle + phase filter
→ tenant/RBAC scope
→ continuity enrichment
→ capability projection
→ UI surface
Examples:
| Surface | Primary truth | Supporting context | Phase logic | Capability examples |
|---|---|---|---|---|
| Home | work items, tasks, approvals, signals | timelines, messages, meetings, outcomes | active/blocked/pending attention | assign, approve, update, open context |
| Account 360 | spine_accounts | persons, opportunities, renewals, contracts, invoices, messages, meetings, signals | customer stage + current risk | update account, prepare renewal, create task |
| Pipeline | spine_opportunities | accounts, persons, activities, meetings, signals | opportunity stage | advance stage, forecast, create follow-up |
| Renewals | spine_renewals | accounts, subscriptions, contracts, invoices, signals | renewal stage/risk | prepare renewal, assign owner, propose action |
| Roadmap | features, releases, sprints | objectives, projects, tickets, incidents | discovery/planned/in-progress/released | prioritize, assign, schedule |
| Incidents | spine_incidents | signals, assets, tickets, activities, timelines | detected/triaged/mitigating/resolved | assign, escalate, remediate |
| Approvals | approvals + Governance records | target entity, capability proposal, evidence | requested/approved/rejected/expired | approve, reject |
| Execution | capabilities + capability executions | connector projections, policies, target context | availability + Governance policy | dry-run, execute, propose |
User flow contract
Every lifecycle uses the same continuity loop:
Resume
→ Orient
→ Decide
→ Govern
→ Execute
→ Reconcile
→ Transition
→ Continue
- Resume — load current lifecycle stage and continuity packet.
- Orient — show what changed, pending work, blockers, evidence and context.
- Decide — select or prepare work/Tool Capability.
- Govern — evaluate authority and approval requirement.
- Execute — run the authorized operation.
- Reconcile — observe the actual downstream result.
- Transition — update canonical lifecycle/status when evidence supports it.
- Continue — update timeline/continuity and re-project the next phase.
A returning user should continue from the durable current state rather than reconstructing the task manually.
Phase-aware Tool Capabilities
Capability availability is derived from lifecycle/phase plus connector, RBAC and policy state:
entity + lifecycle_stage + phase
+ effective connector capabilities
+ tenant policy
+ principal/RBAC
→ available Tool Capabilities
Do not expose a capability merely because the connector technically supports it. It must also be valid for the current business lifecycle phase.
Continuity packet
The Projection Engine should be able to assemble a bounded packet equivalent to:
type ContinuityPacket = {
tenantId: string;
workspaceId?: string;
subject: { entityType: string; entityId: string };
lifecycle: string;
phase: string;
lifecycleStage?: string;
status: string;
lastMaterialEvent?: unknown;
openWork: unknown[];
pendingApprovals: unknown[];
blockers: unknown[];
risks: unknown[];
relevantRelationships: unknown[];
evidence: unknown[];
priorOutcomes: unknown[];
promotedMemory: unknown[];
capabilityAvailability: unknown[];
freshness: unknown;
};
The packet is a projection, not a new truth store.
Write path
The frontend never writes a projection back as canonical truth.
user action
→ command / Tool Capability intent
→ backend validation
→ Governance
→ deterministic write or authorized execution
→ outcome/evidence
→ canonical table update/promotion
→ lifecycle transition if valid
→ continuity/timeline update
→ projection invalidation
→ frontend rehydrate
Mandatory backend map for every frontend route
Every new route/view must identify:
- lifecycle
- phase
- primary backend table(s)
- supporting tables/relationships
- lifecycle/status filters
- tenant/RBAC filters
- continuity inputs
- projected Tool Capabilities
- write/command path
- invalidation/rehydration trigger
A frontend route without this map is incomplete.
No page-shaped truth tables
Do 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.
Continuity invariant
Every meaningful lifecycle transition must leave enough durable state to answer:
- What are we doing?
- What phase are we in?
- What changed and why?
- What is pending or blocked?
- What authority is required next?
- What capabilities are available now?
- What evidence supports the current state?
- What happens next?
That is the operational definition of continuity.