App Category, Entity Domain and Lifecycle Classification
Status: current derived implementation contract
Date: 2026-07-28
Source reconciled: IntegrateWise - App-Category Entity Domain Model
Authority: ARCHITECTURE_LOCK.md → CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.md → TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md
1. The classification address
Every canonical entity has an address beyond its tenant scope:
tenant_id + tenant_account_id + spine_network_id
+ app_category (where the entity originated)
+ business_domain (what business capability it belongs to)
+ lifecycle_stage (where it is in the operating lifecycle)
This is not a departmental database model. App category is a connector/source
classification; business domain is an entity/RBAC classification; lifecycle
stage is a signal, playbook and projection routing classification. Department
remains a people/team attribute that can influence a view but never physical
truth storage.
The canonical implementation is spine_entity_classifications, joined to the
universal spine_entity_scope_bindings record for each typed entity. It is
versioned, so a corrected classification never erases prior provenance.
2. Business domains and RBAC
| Domain | Primary purpose | Typical entity families |
|---|---|---|
revenue | Attract, qualify, win, retain and expand customers | lead, account, contact, opportunity, campaign, attribution, forecast, territory, quota |
people | Workforce, talent and organizational capacity | person, team, employee, position, candidate, interview, offer, leave, performance |
product | Product discovery, delivery, reliability and adoption | feature, bug, sprint, release, repository, deployment, incident, alert, product event |
operations | Company operating system, service delivery and internal systems | project, process, workflow, ticket, SLA, system, asset, strategic goal, board item |
finance | Revenue collection, spend, planning and financial health | invoice, payment, subscription, expense, budget, vendor, cashflow, company metric |
legal | Agreements, obligations, policy and compliance | contract, party, obligation, legal request, policy, compliance control |
communications | Recorded human interactions and evidence | email thread, chat thread, message, meeting, call, calendar event, attachment |
knowledge | Governed organizational knowledge and narrative context | document, note, knowledge article, wiki page, template, brainstorm session, chunk |
platform | Connection, capability and runtime control | connector, connection, schema, capability, automation, MCP tool, API client, webhook, deployment, audit event |
business_domain is the first RBAC filter. Field rules and row rules are
applied afterwards and before the response enters an operational cache.
3. Lifecycle routing
The cross-domain stages are:
sense → frame → decide → build → verify → release → operate → learn → adjust
An entity retains its detailed type-specific state machine in status and
spine_lifecycle_definitions. lifecycle_stage is the shared routing key. A
lead, for example, might have status = qualified and lifecycle_stage = decide; a release might have status = deployed and lifecycle_stage = operate.
4. App category routes
Every installed connector receives exactly one app_category. The source
category selects registered routes; the entity route resolves its business
domain, typed canonical table, default lifecycle stage and emitted events.
| App category | Entity routes | Default domain |
|---|---|---|
crm | leads, persons/contacts, accounts, opportunities, activities | revenue |
marketing_automation | campaigns, audience/attribution entities, leads, content assets | revenue |
revenue_operations | forecasts, routing rules, territories, quota plans, pipeline/call records | revenue |
support_helpdesk | tickets, cases, SLA policies, escalations, CSAT, knowledge articles | operations |
finance_billing | invoices, payments, subscriptions, expenses, budgets, vendors, cashflow | finance |
hris_people | persons/employees, positions, teams, onboarding, performance, leave, compensation | people |
recruiting_ats | requisitions, candidates, interviews, offers, hiring events | people |
product_analytics | product events, feature adoption, user sessions, cohorts | product |
project_issue_tracking | projects, features, bugs, sprints, milestones, dependencies, roadmap items | product |
devops_cicd | repositories, commits, pull requests, builds, deployments, releases, incidents | product |
observability_monitoring | incidents, alerts, errors, SLOs, post-mortems, RCAs | product |
legal_contract | contracts, parties, obligations, requests, policies, compliance controls | legal |
it_identity | systems, assets, licenses, certificates, vulnerabilities, access requests | operations |
communications_email | email threads, messages, attachments, contact interactions | communications |
communications_chat | chat threads, messages, channels, mentions | communications |
communications_video | calendar events, meetings, calls, recordings, transcripts, action candidates | communications |
knowledge_docs | documents, notes, articles, wiki pages, templates, chunks | knowledge |
executive_board | strategic goals, board items, investor updates, fundraising, company metrics | operations |
marketplace_platform | API clients, webhooks, connectors, capabilities, automations, MCP tools | platform |
integratewise_native | human-created Workbench record or governed platform output | resolved by entity route |
The source document describes broad source categories. Final domain is resolved
per entity route: a Finance/Billing invoice is finance, a DevOps deployment
is product, and an IT access request is operations. This prevents a
connector's broad category from widening or narrowing RBAC incorrectly.
5. Projection and cache contract
The Projection Engine applies filters in this order:
1. tenant / tenant account / Spine Network scope
2. business-domain access
3. field-level policy
4. row-level policy (ownership, team, account, relationship and active context)
5. lifecycle-stage and view-specific filter
6. cache the already filtered projection with a TTL
Neither the Workbench nor the operational cache receives an unfiltered
canonical row. Canvas layouts are projection manifests, not entity storage.
System, tenant and personal canvas overrides are configuration records; they
cannot bypass the Projection Engine or become business truth.
6. Memory and promotion alignment
| Scope | Durable location | Canonical effect |
|---|---|---|
| Personal | user-scoped continuity storage | can propose promotion; never direct truth |
| Organizational | governed memory/knowledge storage | can propose promotion through RBAC and approval |
| Agent | session-bounded agent runtime | can propose promotion; never direct truth |
| Operational | D1/KV short-lived cache | no promotion; rebuilt from canonical state |
Every promotable candidate includes memory scope/type, origin, confidence,
subject entity references, target domain/type, evidence and the full tenant
account/Spine Network envelope. spine_promotion_queue is the only route into
Fortress. A successful promotion creates the canonical version and then an
outbox-driven operational cache rebuild.
7. Implementation
041_app_category_entity_domain_classification.sql adds app-category,
business-domain and entity-route registries; versioned entity classification;
and connector/promotion metadata. 0008_entity_classification_operational_cache.sql
carries only already-resolved classification values needed by D1 cache entries.
D1 remains neither a truth store nor a classification authority.