# Business Graph and Business DNA

Status: settled semantic contract, 2026-09-11. Physical relationship storage and business configuration are specified separately; no business-model runtime is claimed as implemented.

Owns: Business Graph, relationship meaning and integrity, the Relationship responsibility, Business DNA and business-specific model assembly. [Core object model and authority](core-object-model-and-authority.md) owns the cross-cutting object/definition/state distinctions; [Objects and types](objects-and-types.md) owns the universal primitive and typed validity; [identity and governance](identity-and-governance.md) owns authority and isolation.

Lineage: source 02 sections 2, 3.3, 5 and 11, source 01's business ownership and extensibility intent, source 03's shared-capability examples, and the corresponding source 00 sections. See the [source ledger](../governance/source-map.md).

## Current presentation ownership

The current Business presentation model has one root only:

```text
Business
└── presentation.dashboard_ref
    └── Dashboard Presentation Object
        └── recursively persisted child Presentation Objects
```

`dashboard_ref` is governed Business configuration containing the exact
Presentation Object identity and revision. It is not a second relationship Type
and does not create a Business-level collection of presentation roots. Direct
Dashboard children are navigable only when their persisted presentation
configuration declares `navigation.navigable: true`.

Capability Definitions, Capability Instances and Capability-specific runtime
paths are retired. Product labels such as People, Marketing, Sales and Projects
are data-defined Presentation Objects and ordinary domain Objects, not a runtime
Capability layer. Older capability wording below is historical lineage and must
not be used as current implementation authority.

## One Connected Business Model

## Business As An Independent Entity

A Business is a first-class entity with its own identity and connected Business Graph and Business DNA. Its data, models, workflows, knowledge, configuration, history and governance persist independently of which Users currently administer it.

Business identity is distinct from creator provenance, Membership, AuthorityGrant and subscription entitlement. Business creation records the creating User (the platform-scoped authenticated account; legacy Type name Principal) as historical provenance and establishes initial administration through the governed authority model; it does not create a permanent Business owner. Administration may later be delegated, restricted, transferred or revoked without transferring or replacing the Business identity.

Business existence, network participation, User association, authority to act for the Business and subscription entitlement are separate facts. A Business can enter the network through a legitimate relationship, be referenced by an authorised source or participate in a relationship-mediated introduction before an associated User exists. It can therefore accumulate attributable information, observations and relationships before any User is authorised to represent it. This does not create a Business lifecycle state such as `claimed`, `unclaimed`, `recognised` or `authorised`, and it does not imply membership, ownership, authority, authentication or subscription. The applicable conclusion is derived from the graph, evidence, authority and entitlement in context.

Business lifecycle includes creation, ordinary governed administration, suspension of operational use while an entitlement is inactive, and reactivation without reconstructing the Business or its Graph/DNA (intended future architecture; all Businesses are currently treated as active and no entitlement is enforced; `business.create` is free and does not require entitlement). [Identity and governance](identity-and-governance.md) owns authority semantics and [subscriptions and entitlements](subscriptions-and-entitlements.md) owns subscription state and the operational gate.

Genesis never creates a Business and there is no special first Business. Every normal Business, including Spearmint Design for the IDY-009 demonstrator, is created through the governed platform-scoped `business.create` operation. That operation supplies server-owned identity, creator provenance and initial Business governance atomically; it is not Genesis or a platform configuration shortcut.

The Business Graph is the connected set of addressable objects and their relationships. It includes business data, definitions, configuration, workflows, knowledge, events, permissions and other addressable platform concepts under the same universal model.

Business DNA is the business-specific semantic and configuration representation expressed within that graph. It describes the business's vocabulary, structures, relationships and configured behavior; it is not a second graph, a separate store or an AI memory database.

"Business model" and "business data" distinguish meaning: definitions describe concepts and instances express particular facts or work. They do not establish different foundational object formats. Both follow [objects and types](objects-and-types.md), including its allowance for ordinary nested scalar values.

A Customer reused in CRM, sales, projects, marketing and reporting remains the same addressable object. A knowledge item, workflow definition or policy can connect to that customer without introducing a new capability-owned representation.

Graph traversal is a conceptual operation, not a graph-database requirement. [Implementation architecture](../implementation/architecture.md) specifies physical storage, indexing and reference resolution under this settled model.

## Relationship Identity and Meaning

A relationship expresses a meaningful connection between objects. Its type identifies the meaning of that connection; endpoint addresses identify what is connected. Relationship labels or displayed names are not substitutes for endpoint identity.

Relationships are first-class addressable data when they require independent identity, metadata, lifecycle, provenance or history. They use the universal primitive rather than a special foundational edge format. Not every nested scalar or reference must acquire an independent relationship object. Initial physical granularity is specified in [implementation architecture](../implementation/architecture.md#physical-model-mapping), without changing these distinctions.

A relationship may have more than two endpoints and may contain endpoint roles, conditions or other constituent objects. Its endpoint data and relationship revision remain distinct from a display label or an inferred connection. Relationships are ordinary objects and may themselves contain Data, Workflow and Logic, allowing a relationship to carry active context, conditions, provenance or workflowed behavior rather than functioning only as a static link. A containing Business or other object derives applicable condition from its constituents and relationships; a child change can therefore propagate a derived-state change through the containing graph without a manually assigned parent status.

The actual graph is the authority for what exists. A definition, semantic mapping, assertion or traversal can describe or propose meaning, but cannot silently create a relationship, adopt a definition or grant authority. If endpoint data is removed, retired or becomes inaccessible, the relationship remains addressable where its identity and history are required. The resulting unresolved or inaccessible endpoint is a condition for governed resolution, not an instruction to silently cascade-destroy the relationship.

An illustrative relationship, with symbolic addresses and nonnormative field names:

```text
{
  id: relationship/alex-acme-contact,
  type: type/organisation-contact,
  value: {
    person: person/alex,
    organisation: organisation/acme,
    role: "purchasing contact",
    effectiveFrom: "2026-09-11",
    source: document/contact-confirmation
  }
}
```

The relationship type is itself addressable under the type contract. The example does not approve slash-separated identifiers, a reference encoding, date serialization or a database layout. Role text can be scalar here; a reusable, independently governed role concept can instead be addressable.

## Relationship Type Ownership and Semantic Mapping

The Business owns the relationship semantics of its own domain. A Business Relationship Type belongs to one Business and may define its Business meaning and terminology, permitted endpoint types, direction, cardinality and slot constraints, applicable lifecycle and integrity semantics, revision, provenance and history. Subject to the platform-wide object, integrity, security and authorization invariants, it is independently valid and usable without a Platform Semantic Concept or any semantic mapping. Any application of the Relationship Type remains subject to the governed operation/workflow boundary; the Type itself is not a Workflow or Logic execution instruction.

The platform may provide optional reusable Platform Semantic Concepts as platform-level semantic knowledge. A Platform Semantic Concept does not own a Business Relationship Type, is not a mandatory parent or ontology prerequisite, cannot silently impose Business semantics, and may evolve independently of Business Relationship Types.

A Business Relationship Type may have an explicit, governed and traceable mapping to one or more applicable Platform Semantic Concepts. A mapping is governed configuration under the universal object, provenance and history contracts where it requires independent identity or lifecycle. It does not redefine the Business Relationship Type, change its runtime meaning or become its source of authority. A mapping may be absent, changed or removed without invalidating the Business Relationship Type or its relationship instances. Similar terminology never establishes semantic equivalence, and an AI proposal is not authoritative configuration until it passes deterministic validation and the required approval process.

Business authority governs Business-owned Relationship Types, including their terminology, applicable domain constraints, use, revision and retirement, subject to platform invariants. Platform authority governs universal object identity, Business isolation, authorization, security, universal relationship integrity, Platform Semantic Concepts and applicable platform-level semantic governance. Exact administrative approval roles and whether a particular mapping requires platform approval remain governance details unless separately approved.

This is a deliberate hybrid model. The product principle is: **Do not simplify the underlying model merely to make the product appear simple. Build the sophisticated model, then construct progressively simpler representations of it.** Future interfaces should provide progressively simpler views over the same governed model rather than simplifying or replacing its semantic authority.

Useful relationship meanings from the sources include:

| Connection | Business meaning that must remain explicit |
|---|---|
| Person belongs to Organisation | Business affiliation or role, potentially dated; not automatic account membership. |
| Customer owns Project | Commercial/delivery context, distinct from permission ownership. |
| Project contains Task | Work structure and contextual navigation. |
| Campaign targets Customer Segment | Audience intent, not permission to contact every related person. |
| Document relates to Project | Reusable evidence or content in a work context. |
| Knowledge item applies to Product | Applicability of a procedure, explanation or policy. |
| Workflow operates on Order | Process context, not authority to execute every action on that order. |

Relationships may carry dates, roles, permissions, state, metadata and historical links. Their meaning must remain inspectable independently of whichever application happens to display them.

## Integrity, Cardinality and Lifecycle

Relationship definitions need to express permitted endpoint types and the intended meaning of direction and roles. A valid connection must not silently point at the wrong kind of object, cross an unauthorized isolation boundary or change meaning when an endpoint label changes.

Relationship types explicitly declare supported endpoint, direction, cardinality and integrity constraints. Do not assume every relationship is many-to-many, every relation bidirectional, or one person's organisation affiliation necessarily exclusive. Concrete declarations are business/type configuration; unsupported declarations fail validation rather than acquiring invented defaults.

Lifecycle questions include when a relationship becomes applicable, how it ends, whether it can be superseded, and what happens if an endpoint is removed or becomes inaccessible. An ended business affiliation is not the same as erasing that it once existed.

These outcomes remain distinct: ordinary removal clears or replaces current relationship data without normally destroying the relationship object or its history; an endpoint becoming unresolved or inaccessible leaves the relationship addressable for governed resolution; correction or substitution is an explicit, attributable change; retirement is an explicit lifecycle transition; and genuine destruction is a separate, exceptional governed operation. None of these outcomes silently cascade-destroys dependent objects, endpoints or historical evidence.

The relationship must be validated against applicable type and governance rules before it becomes authoritative. The initial validator rejects unresolved or unauthorised endpoints and conflicting declared cardinality, uses expected versions for concurrent changes and retains links to retired endpoints for authorised history. These mechanisms are specified in [implementation architecture](../implementation/architecture.md#physical-model-mapping), not hidden in adapter/UI convenience.

[Time and events](time-and-events.md) owns effective/recorded time, historical references and correction questions. This document requires relationship meaning to survive relevant history; it does not select cascading deletion, soft deletion or an immutable relationship store.

## Assertions, Derivation and Applicability

An Assertion represents a claim, not proof that the claim is true or authority to act on it. Existence, accepted/verified standing, contextual applicability and permitted use are separate. [Knowledge](knowledge.md) owns epistemic standing and provenance; [identity and governance](identity-and-governance.md) owns authority.

Relationship meaning and direction are explicit. Traversing a path does not infer another business relationship or conclusion. Derived relationships may be materialised only with explicit derivation and provenance; they do not become self-evident facts because they were stored. Relationships may make a Rule or Policy applicable, but never grant authority by themselves.

Assertions have scope that is explicit or deterministically derived from governed rules. Evaluate applicability for the current Business, object, relationship, time, workflow, action, service, geography or classification as relevant. Acceptance does not broaden scope. The chain is Assertion -> Standing -> Scope/Context -> Applicability -> Permitted use; applicability still is not authority.

For example, ClientCo uses Service A for Project P123 does not establish use of Service A for all ClientCo projects. A project-scoped Policy can be read elsewhere without governing the reader's unrelated action.

Preserve conflicting Assertions with their sources, time and standing. Challenge, rejection, supersession and human resolution do not erase the original claim. Human resolution produces an addressable [Decision](semantics.md#decision) or [Action](workflows-and-automation.md), with rationale and provenance. The Graph is descriptive, provenance-aware and non-destructive, not simply the latest opinion on connected records.

Network participation and accumulated information do not by themselves establish a User association or authority to act for the Business. When a User later becomes associated through an approved relationship, that association changes what may be represented or acted upon; it does not erase earlier external, network or other-Business evidence. Derived views may select information that is applicable and authoritative for a particular question, but the underlying assertions, sources, conflicts, temporal context and derivation remain inspectable. A derived relationship or classification may be materialised for retrieval, but storage of the result does not turn it into an independent fact.

## Relationship Responsibility

The Relationship responsibility supplies reusable connection management and navigation to capabilities. This is an architectural responsibility, not a requirement for a particular class, module or service.

| Contract aspect | Required concern |
|---|---|
| Inputs | Endpoint identities, relationship type and typed value, requested operation, relevant configuration, acting User (or the User whose delegated authority an automation operates under) and isolation context. |
| Read/navigation | Resolve permitted connections and provide contextual graph information without duplicating related business objects into capability-owned models. |
| Mutation | Create, amend, end or otherwise manage relationships as allowed by the approved type, lifecycle and governance contracts. |
| Validation | Check endpoint/type compatibility, required metadata and the selected integrity/cardinality rules; type validity alone does not authorize a connection. |
| Outcomes | Report the permitted result or a meaningful failure, with enough context for the calling workflow or human to respond. |
| Events/history | Make significant relationship changes explainable with actor/source and relevant temporal context under the Event and history contract. |
| Failures | Handle invalid types, missing or inaccessible endpoints, unauthorized links and selected integrity conflicts explicitly; do not create a misleading authoritative connection. |

Reading an endpoint does not necessarily authorize reading every relationship or the other endpoint. Relationship metadata can itself be sensitive, and even revealing that a connection exists can disclose information.

[Identity and governance](identity-and-governance.md) owns those access decisions. [Retrieval](retrieval.md) owns candidate selection and authorized traversal for queries; the Relationship responsibility supplies the connection semantics on which retrieval depends.

Workflows can request relationship changes but cannot bypass their validation or authority checks. Event delivery, transaction boundaries and concurrency guarantees depend on [workflow execution](workflows-and-automation.md) and implementation decisions, not this contract table.

## Business DNA

The first implemented initialization slice uses the Business Definition as a platform-owned descriptive composition for an existing Business instance. Its constituent requirements are resolved against actual object data; Memberships, AuthorityGrants and Policies remain governance objects and are not duplicated as Business profile constituents. Missing required constituents become explicit workflow requirements, compatible existing constituents are reused, and ambiguous or incompatible existing constituents require governed resolution.

Business DNA makes the business's own interpretation of the platform explicit and durable. It can comprise linked definitions and configuration for:

- Business terminology, types, properties and classifications such as what the business means by a customer, service visit or completed project.
- Relationships, roles, statuses and lifecycle declarations describing how work and participants connect.
- Rules, policies, constraints, goals and recorded decisions, with meanings owned by [semantics](semantics.md).
- Readable workflows and configuration for business behavior, interpreted by the [workflow runtime](workflows-and-automation.md).
- View, form and navigation definitions that present the model through [views and content](views-and-content.md).
- Business-specific brand vocabulary, reusable content and media references, such as approved names, logos and visual preferences.
- Permission declarations, integration configuration and references to applicable procedures or knowledge, interpreted by their respective owners.

These are all shared-model objects or typed values, not fields in a mandatory monolithic "DNA record." Their connections to operational instances are part of the same Business Graph. Constituency is established and changed through the ordinary Data, Workflow, Logic and Presentation mechanisms; Business-to-Presentation association is a generic relationship, not a special capability assignment system or flag.

Configuration must be serializable, versionable, human-readable, AI-readable and schema-validatable under [objects and types](objects-and-types.md). Executable configuration is interpreted by controlled responsibilities; it is not arbitrary application code generated for each business.

A new business concept should normally introduce a type and configuration rather than another foundational schema. Capability composition and the criteria for genuinely new execution behavior are owned only by the [product definition](../product/definition.md#composition-and-extensibility).

## Surface UI and Future Business Configuration

The Business Graph remains the authoritative underlying source of truth while the Surface UI presents it through understandable Business concepts. A person should be able to work with concepts such as Customer, Contact, Enquiry, Qualification, Project, Product, Service, Invoice and Staff member without needing to understand the generic object representation. This is a projection and interaction direction, not permission to create a second rigid domain model or a second mutation system.

The Surface UI is intended to help discover how the existing model becomes a useful Business application. Its use may reveal missing concepts, new relationships, changed priorities, new configuration domains or better boundaries. Business Configuration therefore remains open to refinement: a Business may use one domain, several domains, overlapping domains or a combination not anticipated by the provisional capability catalogue. New capabilities should compose over the common substrate where possible.

The relationship between provisional Business Configuration Domains and future IDY stages is deliberately unresolved. A domain does not automatically become a stage or module; one stage may serve several domains, and one domain may draw on several stages. Future configuration may be performed manually or with optional AI assistance, but AI proposals never become authoritative without the same validation, authorization and approval required of human changes. The Business's evolving vocabulary, capabilities, objects, relationships, processes, terminology, rules and objectives are intended to contribute to its Business DNA, without freezing a final storage or representation here.

A Business is not required to be fully configured at creation. Configuration can accumulate progressively through manual entry, relationships, governed Operations, workflow activity, imported or observed information, Definition adoption and later human decisions. The platform should expose what is known, what remains unresolved and what can happen next without pretending that the Business is more completely understood than the evidence supports. Definitions are one mechanism for deriving missing or applicable configuration; onboarding is not required to become a single mandatory wizard.

## Assembly and Business Ownership

The business representation is a first-class asset under the [product ownership promise](../product/definition.md#business-ownership). Humans must be able to understand what the model says, which configuration applies and what an accepted change would affect.

An assembly can select reusable platform-owned capability definitions and add Business-owned vocabulary, workflows, views and knowledge relationships. Business deviations are expressed as scoped, versioned configuration and instances governed by the platform definition and the Business's authority; they do not create a second capability definition or data universe. Relationship Type ownership is explicit: an existing platform/global Relationship Type may be selected where permitted, while a Business Relationship Type remains owned by its Business. Optional semantic mappings do not create hidden precedence or a mandatory global ontology.

Definitions and configurations identify their owner, scope and versions explicitly. Platform-owned definitions can be reused by more than one Business without transferring ownership; Business-controlled deviations do not alter the platform definition or overwrite another Business's configuration. The initial assembly uses explicit references to installed definition versions and separately governed Business configuration; unsupported composition/sharing operations are refused. [Types](objects-and-types.md) governs validity and [governance](identity-and-governance.md) governs changes.

Definition application is an explicit boundary between a reusable platform composition and Business-owned realization. A platform Capability Definition may contain or reference recursively composed universal Objects, and those Objects may combine multiple semantic roles. Applying it for a Business establishes or resolves ordinary Business-owned Objects/configuration through existing containment, reference, revision, provenance and governed mutation mechanics. It does not mutate the platform Definition, copy Business configuration into platform scope, or create a second capability graph/store. Release/publication identity remains provenance distinct from Definition/Object identity and revision.

Exportability must respect [governance](identity-and-governance.md): it does not authorize revealing another Business's information or copying operational secrets. [Implementation architecture](../implementation/architecture.md#physical-model-mapping) specifies versioned manifests with explicit dependency handling and rejection of conflicting imports. Full distribution tooling is not a first-milestone requirement.

AI may propose a model change, but does not own the model or confer authority on the proposal. A valid proposal must still be authorized and approved where required before controlled application; a rejected proposal must not alter active business meaning.

Over time, governed activity and observations may improve the Business's understanding: activity -> observation -> knowledge/evidence -> pattern -> suggestion -> human approval -> configuration/Business DNA -> improved future operation. A standard platform Definition may be instantiated for a Business, modified through normal Data, Workflow and Logic mechanisms, and later produce a possible reusable derivative or pattern. Promotion of that derivative into a platform-level Definition or pattern requires explicit human authority; the platform must not automatically mutate its authoritative Definitions from observed behavior. Patterns across Businesses may inform reusable Definitions or platform knowledge only under explicit privacy, provenance, isolation and governance constraints. This is a future direction, not an automatic cross-Business learning mechanism or implementation requirement in the current contract.

No old marketing client schema, administrator hierarchy, business-data migration or compatibility obligation is carried forward. Future evolution of the new business model still needs explicit compatibility decisions; absence of legacy obligations is not permission for unexplained future changes.

## Organisation and Customer Example

Consider an Organisation called Acme and a Person called Alex. Alex's relationship to Acme describes a purchasing-contact role, with relevant source and dates. Acme can participate in customer and supplier contexts without being duplicated for each capability.

Whether "customer" is represented as a particular configured type, a role relationship or a composition is a type/model design decision, not a universal mandate here. Whichever approved representation is used must preserve shared identity across enquiries, quotes, projects, communications and reports.

The business Organisation is not automatically a Tenant, and Alex the Person (a Business-scoped profile) is not automatically an authenticated User (a platform-scoped account); neither requires the other and there is no implied one-to-one link. If Alex is invited to a portal, the platform must establish the relevant User and membership authority explicitly through [identity and governance](identity-and-governance.md).

A project can link to the customer context, its tasks, service documents and applicable knowledge. A pricing-policy change can affect future work without silently changing the explanation for an earlier accepted quote; historical interpretation belongs to [time and events](time-and-events.md).

## Conformance and Implementation

- Conforming: CRM and operations navigate the same person/organisation context; relation metadata preserves who was responsible and when it applied.
- Conforming: an Equipment type, servicing workflow, procedure and technician view participate in the existing graph and retrieval model without a new data foundation.
- Nonconforming: Business DNA lives in an unrelated authoritative schema, a campaign maintains its own isolated customer identities, or a business affiliation silently grants account access.
- Nonconforming: AI introduces an active relationship or policy change without the same validation and authorization required of a human request.

[Settled D01-D10](../governance/decisions.md) govern the model. [Implementation architecture](../implementation/architecture.md) specifies relationship persistence and validation. Conformance must reject connectivity-based authority, preserve contextual assertions and their history, and keep the same identity across capabilities. Limited first-milestone configuration does not remove these distinctions.