7lens Data Model — Business

Canonical copy

Copied from the 7lens app repository, docs/datamodel/7lens-data-model-business.md at 012d434, on 2026-11-11. Document version 2.0, dated 2026-10-31. The app repository is the source of truth. Do not edit this page here; change the source and re-run npm run sync:reference.

This is a strategic source document: Domains, Business Applications, and Deployment definitions. A person is accountable_person. A timestamp is RFC 3339 with an offset. A calendar date is YYYY-MM-DD.

Retired notes on application deployment design and schema reconciliation are not a second model.

---

Purpose

The 7lens Business model is the catalog of business areas and the logical systems business users run. A Domain groups Applications and belongs to one Legal Entity. An Application is one enduring business system in exactly one Domain.

Platforms, Services, and Offerings are Technology. An Application is not a Service. Inventory Assets are instances. They can evidence an Application. They do not define it.

This document defines:

1. Domain and Application identity — what each record is, and the identity test that separates an Application from a Platform.
2. Relationships — part_of and depends_on, and the Application-to-Service consumes join.
3. Deployment definitions — how a logical Application is made available, including Entry Points, and how that collection relates to the older flat fields.

Starter-pack contents are not rules. A hyphenated id, a default application_type, or a filled accountable_person in a pack is that pack’s data.

Product copy uses Domain, Application, Deployment, and Entry Point as defined here. In Configuration UI, accountable_person is labelled Owner.

---

Concepts

Identity test

Classify a thing by the first match:

1. ICT Provider — the supplier. Technology.
2. Service — a capability several products could supply. Technology.
3. Offering — one product or variant that supplies a Service. Technology.
4. Platform — something the enterprise operates that supplies Services and that business users work in. Technology. ERP, CRM, HR, and ITSM, when the enterprise operates them, are Platforms.
5. Asset — one real instance. Inventory.
6. Business Application — what business users use to run a business process.

An Application and a Platform have no direct link. An Asset belongs to a Deployment, and that Deployment belongs to an Application or a Platform, not both. consumes[].service is the Service id. Offerings are not targets of consumes.

Domain

Definition

A Domain is a business area that groups Applications. Domains are recursive. A Domain may name another Domain as parentId. The parent chain must not cycle. A child Domain shares its parent’s Legal Entity.

Every Domain belongs to exactly one Legal Entity through legalEntityId. Applications do not store a Legal Entity. Ownership resolves Domain → Legal Entity → Organization.

Identity

Attribute	Rule
id	Stable id, unique among Domains. The Groups slug rule is the style check. A miss warns and does not block save.
name	Human-readable name. Required.
description	What the business area is. Required on a new Domain. An existing empty description warns.
legalEntityId	Id of the Legal Entity. Required. A parent Domain must use the same Legal Entity.
parentId	Optional parent Domain id. null is a root.
accountable_person	Optional Owner. Shape under People.

parentId and legalEntityId are published camelCase names. They stay until a versioned migration. New reference fields use *_id.

What a Domain is not

• Not an Organization node, a Region, or a Legal Entity.
• Not a Technology Stack.
• Not a Group. Cross-cutting classification is a Group. Business Line is a Group, not a level of the Domain tree.

---

Application

Definition

An Application is an enduring logical business system that provides functionality to business users, customers, or other consumers.

Its identity is the system it represents. It is not a running instance, an infrastructure resource, a library, or a vendor product. Several technical elements may implement one Application. Separate Application records are for independently identifiable business systems.

Every Application belongs to exactly one Domain through domainId.

Identity and required fields

Attribute	Rule
id	Stable id, unique among Applications. Non-empty. The ingest pattern app.{unit}.{slug} is not this id.
name	Human-readable name. Required.
description	What the business system is. Required on a new Application. An existing empty description warns.
domainId	The one Domain. Required. Published camelCase.
accountable_person	Optional Owner. When a person is stored, this is the only shape.

These stay on the Application because they describe the logical system, not one Deployment:

Attribute	Rule
audience	external, internal, or mixed. The parse default is internal.
application_type	saas, internal_application, or third_party_application. The parse default is internal_application. That default is not evidence of sourcing or delivery.
sourcing_model	Optional. Who controls the product. No default.
delivery_model	Optional. How it is provided. No default. Independent of sourcing_model.
consumes	consumes[].service is the Service id. The list may be empty. An Offering id is not a valid target. An Application and a Platform have no direct link.

New Configuration writes reject free-text accountable, including an empty string, and reject owner and ownerPerson. An existing non-empty accountable warns. The person, when one is stored, is accountable_person.

What an Application is not

• Not a Service, an Offering, or a Platform. An Application and a Platform have no direct link.
• Not an Asset, and not a Deployment.
• Not a Group value.

---

Sourcing and delivery

sourcing_model is who controls the Application as a product. delivery_model is how it is provided. Neither is inferred from the other, from application_type, from deployed_in, or from Inventory.

sourcing_model	Meaning
in_house	The organization controls the product. A supplier may build or operate it.
third_party	An external party controls the product.
joint	Product control is shared, with shared decision rights. Co-development or hosting alone is not joint.

delivery_model	Meaning
saas	Consumed as a provider-operated product. The consumer configures it and does not run the deployment.
self_deployed	The organization deploys it into an environment it controls. The infrastructure may still be a cloud.
provider_hosted	An external provider hosts it, and it is not consumed as standard SaaS.
hybrid	The same logical Application uses materially different delivery arrangements. Several regions or environments alone are not hybrid.

Every pairing is allowed. Unset means not yet classified. There is no unknown value. Do not backfill these fields from application_type. A stored default of internal_application is unconfirmed.

application_type remains until an explicit deprecation.

---

Relationships

Application-to-Application relationships are the collection business.applicationRelationships. They are not fields on the Application, and they are not graph-only. Graph PART_OF remains Application → Domain.

A relationship is { sourceApplicationId, type, targetApplicationId }. There is no relationship id. The canonical types are part_of and depends_on.

part_of

Directed from the constituent Application to its parent. At most one parent. No self-link. No cycle. The child and the parent resolve through their Domains to the same Legal Entity. They may sit in different Domains of that Legal Entity. A cross-Legal-Entity part_of is invalid. An unresolved Legal Entity is an error.

part_of does not transfer ownership and does not imply depends_on.

depends_on

Directed from the consumer to the Application it relies on. Several Applications may depend on one shared Application, including across Legal Entities. No self-link. Both endpoints exist. Deleting an Application must not leave a dangling endpoint. A cycle is not forbidden.

depends_on is not composition.

Deleting a parent does not reparent children. The relationship is removed or retargeted in the same configuration write. environments value decom is not deletion.

No other Application-to-Application type is canonical. integrates_with and interacts_with are not core types. Portfolio grouping is a Group or a Domain, not a relationship.

sourceApplicationId and targetApplicationId are published camelCase. New reference fields use *_id.

---

Technology dependency

consumes[].service is the Application-to-Service join. The value is a Service id. An Offering id is not a valid target. An empty consumes list is allowed. The ingest wire may still require one entry. That wire is not this record.

Inventory may trace or contradict a declared consume. It does not rewrite consumes. Discovery does not silently change an Application.

An Application and a Platform have no direct link.

---

Deployment

Definition

A Deployment is a defined way of making a logical Application available in one customer-defined context. It is part of the Application. It is not a live runtime, and it does not assert that the runtime is up.

Deployments are nested:

business.applications[].deployments[]

An Application has zero or more Deployments. The model does not require one Deployment per region, account, cluster, provider, or environment.

The Application payload is authoritative. A graph projection may emit a derived application_deployment node (applicationId/deploymentId) linked by HAS_DEPLOYMENT. That node is not read back into the payload.

Fields

Field	Rule
id	Required. Unique within the Application. Published grammar ^[a-z][a-z0-9\-_.]*$. A non-snake_case segment warns.
name	Required human-readable label.
environments	Optional. sandbox, dev, pre, pro, decom. Labels, not a lifecycle.
deployed_in	Optional location (tier + id). Where it runs. Not ownership.
entry_points	Optional. Several, including several of the same type.
deployable	Optional deployability object.

Qualified references use applicationId/deploymentId.

repositoryAssetIds may still appear on older rows. It is read for v1 data only and is no longer written. Deployments do not list Assets. An Asset points at Deployments, with role runtime or source. That reference is an Inventory field.

An Asset belongs to a Deployment, and that Deployment belongs to an Application or a Platform, not both.

Three collection states

State	Read authority for environment, location, Entry Points, and deployable
deployments absent	The flat Application fields. Do not invent Deployments from schema defaults.
deployments: []	Zero Deployments. Flat fields are not merged back on read.
deployments length ≥ 1	The nested Deployments. Flat fields are residue until an explicit cleanup. They are not a second authority.

The key has no schema default, so absent stays distinct from [].

Flat fields that remain on the Application for that compatibility are deployed_in (default []), environments (default ['pro'] when omitted), entry_points (default []), and optional deployable. deployed_in is never a Legal Entity.

Migration

migrateApplicationDeployments() is explicit. It is not run on read, hydrate, or ordinary save. It creates at most one Deployment, id primary, when deployments is absent and the flat fields carry non-default evidence: a non-empty deployed_in, a non-empty entry_points, environments other than ['pro'], or a deployable that is enabled or has parameters. Defaults alone are not evidence.

On success it clears flat deployed_in, entry_points, and deployable, and resets environments to ['pro'], in the same result. Callers persist that result. Failure leaves the input unchanged.

Entry Points

Entry Point is the term for how a consumer reaches a Deployment. This model does not add a separate Interface entity.

Canonical types, used on Deployment Entry Points:

Type	Meaning
api	Programmatic access.
web_portal	Browser access.
ai_agent	Access through an AI agent.
mobile_application	Access through a mobile client.
other	A governed customer-specific kind.

While deployments is absent, Application-level Entry Points stay web, api, mobile, ai_agent, and graphql. Those names are not renamed on ordinary read or save.

The migration helper, and only that helper, maps web → web_portal, mobile → mobile_application, and graphql → api with protocol: graphql. api and ai_agent are copied. An unknown type skips that Application’s migration. Deployment Entry Points also accept the legacy discriminators so an existing nested value still reads.

What a Deployment is not

• Not an Asset, and not a discovered runtime.
• Not a Group target.
• Not created, overwritten, or deleted by Inventory discovery.

---

People

Where a Domain or Application names a person, the field is accountable_person: required name, surname, and email when the object is present; optional role. The Configuration label is Owner. Email correlates records. It is not a person-registry foreign key. There is no Person registry and no Team entity.

The Owner is optional on a Domain and on an Application. Do not invent a placeholder person. Accountability is not Legal Entity ownership.

New Configuration writes reject free-text accountable, including an empty string, and reject owner and ownerPerson. An existing non-empty accountable warns. The person, when one is stored, is accountable_person.

An Asset stores no person. Accountability for an Asset walks the Application’s accountable_person, otherwise the Domain’s. When belonging is a Platform, it walks that Platform’s accountable_person.

---

Groups on Business

Groups classify Domains and Applications the same way they classify Organization and Technology. A Group may hold direct values, container subgroups (each holding values), or both. Picks live on the entity as group_values, not in assignments. Do not add a second classification system on the Application.

---

Rules

New external fields, new 7lens-authored ids, and new closed-list values are snake_case. A new reference is *_id or *_ids. A token taken from an external standard stays verbatim. Published camelCase stays until a versioned migration:

Published name	Record
parentId	Domain
legalEntityId	Domain
domainId	Application
sourceApplicationId	Relationship
targetApplicationId	Relationship
repositoryAssetIds	Deployment, v1 read only

Id style uses the Groups slug rule: a lowercase letter, then lowercase letters, digits, or underscores (^[a-z][a-z0-9_]*$). The same rule is the Technology catalog-segment check. A miss is a warning. Domain and Application ids have no tighter schema than a non-empty unique string. Deployment ids keep the published grammar ^[a-z][a-z0-9\-_.]*$. YAML, backup restore, and the Configuration page share one Business validator for required fields, snake_case keys, slug warnings, known Domain and Legal Entity references, and acyclic Domain parents.

On a new Domain or Application, an empty description is an error. On an existing record the YAML check warns and does not block save. The Add and Edit dialog still requires a description before it saves. id, name, legalEntityId, and domainId are errors when missing. sourcing_model and delivery_model may be unset. A missing Owner is silent.

Configuration entities do not store created_at or updated_at. Authorship is the Configuration change log and backup.

---

Q&A

Q1. Is a CRM or an ERP an Application?

If the enterprise operates it and business users work in it, it is a Platform. The business processes built on it are Business Applications. The identity test is the order of the check.

Q2. How should an Application made of several parts be represented?

When the parts are independently identifiable business systems, each is an Application and part_of records composition. Technical elements are Assets, not Applications.

Q3. How should related Applications be grouped without composition?

Use a Domain for a business area. Use a Group for a cross-cutting classification. Neither implies part_of or depends_on.

Q4. Can part_of cross a Legal Entity?

No. Both Applications resolve to the same Legal Entity. They may use different Domains of that entity.

Q5. Can depends_on cross a Legal Entity?

Yes. Each Application keeps the ownership of its own Domain.

Q6. Where do environment and Entry Points belong?

On Deployments, once deployments is present. While the key is absent, the flat Application fields remain the authority. An empty list means zero Deployments, not “fall back to the flat fields.”

Q7. Does Inventory author consumes?

No. consumes[].service is the declared join. Assets may evidence it. The Application model does not require Inventory.

Q8. Is a Platform an Application?

No. A Platform is Technology. A business use of that Platform is an Application.

---

Examples

The people, the Service id, and the hyphenated Domain id are examples. A hyphen is pack data. It warns. It is not the shape to mint.

Domain and Application

domains:
  - id: retail_banking
    name: Retail banking
    description: Branch and digital retail for consumer customers.
    parentId: null
    legalEntityId: acme_es
    accountable_person:
      name: Ada
      surname: Lovelace
      email: ada@example.test
      role: Domain owner
applications:
  - id: claims
    name: Claims
    description: Logical system for claims processing.
    domainId: retail_banking
    audience: internal
    application_type: internal_application
    sourcing_model: in_house
    delivery_model: self_deployed
    consumes:
      - service: compute.virtual_machines
    accountable_person:
      name: Grace
      surname: Hopper
      email: grace@example.test

application_type: internal_application in this example is an explicit classification of that record. A parser default of the same value, with no author decision, is not sourcing_model: in_house.

Relationship

applicationRelationships:
  - sourceApplicationId: claims_assessment
    type: part_of
    targetApplicationId: claims
  - sourceApplicationId: claims
    type: depends_on
    targetApplicationId: fraud_detection

Deployment

deployments:
  - id: eu_production
    name: EU production
    environments: [pro]
    deployed_in:
      - tier: country
        id: es
    entry_points:
      - type: web_portal
        url: https://claims.example.com
        exposure: internal
        environment: pro

While deployments is absent, the same facts may still sit in the flat Application fields, with Entry Point type web rather than web_portal.

Invalid shapes

# Offering used as a consume target
consumes:
  - service: compute.virtual_machines/aws_ec2

# Free-text owner
owner: Ada Lovelace

# A second ownership field on the Application
legalEntityId: acme_es

# CamelCase field minted for this axis
businessOwner: Ada

---

Non-goals

This companion does not:

• Treat starter-pack fill-ins as rules.
• Treat a Platform, an ERP module, a library, or a Service as an Application.
• Make Offerings a target of consumes.
• Let Inventory author consumes or silently create Deployments.
• Infer sourcing_model or delivery_model from application_type, hosting, or deployed_in.
• Add integrates_with, interacts_with, or a second classification system beside Groups.
• Apply the ingest id pattern app.{unit}.{slug} to canonical Application ids.
• Treat the knowledge-base APPLICATIONS axis (parent, Unit, Company, Site) as this model.
• Invent Deployments from schema defaults, or rename web, mobile, and graphql on ordinary save.