# Business Capabilities Status: current architectural direction; Sales product definition added 2026-09-29. This is the intended capability landscape, not an implemented feature inventory or a promise to complete every area in the MVP. Owns: business outcomes, composition examples and the enquiry and equipment-servicing scenarios. Composition terminology belongs to the [product definition](definition.md#composition-and-extensibility); sequencing belongs to the [roadmap](roadmap.md). Lineage: source 01's holistic platform and capability examples, source 02's relationship and application examples, source 03 sections 4, 5 and 8, and their corresponding source 00 sections. See the [source ledger](../governance/source-map.md). The canonical Sales product composition below incorporates the project owner's explicit Sales scope and content decisions supplied 2026-09-29. Those decisions govern Sales semantics; repository implementation artifacts do not. ## Shared Capability Contract Every capability uses the same [objects and types](../architecture/objects-and-types.md) and [Business Graph](../architecture/business-model.md). A Customer used in CRM, sales, projects, support, reporting and website forms is not copied into six capability-owned customer models. Each catalogue entry gives a business outcome and scenario, illustrative shared types and relationships, supporting platform responsibilities, and permission/history touchpoints. Type names are examples, not a mandatory type library or physical schema. A Definition used for a product composition is an ordinary recursive Definition; a Business applies/configures it through governed Business-scoped Objects, Relationships, Configuration and Presentation Objects. Those values remain subject to platform validity, Authority, provenance and commit rules. All entries require authorized human operation and deterministic behavior without AI; AI-assisted operations add optional assistance to that baseline. The standard Definition is the complete recursive composition required to define and operate the capability. It is not equivalent to `Capability -> list of Types`; Types, Operations, Views and relationship declarations are only ordinary Objects that may be contained or referenced within that composition. The eight catalogue names below are product/canonical labels, not proof that eight complete Definitions or eight independent stores have been implemented. Missing recursive composition is an implementation/content gap, not permission to create a capability-specific graph or semantic layer. The distinction is strict: the standard Definition is reusable, while each Business configuration is separately governed. A Business-specific selection or variation does not rename, replace or mutate the standard and does not create a new special type. There is no current capability Derivation layer; future Definition evolution is a separate governed question and is not implied by Business configuration. The eight standard names are product concepts, not evidence that eight complete Definition Objects have been published. Sales has the canonical product composition specified below; the seven initial compositions are specified in the bounded sections that follow it. These product contracts authorize neither unsupported execution nor new domain infrastructure; the product text itself is not persistence or publication authority, and implementation evidence is recorded separately in [implementation status](../implementation/status.md#capability-definition-and-application-build). The current shallow IDY-008 declarations (`supported_constituents`, `operation_ids` and `view_ids`) are reusable configuration/test evidence only; they are not the semantic Definition of a capability. The established project-owner User receives the narrow `definition.publish` permission through normal platform installation/configuration; bootstrap and authority reassignment mechanisms are out of scope. The generic governed publication boundary is specified separately from Business application. Foundational Initialization Definitions such as User (legacy Type name Principal), Business, Person and Organisation are distinct from the eight Capability Definitions. An Action is a provider-independent semantic request within a Capability. Its existing exact-revision Operation Contract provides the executable contract; the two concepts do not create parallel registries or execution systems. `send_email` is the canonical example: its declared inputs describe recipients, content, optional template/attachments and channel context, while an independently selected Provider performs or simulates the request. The initial foundation supports simulation only and never claims an email was sent. The intended inspection path is `UI -> Explore Definitions -> canonical persisted Definition -> recursive composition -> Object inspection`. The Explorer is read-only, must inspect the canonical persisted Definition, must not execute Workflow or Logic, and must not become a second semantic authority or substitute a manifest projection when the canonical Definition is unavailable. Object/Data, Relationship, Identity/Permission and relevant Event responsibilities underpin every entry. Additional dependencies below use the names routed through the [architecture map](../architecture/overview.md); they are not instructions to create code services. [Governance](../architecture/identity-and-governance.md) applies to every read, change and external action, and [time and events](../architecture/time-and-events.md) applies to its explanation and history. ## Capability Model Capabilities are reusable business/product compositions, not necessarily separate modules or application silos and not a fourth semantic role. Their reusable Definitions are platform-owned; a Business's editable/configured Objects and Relationships use the shared model rather than a copied domain universe. They compose from Data, Workflow and Logic, plus Objects and Types, Relationships, State, Knowledge, Operations, Presentation, Authority, Provenance, Communication, Integrations and Analytics. A new business domain should use the lowest sufficient composition level described by the [product definition](definition.md#composition-and-extensibility) before a new reusable engine is considered. An Operation may support a product composition, but neither an Operation nor its Operation Contract is the composition itself. The user should experience the business outcome and a useful holistic interpretation of the object that matters, not merely a summary or an implementation graph. A higher-level object should normally make the condition contributed by its constituents understandable without requiring the user to inspect every constituent. It may project its identity, current condition, constituent context, attention, significant changes, useful measures, applicable workflows, system activity and recommendations. Constituent and mechanical detail remains available through deliberate inspection and configuration. ## Standard Capability Definitions The current standard platform Capability Definitions are: | Navigation order | Capability | |---:|---| | 0 | Dashboard | | 1000 | People | | 2000 | Products & Services | | 3000 | Sales | | 4000 | Marketing | | 5000 | Projects | | 6000 | Operations | | 7000 | Finance & Accounts | | 8000 | Knowledgebase | The numeric order is persisted as Presentation configuration on the relevant Business-scoped Presentation Objects, leaving space for future product compositions to be inserted without renumbering the existing entries. Unrecognised Business compositions sort after the standard catalogue by their persisted order and then label. Each name identifies a standard Definition in the catalogue. A Business may have zero, one or many corresponding Business Capability Instances; an unconfigured or empty instance is distinct from a missing standard Definition. Applying a Definition creates or resolves Business-owned Objects/configuration from its composition without mutating the platform Definition or copying Business scope into platform scope. The eight entries do not imply eight separate stores, modules or execution engines. Dashboard is an empty platform Definition. Its Business Capability Instance is populated through governed configuration with exact references to the Business's other Capability Instance Objects. Its presentation is a simple ordered grid of those referenced instances; it does not execute or duplicate their constituent data, Workflow or Logic. ## Sales Capability Definition This section is the canonical product specification for the first standard Capability Definition, Sales. It records product semantics and boundaries; it does not define a serialized Object shape, assign Object identifiers or revisions, authorize publication, or claim that a Definition has been persisted. The Definition uses the universal Object model and existing identity, revision, provenance, relationship and governed mutation contracts. Luna determines the conforming Object composition and containment/reference mapping from those contracts; no Capability-specific schema or infrastructure is introduced. ### Responsibility and lifecycle Sales is responsible for the commercial lifecycle from an unconverted contact or prospect through commercial qualification to sale and, where applicable, a recorded Project handoff. Its lifecycle is: `lead/contact -> qualification -> opportunity -> commercial proposition -> sale` Sales may begin with any contact or prospect that has not yet converted. A person or organisation may be commercially relevant before it is a qualified opportunity. Qualification determines whether an enquiry or prospect is worth pursuing. An opportunity represents the commercially qualified potential and its progress toward an outcome. A commercial proposition is made to an opportunity or customer and can include a proposal or quote. Sale records the commercial outcome; successful Sales may record a handoff to Projects. The phases and business-specific outcomes are represented through ordinary configured State, Workflow and Logic semantics. This does not establish a universal platform State vocabulary or prescribe transitions, guards, or implementation fields beyond the product lifecycle stated here. State definitions, current State references, and transition occurrences remain distinct under the canonical model and retain their applicable history. ### Commercial information The Sales composition must be able to represent: - Contact/prospect identity and the origin of commercial interest, including website, email, phone, campaign, referral, event, partner, and other Business-configured sources/channels. - Qualification and opportunity meaning, progress, and commercial context. - Commercial propositions, proposals and quotes, including what is being sold: packages, recurring services, and configurable offerings. - Expected revenue, probability, weighted pipeline, expected or target close dates, and forecast category. - Commercial outcomes including won, lost, abandoned, disqualified, and converted to customer, with room for other Business-configured outcomes. - The responsible representative and source attribution needed for pipeline and performance analysis. Conversion to customer establishes a shared customer role on the existing Person or Organisation identity. It does not create a duplicate customer identity or a Sales-owned copy of the person or organisation. The Sales capability includes analytics requirements for pipeline value, conversion rates, velocity, win rate, revenue, source performance, and representative performance. Forecast categories and metric definitions/calculations are Business-configurable. No universal weighted-pipeline formula, revenue basis for recurring/configurable offerings, probability scale, attribution model, or measurement window is established by this Definition. Analytics must preserve the applicable metric definition, source, scope, time basis, and material limitations under the [Analytics and Evolution](../architecture/analytics-and-evolution.md) contract. ### Shared capability boundaries - **People and Organisations:** Sales reuses shared Person and Organisation identities for prospects, contacts, and customers. The customer role is established on that shared identity. Sales does not own a separate contact/customer directory or redefine identity and access semantics. - **Products & Services:** Sales owns the commercial proposition and its terms. It refers to the shared offerings, packages, recurring services, configurable offerings, and applicable pricing context; it does not own or duplicate their catalogue. Relevant offering and pricing context remains explainable for prior propositions and outcomes. - **Projects:** Sales records the handoff boundary after a successful commercial outcome. The Projects capability owns Project composition and lifecycle. Sales does not create, initialize, or execute a Project. - **Marketing:** Sales records source attribution, including Campaign where applicable. Campaign planning, content, channels, and delivery remain with their owning capabilities and shared platform responsibilities. - **Communication:** Sales may relate relevant interactions and communication evidence to its commercial work. Communication channels, delivery, and their histories remain with Communication responsibilities; naming email or phone as an origin does not require an integration or connector. - **Knowledge and Documents:** Sales may reference relevant knowledge, documents, and commercial evidence. It does not take ownership of knowledge management, document/content management, or their lifecycle. - **Analytics:** Sales defines the required business measures and supplies their relevant commercial context. Shared Analytics responsibilities own measurement, aggregation, reporting projections, and their evidence and access boundaries. ### Composition and addressability Sales-owned lifecycle and commercial-proposition semantics belong to the Sales Definition composition. Shared People, Organisation, offering, pricing-policy, Campaign, communication, knowledge, document, analytics, and Project Objects are referenced where their identity and ownership remain with those shared or adjacent responsibilities. Source labels and other values may remain ordinary typed values when independent identity is unnecessary. Containment, reference, identity, Type, revision, and provenance follow [Objects and Types](../architecture/objects-and-types.md): a constituent is independently addressable when its reuse, relationships, provenance, history, lifecycle, or another canonical authority requirement calls for it. Otherwise it may remain inline within the ordinary Object composition. These are semantic composition rules, not a prescribed JSON/reference shape. Exact applicable revisions use existing mechanisms; release/publication evidence is provenance and does not replace Object identity or revision. ### Explicit exclusions The Sales Definition does not absorb the Projects capability or create Projects; own People/Organisation identities or a separate Customer model; own the Products & Services catalogue or pricing policy; manage Marketing campaigns or channel publishing; provide website, email, phone, referral, partner, or event intake connectors; own Communication delivery, Knowledge, Documents, or Analytics infrastructure; or define a finance/accounting ledger. It does not require AI. Business-configurable forecast and metric semantics are not replaced by fixed universal categories or formulas. Adjacent concepts are not added to Sales merely because they could be useful. ## Initial Capability Compositions These compositions establish the first product scope. They use shared addressable Objects and exact Type/Object revisions under the universal model. A named constituent is addressable only where reuse, relationships, provenance, history or lifecycle requires identity; other structure may remain inline. Listing a capability responsibility does not assert an implemented engine, live integration, universally fixed Type or executable Operation. Unsupported actions remain unavailable until an existing trusted Operation and applicable Business authority exist. ### People People reuses the platform Person and Organisation identity semantics. Its Business composition relates people to organisations through explicit, Business-owned Relationship Types and can capture contact details, preferences, roles, affiliations and responsibility only where the Business has an applicable supported Object or Type. It does not create a duplicate Contact or CRM model, and a role relationship does not grant Business access. Unimplemented contact methods, role workflows and responsibility actions are configuration requirements, not executable behavior. ### Products & Services Products & Services describes a Business's reusable offerings, including identity, description, applicable commercial context and lifecycle. Offering Types and pricing context are addressable when history or reuse requires them; relationships connect offerings to supporting Knowledge or Documents and consuming capabilities. Sales refers to these offerings and preserves the commercial context used in a proposition; it does not own or copy the catalogue. This initial composition is not an ERP, inventory, order, fulfilment or pricing engine. ### Marketing Marketing composes business goals, audiences, content, channels, campaigns, interactions, responses, outcomes and measurement through shared Objects and explicit Relationships. Independently managed campaigns, content, audience membership or outcomes are addressable where their identity or history requires it; other planning details may remain inline. Existing Views may inspect configured content. No live channel delivery, provider, marketing automation engine or AI behavior is implied; unsupported execution is unavailable. ### Operations Operations composes operational work and its execution context, including work, execution, exceptions, handovers, people, equipment or resources and procedures. It uses shared Person and Organisation, Knowledge and Document, Relationship, State and Workflow mechanisms where present. It is not a synonym for Projects and does not imply an equipment service engine, scheduler, resource allocator or unsupported operational action. ### Projects Projects represents project identity, lifecycle, customer context, work, participation, documents and outcomes using shared Objects and explicit Relationships. The Business-owned Project lifecycle remains distinct from Sales. A successful-sale handoff may be represented when an authorized supported Operation exists; the current Qualification-to-Project demonstrator does not by itself define the general Projects capability or make Project creation Sales-owned. ### Finance & Accounts Finance & Accounts initially organizes supported commercial and financial evidence and its relationships to offerings, propositions, goals and work. It may expose references or bounded financial records only where an existing semantic Type and governed behavior support them. Unsupported execution is explicitly unavailable. This composition does not claim a ledger, tax engine, banking or payment provider, ERP or speculative financial infrastructure. ### Knowledgebase Knowledgebase composes source Documents, Knowledge, assertions or information, provenance, applicability, standing and explicit Relationships. Documents remain sources, not automatic truth; claims retain source and authority distinctions, and changes are non-destructive. Human-facing inspection and supported existing actions may be exposed. AI retrieval, autonomous processing, a second document model and unimplemented ingestion are excluded. ## Onboarding and Continuous Configuration Business onboarding is a first-class capability that progressively establishes a usable Business rather than presenting every underlying object and configuration decision as an administrative form. Its conceptual composition is: `business description -> questions and information gathering -> object/configuration creation -> relationships -> deterministic calculations -> workflow actions -> human decisions -> operational state` The same platform primitives remain available after onboarding. AI may interpret a description, estimate an input or propose objects and relationships, but the platform must retain a manual and deterministic path for the same decision. Proposed values remain distinguishable from authoritative values and require the applicable validation, authority, approval and provenance treatment before adoption. The intended reduction in configuration burden is a product direction, not a latency promise or a requirement to expose every configuration mechanic in everyday operation. ## Attention and Operational Activity Attention is a cross-capability behavior contextual to the object, relevant Business, current state/activity/consequences, logged-in user and that user's authority and permissions. It may include pending workflow actions, critical changes, failed or consequential Operations, completed work that matters, recommendations, opportunities, external events, watched-object changes and proposed configuration. Critical, Recommended and Opportunity describe attention semantics; they need not become fixed labels on every screen. Information a user may see is distinct from an action the user may initiate or approve; a workflow/action outside the user's authority must not appear as an actionable available action. Watching may apply to an object, collection, business area, process, workflow or metric. Sensible contextual defaults should surface meaningful changes without making the user manually subscribe to the whole business. Routine successful automation should remain visible through useful summaries and activity/history views without overwhelming the primary attention surface. Operational history is both auditability and future business information. Counts of automated logic operations, workflow activity, human decisions, external operations, imported datasets and significant configuration changes may support business understanding when their source, scope and measurement basis remain clear. Detailed event, outcome and provenance records remain governed by their canonical architecture owners. ## External Information and Network Learning Live integration and dataset ingestion are distinct capabilities. An integration exchanges information with a connected external resource when an approved connection is available. Dataset ingestion imports a bounded CSV, spreadsheet, export, archive or other structured dataset, then maps, validates and governs useful information into the shared Business model where appropriate. Imported information remains attributable to its source and is not authoritative merely because ingestion succeeded. Marketing is an outward-facing and information-producing future capability/domain constructed from the same universal object model. It can use business identity, brand, products, services, knowledge, customer context and analytics across channels, while responses and measured outcomes can contribute to later business knowledge and recommendations without creating a duplicated marketing data universe. Marketing's network emerges from ordinary addressable objects and relationships. Audiences, contacts, prospects, customers, propositions, products and services, content, creative assets, channels, websites, social activity, print activity, campaigns, messages, interactions, responses, opportunities, outcomes and performance are illustrative structures that may be described by Definitions and composed from Data, Workflow and Logic. They are not a fixed Marketing schema, campaign engine, network primitive or special capability mechanism. A relationship may itself be an object containing Data, Workflow and Logic when its context, provenance, lifecycle or activity requires that identity. The future Marketing capability should eventually be capable of marketing Idiosyncrasy itself. That is a validation/use case for the generic model: propositions, audiences, content, channels, campaigns, workflows, responses and outcomes can represent Idiosyncrasy's own marketing activity. It is not a reason to introduce Idiosyncrasy-specific Marketing architecture. Network participation may introduce a Business through a legitimate relationship, external/public source or another Business's attributable assertion before a User is associated with that Business. The platform may accumulate useful information and evidence around that Business and later present an evidence-led contextual opportunity for authorised representation or capability adoption. This is a product direction, not a `claimed`/`unclaimed` lifecycle, automatic authority grant, guaranteed acquisition flow or replacement for explicit User association, authority, entitlement and provenance checks. Patterns observed across businesses may eventually produce contextual recommendations about configuration, workflows, logic, communication or operating practice. A standard platform Definition may be instantiated for a Business, modified through normal Data, Workflow and Logic mechanisms, and later recognised as a candidate reusable derivative or pattern. Promotion of that derivative into a platform-level Definition or pattern requires explicit human authority; observed behavior must not automatically mutate authoritative platform Definitions. This area remains open for further exploration: no cross-business learning mechanism, universal recommendation score or final discovery experience is established here. Any future recommendation must preserve Business isolation and must not expose or silently import another Business's source data, knowledge, identity or operational records. The same principle applies to a Business's own continuous evolution: observed history may lead to a proposal, but adoption remains governed, attributable and measurable. ## Capability Catalogue ### CRM Maintain a coherent customer relationship: a colleague reviewing Acme sees opportunities, interactions, work and relevant knowledge together. Shared Customer, Person, Organisation and Interaction objects connect to Opportunity and Project objects. Dependencies: View/UI, Communication, Knowledge and Analytics. Permissions limit customer context and private notes; history identifies interaction authors, relationship changes and prior customer states. ### People and Contacts Find the right person and contact method without re-entering a contact in every application. Person objects relate to organisations, responsibilities and interactions; a contact preference can remain a scalar while its explanation is linked knowledge. Dependencies: View/UI, Communication and Knowledge. Access to contact details and communication use must be scoped; changes to details, responsibility and recorded preferences remain explainable. ### Organisations Represent customers, suppliers, partners and other organisations in their business context. For example, one Organisation can be both a supplier and a customer, with different people responsible for purchasing and sales. Dependencies: View/UI and Knowledge, using Organisation, Person and typed role relationships. Business roles do not grant tenant access; role dates, source and changes matter to history. ### Sales and Pipeline See the canonical [Sales Capability Definition](#sales-capability-definition). Its product boundary covers the lifecycle from unconverted contact/prospect through qualification, opportunity, commercial proposition and sale, with shared identity, offering, and Project handoff boundaries. ### Products and Services Describe what the business offers and connect it to delivery knowledge: a service quote references an offering and applicable pricing policy. Product and Service objects relate to documents, knowledge, content and orders. Dependencies: Knowledge, Content and View/UI. Control who changes offerings or pricing references, and retain the relevant description or policy context for an earlier transaction. ### Projects Coordinate delivery for a customer without creating another customer directory. A Project relates to its customer, tasks, people, documents and outcomes; a project detail view assembles these shared objects. Dependencies: Workflow, View/UI, Knowledge and Analytics. Project participation and document visibility need explicit scope; assignment, milestone and completion history explain progress. ### Tasks Make responsibilities actionable: an accepted sale creates follow-up tasks assigned to the appropriate people. Task objects relate to the originating opportunity, project, workflow execution or service visit. Dependencies: Workflow, Automation/Scheduling, Communication and View/UI. Assignment is not permission escalation; due-date changes, reassignment, completion and failed reminders must be attributable. ### Operations Coordinate the actual work of a business, including service delivery, exceptions and handovers. A configured operational process links equipment, jobs, tasks, parts, people and procedures rather than requiring a new foundation. Dependencies: Workflow, Knowledge, Communication, View/UI and Analytics. Limit operational changes by responsibility and authority; retain exceptions, approvals and outcomes. See [equipment servicing](#equipment-servicing-example). ### Marketing Plan campaigns around business goals, audiences, content and outcomes. A Campaign can relate to a Goal, budget, audience and overlapping activities, allowing a planner and detail view to show the same work in different ways. Dependencies: Content, Workflow, Automation/Scheduling, Communication and Analytics. Approvals and audience access apply before delivery; retain plan changes, publication decisions and measured outcomes. ### Email Marketing Prepare and deliver an email to an authorized audience with reusable content and a recorded result. Campaign, Audience, Message, Template and delivery-related objects reuse contacts and their applicable communication preferences. Dependencies: Content, Communication, Integration, Workflow and Automation/Scheduling. Check audience use and send authority; distinguish scheduled intent, attempted delivery, confirmed delivery and response history. ### Social Media Campaigns Coordinate channel-specific content from one campaign: prepare variants for supported accounts, approve them and inspect delivery results. Campaign and content objects relate to channel/account configuration and publication outcomes. Dependencies: Content, Integration, Communication, Workflow and Analytics. Account-scoped publication rights and backend capability limits apply; record variant, approval, external identifier and failure context. ### Websites and CMS Manage pages, templates, blocks/components, media and reusable sections as business content. A website page can use the same service description and enquiry workflow as sales; a content editor must work without AI. Dependencies: Content, View/UI, Workflow and Integration where an external backend is selected. Editing and publishing are distinct authorities; versions, publication state and backend results remain distinguishable. ### Forms Collect validated business information directly into the shared model: a website enquiry form creates an Enquiry and connects it to people and organisations. Form and View definitions are addressable configuration, not hidden per-page schemas. Dependencies: View/UI and Workflow, plus Content or Integration for the hosting surface. Validate submissions under explicit intake authority; record provenance without exposing existing private records to the submitter. ### Customer Communications Keep conversations and operational messages connected to their business purpose. A confirmation, project update or service reminder relates a Message or Interaction to a person and the originating work. Dependencies: Communication, Integration, Workflow and View/UI. Apply recipient, channel and data-access controls; conversation history and delivery history must not be mistaken for business events or audit evidence alone. ### Documents Reuse files and their business context: the pricing-policy PDF can support a quote, procedure lookup and an approval review. Document objects relate to content, knowledge, offerings and the business objects they concern. Dependencies: Content, Knowledge and View/UI. Upload, read, share and replace permissions differ; retain source, author and relevant version links rather than silently replacing the evidence for an old decision. ### Reporting and Analytics Answer operational as well as marketing questions: compare enquiry-to-response time, unfinished tasks, sales results and campaign performance. Metric, report and outcome definitions relate to shared objects, goals and workflow executions. Dependencies: Analytics, View/UI and relevant historical retrieval. Reports must respect underlying access and explain measurement period, source and definition; an aggregate must not leak another business's data. ### Automation Remove repeatable manual work while preserving a visible process: a sale can initiate tasks, approvals, waits and communications. Workflow definitions, nodes, schedules and executions relate to the affected business objects. Dependencies: Workflow, Automation/Scheduling and the responsibilities used by each action. Execution authority is bounded; record conditions, approvals, failures and outcomes. The settled runtime contract owns retry, version concurrency and recovery; implementation parameters cannot weaken it. ### Knowledge Management Retain business memory beyond fields: policies, procedures, explanations, observations and customer-specific notes can be found and related to work. Knowledge items connect to Documents, People, Products and other knowledge. Dependencies: Knowledge and View/UI, using [structured-first retrieval](../architecture/retrieval.md). Preserve source, authority, applicability and review dates; an inference or AI suggestion must not silently become approved policy. ### Customer Portals Expose a deliberately scoped view of shared work: a customer sees permitted project progress, documents or forms without a separate copy of the project model. Portal, View and Form definitions select business objects and permitted actions. Dependencies: View/UI, Content, Workflow and Communication. Portal membership and field/object visibility require explicit governance; record submissions, approvals and sharing changes without assuming a legacy client role. ### Finance-Related Workflows Coordinate commercial processes such as quote approval, payment follow-up and invoice-related tasks. Quote, Order, invoice/payment references and Goal or Policy objects can connect sales work to financial evidence. Dependencies: Workflow, Communication, Integration and Analytics. Restrict sensitive values and approvals and retain source/version context; this capability is not a promise to deliver a full accounting ledger, tax system or ERP initially. ### Integrations Connect external services without surrendering the internal business model: an approved publication or imported order maps external information to shared objects. Integration configuration, discovered tool definitions and external references remain typed platform data. Dependencies: Integration, Communication and Workflow as appropriate. Scope credentials and tool access, validate imported data, and record provenance, remote changes and partial failures; a provider-specific data universe is not a valid shortcut. ### AI-Assisted Operations Optionally help people summarise an enquiry, draft content, inspect knowledge or propose a workflow. Proposed content, knowledge, configuration and analysis relate to their sources and affected business objects; humans can perform the underlying business work without AI. Dependencies: AI/Intelligence with Knowledge, Analytics and optional Evolution/Optimisation, through authorized retrieval and deterministic execution. Validate and authorize before applying output; preserve proposal provenance, approval and outcome separately. ## Website Enquiry Example The following source demonstration is a proposed cross-capability flow, not an assertion of a working form, connector or workflow runtime. Its business steps can be configured, reviewed and operated without AI. 1. A website form submits validated information and creates an Enquiry object under the permitted intake context. 2. The Enquiry is related to a Person and/or Organisation; uncertain matching is surfaced for human resolution rather than silently merging identities. 3. The platform records the business event `enquiry.received` with subject and source context. 4. A configured workflow evaluates the enquiry against its conditions and applicable governance. 5. A Customer object is matched or created and linked to the enquiry and relevant person/organisation; the same customer context is reused downstream. 6. A Sales Opportunity is created with its connection to the customer and source enquiry intact. 7. A Task is assigned to the responsible person, with a visible business reason and link to the originating work. 8. A confirmation email is sent through an authorized communication path; its delivery result is recorded separately from the enquiry event. 9. The Interaction is recorded against the relevant business objects so CRM and sales can see it. 10. Relevant knowledge can be attached, such as a product procedure, customer preference or explanation useful to the response. 11. Dashboard metrics update from the recorded business activity and outcomes, preserving their measurement context. 12. AI may optionally summarise or classify the enquiry using authorized context; its absence must not block steps 1-11. The proof is shared identity and traceability across website, CRM, sales, task management, communications, knowledge and analytics. Human review must resolve ambiguous matches or missing authority. A failed email must be visible without pretending the enquiry failed to exist or the recipient was contacted. Execution ordering guarantees, transactional boundaries and recovery behavior are deliberately left to [workflows and automation](../architecture/workflows-and-automation.md) and approved implementation decisions, not inferred from this numbered business narrative. ## Equipment-Servicing Example A request to manage equipment servicing should first compose Objects + Types + Relationships + Knowledge + Workflow + Communication + Views. It does not by itself justify an `EquipmentServicingEngine`. - Define Equipment, Service Contract, Service Event, Technician and Parts types using the existing type system. These are illustrative business concepts, not new foundational tables. - Relate Equipment to its owner and Service Contract; relate a planned/completed service visit to that equipment, the responsible Technician and any Parts used. A Technician can reference an existing Person rather than duplicate identity. - Treat the source's Service Event as a business service-occurrence concept whose state is managed explicitly; completion may produce a separate platform event such as `task.completed` or a configured service-completion event. A planned appointment is not evidence that servicing happened. - Attach maintenance instructions, manuals, safety procedures, observations and previous service knowledge through the Knowledge responsibility. A technician can read these without a model provider. - Configure a workflow to identify due work, create or assign tasks, request any needed approval, record inspection results and complete the visit. This is a broader conformance example; the [roadmap](roadmap.md) prioritises the bounded Spearmint process before specialist scheduling. - Use Communication for reminders, customer confirmations and follow-up, retaining delivery outcomes and links to the contract or visit. - Configure equipment detail views, contract lists, technician work queues and service history from the same objects. A human can arrange and complete work even when AI is disabled. - Apply permissions to equipment, customer context, technician assignment and contract changes. Record part usage, observations, approvals and completion context so future servicing can be explained. If many businesses need specialist scheduling, route optimisation and technician dispatch, a reusable Service Management capability may be worthwhile. Only genuinely unsupported reusable execution behavior justifies considering a new engine through the [architectural test](definition.md#seven-question-architectural-test). ## Scope and Dependencies The [roadmap](roadmap.md) chooses Spearmint Design's bounded business process, not completion of this catalogue or a generic CRM. Native CMS, live WordPress and broader integrations are later implementation depth, not an architecture approval gate for the first milestone. No old commercial support or migration commitments are inherited. Detailed ownership stays with the architecture peers linked above, including [views and content](../architecture/views-and-content.md), [communication and integrations](../architecture/communication-and-integrations.md), [knowledge](../architecture/knowledge.md), [analytics and evolution](../architecture/analytics-and-evolution.md) and [AI](../architecture/ai.md). Existing marketing code creates no compatibility or migration obligations for these capabilities. ## Provisional Future Capability / Business Configuration Domains Future capability discovery is an important product concern, but its exact interaction model and presentation elements have not yet been defined. The platform should preserve room to discover capabilities beyond the current catalogue without presenting unavailable capability as a functional action or constraining a Business to today's domains. Recommendations, cross-business patterns, analytics, integrations and AI remain areas for subsequent exploration under their existing canonical owners. The following domains are areas identified for future exploration, not frozen requirements or a closed catalogue. They are not necessarily independent modules; domains may overlap, the list is not exhaustive, capabilities may move between future IDY stages, and actual Surface UI use may change these assumptions. A Business Configuration Domain does not automatically correspond to an IDY stage. One stage may support several domains, one domain may need several stages, and a future stage may have no single business-domain label. For example, `Finance` must not become `IDY-011 = Finance` unless a later exploration/PLAN process establishes that relationship. - **Marketing & Communications:** website/web, social media, print, campaigns, content, email, communications and brand/assets. - **Finance / Accounts:** income/expenditure, invoicing, payments, budgets, suppliers, financial reporting and accounting integrations. - **Products & Services:** product catalogues, services, variants, pricing, packages, availability and lifecycle. - **Sales / CRM:** prospects, enquiries, qualification, opportunities, customers, quotations and sales processes. - **Operations / Logistics:** orders, fulfilment, purchasing, suppliers, stock/inventory, delivery, scheduling, locations and operational resources. - **Personnel / Staff / HR:** people, roles, responsibilities, skills, availability, recruitment, onboarding, training and organisational structures. - **Projects & Work.** - **Customers & Relationships.** - **Knowledge & Documentation.** - **Assets & Resources.** - **Contracts & Legal.** - **Compliance & Risk.** - **Planning & Objectives.** - **Analytics / Business Intelligence.** - **Business Evolution.** - **Events & Scheduling.** - **Procurement & Suppliers.** - **Support / Service Delivery.** - **Integrations & External Systems.** - **Automation & Workflows.** - **AI Assistance / Business Learning.** These areas remain open-ended and intentionally refinable. They are capability directions to investigate through the Surface UI and later PLAN/BUILD cycles, not mandatory independent modules, implementation commitments or future architecture decisions.