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