Skip to main content

Canonical Business Context Model

The Canonical Business Context Model (BCM) is the built-in schema the Asset Registry uses to describe a customer's business and the software that runs it. It organises Element Types into three layers — Business, Technical, and Impact — plus a dedicated People & Budget extension that provides the ownership and accountability axes used by AI Dev Cost and similar modules.

All BCM element types live in the same built-in Domain ("Business Context") and Module ("Canonical Business Context"), and are pre-seeded with the element types, type units, and edge types described here.


Business Layer

Describes what is being sold and to whom.

Element TypeDescription
ProductGroupingStrategic portfolio or business segment for executive reporting and P&L alignment.
ProductLineFamily of related products sharing a common platform, technology, or market positioning.
ProductAn individual sellable offering (good, software, service, or subscription) that generates revenue.
CustomerSegmentGrouping of customers with shared characteristics for strategic planning and aggregate analysis.
CustomerExternal party (company, organisation, or cohort) that purchases products or services.

Hierarchy edges: Product → ProductLine → ProductGrouping, Customer → CustomerSegment. Business edges: Customer → Product (purchases), Application → Product (realizes), ApplicationDeployment → Customer (serves).


Technical Layer

Describes how the software is implemented and deployed.

Element TypeDescription
ApplicationBusiness function unit (conceptual application).
ApplicationPackageDeployable software artefact (COTS, SaaS, custom, open source, or platform).
ApplicationDeploymentRuntime instance of an ApplicationPackage, tied to an environment and version.
ApplicationComponentFunctional sub-unit of a deployment (API, plugin, module, integration endpoint).
ExposureZoneNetwork exposure classification for security and trust boundaries.

Realisation edge: ApplicationPackage → Application (implements). See Application Package, Application Deployment, and Application Component for per-type details.


Impact Layer

Describes how much it matters to the business if an application is compromised or unavailable. Seven impact dimensions attach to Application / ApplicationPackage via IMPACT_ASSESSMENT or CONTAINS edges.

DimensionCaptures
ConfidentialityData classification, PII handling, encryption, third-party access, compliance standards. See CIA Ratings.
IntegrityRPO, customisation, integration complexity, validation, audit logging, reconciliation.
AvailabilityRTO, SLA uptime, HA posture, DR plan, monitoring.
Legal & RegulatoryLicense-to-operate risk, penalties, disclosure obligations, audit/compliance usage.
Public ReputationMedia coverage risk, stakeholder perception, community licence to operate.
Financial ReportingSOX likelihood, reconciliation/journal usage, ERP integration, audit relevance.
Cash ImpactDirect and indirect cash-flow consequences, transaction volume exposure.

See Business Impact for the non-CIA dimensions.


People & Budget Layer

Describes who is building the software and what they are allowed to spend. Introduced to support AI Dev Cost.

Element TypeDescription
OrganizationTop-level tenant. Roots the people hierarchy.
TeamGroup of engineers accountable for Products. Primary unit for AI Dev Cost budgets and adoption metrics.
EngineerIndividual developer; leaf of the hierarchy and unit of attribution for LLM usage, seats, and per-developer budgets.
BudgetSpending envelope over a period (monthly / quarterly / annual), attached via typed edges to an Engineer, Team, Product, or Organization.

See People and Budget for properties, edges, and rollup patterns.


How the layers connect

  • Application realizes Product — links the Technical Layer to the Business Layer.
  • Application has impact edges to each dimension in the Impact Layer.
  • Team owns Product, and engineers belong to Team → Organization — links the People & Budget Layer to the Business Layer.
  • Budget attaches to any node in the people hierarchy or to a Product, so AI Dev Cost rollups can be expressed at any granularity.

Together these layers let a query answer, for a single Application or Product: what it is for (Business Layer), how it is built (Technical Layer), how much it matters (Impact Layer), and who is building it and at what cost (People & Budget Layer).