7lens Data Model — Groups

This is a strategic source document: the Groups-axis definition model. It defines the three Config containers (Groups, Frameworks, Integrations), values, subgroups, ownership, and leaf addressing. Where this companion and Data model disagree on Groups structural detail or container placement, this companion wins.

Purpose

The 7lens Groups axis records cross-cutting classification and which external frameworks and tool integrations the enterprise intends to map. Configuration exposes that axis as three containers:

Groups — customer-defined strategic classification dimensions.
Frameworks — catalogue-backed standards, architecture models, and compliance regimes.
Integrations — catalogue-backed tool / platform taxonomies (not asset instance ids).

Groups organize and classify entities across Organization, Technology, and Business, and establish strategic ownership and access boundaries through the Owner of each selected value.

Groups are not part of the organizational hierarchy. They are an Ontology axis in their own right. Business Domains remain the business grouping mechanism; Groups are the cross-cutting classification mechanism (portfolio waves, business lines, architecture groupings, and similar).

Core naming rule: Values ≠ Subgroups. A value is an assignable option. A subgroup is a container that owns a list of values. Never use those labels interchangeably.

This document defines:

Three containers — Groups, Frameworks, Integrations: purpose and placement rules.
Definition semantics — Group tree, ownership, rules, and leaf addressing.
Product language — purpose, required-pick validation, inheritance/override, Groups vs Domains.

Product copy uses the terms Group, value, and subgroup as defined here. In Configuration UI, ownership fields are labelled Owner.

Three containers

Config order under the Groups axis: Groups → Frameworks → Integrations. All three belong to the same Ontology axis. They are not three separate axes, and they are not interchangeable lists of the same thing.

Container	What it holds	Wire home (starter packs / Backup)
Groups	Customer-defined classification dimensions with values and/or subgroups, Owners, and per-entity-type rules. Entities pick values via entity-side `group_values`.	`groups[]` entries that are not catalogue shells
Frameworks	Enabled standards / models / compliance regimes from the published catalogue (for example TOGAF, TBM, ISO 27001, GDPR, DORA). Selection records intent, not certification.	`frameworkSelections[]` rows on the Framework surface, plus matching `fw_*` Group shells
Integrations	Enabled tool / platform taxonomy entries from the published catalogue (for example ServiceNow CSDM). Taxonomy means the catalogue id for the product family / mapping target — not a concrete CMDB instance, tenant id, or Asset id.	`frameworkSelections[]` rows on the Integration surface, plus matching `int_*` Group shells

Catalogue shells use stable prefixes: Framework shells fw_<catalogue_id>, Integration shells int_<catalogue_id>. Ordinary custom Groups must not reuse those prefixes for unrelated classification. Author-created Framework or Integration shells that are not yet in the published catalogue still use the same prefixes and may later grow the same value / subgroup tree as ordinary Groups.

Framework and Integration enablement is global on the Groups axis. Technology and Business inherit that enablement; they do not redefine the catalogue selection per Service or Application.

DOs

Put customer strategic classification (business line, criticality, accountable function, modernization wave, and similar) under Groups.
Put published standards, architecture frameworks, and compliance regimes under Frameworks via catalogue selection.
Put published tool / platform mapping taxonomies under Integrations via catalogue selection.
Keep classification picks on the entity (group_values) for the entity’s type.
Keep OSM as the Technology catalog seed / open model path — not as a Framework selection.

DONTs

Do not invent a fourth container called “Technology Groups.” Technology Stack, Service, Offering, Platform, and ICT Provider remain Technology concepts. A custom Group must not stand in for the Technology hierarchy (for example a “Technology Stack Profile” Group that duplicates Stack membership).
Do not model Data Sensitivity, Environment, or Lifecycle as Groups. Data classification belongs on Asset attributes; environment belongs on Deployments (Assets inherit it); lifecycle commitments belong on Technology definitions.
Do not encode compliance or architecture catalogue entries as ordinary custom Groups (for example a Group named “Compliance Framework” whose values are gdpr / iso27001). Use Frameworks.
Do not encode tool platforms as ordinary custom Groups. Use Integrations.
Do not store Asset instance ids, Deployment ids, or tenant / instance identifiers as Integration values that pretend to be the catalogue taxonomy.
Do not place OSM under Frameworks. OSM is not a Framework selection on the Groups axis.
Do not use Groups to replace Business Domains or Organization hierarchy nodes.

Concepts

Group

Definition

A Group is one strategic classification dimension the enterprise defines once and applies globally.

Examples (not exhaustive): Business Division, Business Line, Modernization Wave, Regulatory Classification, Architecture Layer.

A Group has a stable identity independent of any single entity pick. It defines how the enterprise classifies; entity-side picks record which value an entity holds under that Group.

Identity and ownership

Every Group requires:

Attribute	Role
id	Stable identifier for the Group record. Slug form: lowercase letters, digits, underscores; must start with a letter (`^[a-z][a-z0-9_]*$`).
name	Human-readable label (for example “Business Line”).
key	Lowercase programmatic key for the dimension (same slug rule as `id`; for example `business_line`).
accountable_person	Structured Owner for the Group definition (see Ownership wire shape).

Optional descriptive text may accompany the Group. It does not change classification semantics.

Ownership rule: wire ownership is accountable_person only. Do not use free-text owner or accountable, and do not use a parallel ownerPerson key. Configuration UI labels this field Owner.

Group key uniqueness, and value/subgroup key uniqueness within a Group, are integrity rules. Keys do not replace stable ids. Keep both id and key on Group, value, and subgroup containers.

What a Group is not

Not a node in Organization → Region → … → Legal Entity.
Not a Business Domain (Domains group Applications structurally and map to Legal Entity).
Not a Technology Stack (Stacks organize Services).
Not itself an assignable leaf — entities are classified by selecting a value, not by “being” the Group.

Ownership wire shape

Every Owner on a Group, subgroup container, or value is an accountable_person object matching the API / OpenAPI person shape:

Field	Required	Meaning
name	yes	Given name.
surname	yes	Family name.
email	yes	Contact email.
role	no	Position or role title (optional).

UI label everywhere: Owner. Wire key everywhere for Groups (and Organization): accountable_person.

Tree structure

A Group may have:

direct values[] (assignable leaves), and/or
subgroups[] (containers), each with its own values[].

Both collections may be populated on the same Group. There is no XOR that forbids both collections together.

Group
 ├── values[]                    ← direct leaves (optional)
 │    └── Value (id, key, name, accountable_person, …)
 └── subgroups[]                 ← containers (optional)
      └── Subgroup (id, key, name, accountable_person, …)
           └── values[]          ← leaves under that subgroup
                └── Value (id, key, name, accountable_person, …)

Values versus subgroups

Concept	Meaning
Value	An assignable classification option. Entities pick values. Values carry ownership used for strategic ownership and access boundaries.
Subgroup	A container under a Group that owns its own value list. A subgroup is not itself the leaf an entity “is.”

Calling Renewable Energy a “subgroup” of Business Division is wrong when Renewable Energy is an option of that Group: it is a value. Calling Business Line’s Retail / Corporate “subgroups” is wrong when they are the Group’s direct options: they are values.

A subgroup is not a second independent Group in the global catalogue, and it is not a recursive arbitrary-depth tree. Depth is fixed: Group → (optional) Subgroup → Value.

Structural rules

A Group may publish direct values[], container subgroups[], or both.
Nesting is one level only: subgroup → values. No subgroup → subgroup. Values do not own subgroups.
Every subgroup that is published must own a non-empty values[] (a container with no leaves is incomplete).
Either or both of values[] / subgroups[] may be empty while the Group definition is still being built; an incomplete definition used as a required classification is a governance gap on the Group itself (see Inheritance, override, and required picks), not a hard structural XOR reject.
Keep product term value for every assignable leaf.

Invalid shapes (non-exhaustive):

Subgroup containing another subgroup.
Subgroup treated as a leaf assignable option with no values beneath it.
Values nesting further subgroups under them.
Leaf or container with free-text owner / accountable, or a non-canonical ownership key such as ownerPerson, instead of accountable_person.
entityType: provider in rules (provider dropped from Group applicability).

Value

Definition

A value is one allowed option of a Group (direct) or of a Subgroup (under a container).

Values are the only leaf classification options entities select. Ownership for access boundaries and strategic accountability attaches to the selected value.

Required attributes

Every value must have:

Attribute	Requirement
id	Stable identifier within its owning Group or Subgroup (slug rule as for Group).
key	Programmatic key within that same scope (same slug rule).
name	Human-readable label.
accountable_person	Structured Owner (`name`, `surname`, `email`; `role` optional). Required — not optional.

Optional description may accompany a value. It does not relax the attributes above.

Ownership and access

Groups establish role and access boundaries across 7lens through the Owner of each value. Selecting a value associates the entity with that value’s ownership for classification-driven access and accountability. Group-level accountable_person covers the dimension definition; value-level accountable_person covers the selected option. Subgroup-container accountable_person covers definition accountability for that partition only — it does not replace value ownership.

Subgroup

Definition

A Subgroup is a named container under a Group that owns its own list of values.

Subgroups exist to partition a Group’s options when a single flat value list is insufficient — for example when options are organized under intermediate headings that are not themselves the leaf classification.

Required structure

Each subgroup:

belongs to exactly one Group;
requires id, key, name, and accountable_person (same ownership shape as Group and value);
must own a values[] list (each value as in Value);
does not own further nested subgroups (one subgroup level only).

Rejected readings

The following are not the model:

Treating a subgroup as a flat list of options with no values underneath.
Treating subgroup as an optional second level hanging under each Group value.
Using “subgroup” as another name for value.
Requiring exclusive either/or (direct values XOR subgroups).

Classification picks

Definition-time addressing

The definition model addresses a selected leaf with a path-aware shape:

Where the value lives	What the pick must identify
Direct `Group.values[]`	`groupId` + `valueId`. No `subgroupId`.
Under a subgroup	`groupId` + `subgroupId` + `valueId`.

A pick that names a Group but selects no value is incomplete. On a new write a missing required pick is an error. On existing data it warns. It is not an implicit default.

Invalid picks:

subgroupId without valueId (subgroup is not a leaf).
valueId that does not belong to that Group’s direct values or to the named subgroup’s values.

Product home for picks — entity-side

Classification picks live on the entity for its entityType (for example: a required Group → each Application chooses a value), in group_values. There is no separate Groups assignments[] category as the product home for picks.

Starter-pack Groups YAML is definitions only: Group tree, rules, and optional framework selections — not a flood of assignment rows. Entity-side picks land with each entity axis (Organization, Technology, Business). Path-aware addressing (valueId ± subgroupId) is the definition contract for those picks.

Entity applicability

Groups apply to higher-level concepts across the Ontology. Product applicability for Group rules:

Organization, Region, Sub-region, Country, Legal Entity, Technology Stack, Service, Offering, Platform, Business Domain, Application.

provider is dropped from Group applicability. Do not include ICT Provider in Group rules or entity-type enums for Groups.

A Group declares which entity types it applies to through rules (Rules). A pick’s entity type must be one the Group’s rules allow.

Inheritance, override, and required picks

Picks can be inherited down a parent chain and explicitly overridden by a child when the Group’s rules allow inheritance and override for that entity type. A value inherited from a parent does not satisfy required. Inheritance does not invent a second Group or redefine allowed values.

A Group is validated whenever it applies. A missing required pick is an error on a new write and a warning on existing data. A missing optional pick is a warning. The record is not saved on a new write while a required pick is missing. Completeness and RBAC consumers must treat a missing required pick on existing data as visible unfinished classification, not as an implicit default value.

Groups versus Domains versus composition

A subgroup is not an optional second level under each Group value. Values and subgroups are not one concept. Direct values and subgroup containers are not exclusive. Classification picks are not stored in Groups assignments[].

Business Domains provide business grouping of Applications and map to a Legal Entity.
Groups provide cross-cutting classification across axes.
Application part_of and depends_on are structural and dependency relationships, not Group classifications.

Do not invent Application composition relationships to replace Groups. Do not use Groups to express Domain hierarchy or Legal Entity ownership.

Customer-defined classifications belong in Groups. Do not create a parallel classification system alongside Groups for cross-cutting tags. External standards and compliance enablement belong under Frameworks; tool / platform mapping taxonomies belong under Integrations. Do not encode those catalogue entries as ordinary Group values.

Rules

Each Group carries rules that state, per applicable entity type:

Rule dimension	Meaning
Applies	Whether this Group is in scope for that entity type.
Required	Whether a value is required when the Group applies. A missing required pick is an error on a new write and a warning on existing data. An inherited value does not satisfy `required` (see Inheritance, override, and required picks).
Cardinality	Whether the entity may hold one or many values of the Group.
Inheritance	Whether children inherit the ancestor’s pick.
Allow override	Whether a child may explicitly override an inherited pick.

Rules constrain picks; they do not change the tree shape of the Group. Coexistence of direct values and subgroups is independent of which entity types the Group targets.

Non-goals

This companion does not define or endorse:

Treating Groups as nodes in the Organization hierarchy (Region / Legal Entity tree).
Using Groups as a substitute for Business Domains or Application part_of / depends_on composition.
A “Technology Groups” container, or custom Groups that duplicate Technology Stack / Service / Offering / Platform membership.
Data Sensitivity, Environment, or Lifecycle as Groups (those facts live elsewhere in the model).
OSM as a Framework selection on the Groups axis.
Integrations as Asset instance ids, Deployment ids, or tenant / instance identifiers.
Collapsing values and subgroups into one concept.
Nested subgroup containers (subgroup → subgroup); nest depth is subgroup → values only.
Exclusive either/or (XOR) modes that forbid direct values and subgroup containers together.
Free-text owner / accountable, or non-canonical keys such as ownerPerson, as ownership (ownership is accountable_person only).
A Groups assignments[] category as the product home for classification picks. Picks are group_values on the classified entity.
provider / ICT Provider as a Group applicability target.

Boundary detail remains under Concepts and Three containers (what a Group is not; DOs / DONTs; rejected readings).

Q&A

Q1. Is a Group’s option a value or a subgroup?

If it is what an entity selects as its classification leaf, it is a value. If it is a heading/container that owns those leaves, it is a subgroup. Never both for the same object.

Q2. Can a Group have both a flat value list and subgroups?

Yes. Direct values and subgroup containers may coexist. There is no XOR.

Q3. If we use subgroups, where do the options live?

On each subgroup’s own values list. A published subgroup without values is incomplete.

Q4. Does every value need `accountable_person`?

Yes. Also required on the Group and on subgroup containers. Free-text owner / accountable and ownerPerson are not part of the model. UI label: Owner.

Q5. How does an entity pick a value when subgroups exist?

Path-aware: identify the Group, the subgroup (when under a container), and the valueId. Direct leaves omit subgroupId.

Q6. What happens if a required Group has no value on an entity?

On a new write, the record is not saved. On existing data, the missing value warns. An inherited value does not satisfy required.

Q7. Does this replace Business Domains?

No. Domains remain the Business hierarchy. Groups are cross-cutting classification.

Q8. Where do classification picks live in the product?

On the entity for its entityType, as group_values, on Organization, Technology, and Business records. Groups definitions ship the tree only (no assignments[]). This document defines the Groups definition tree and the path-aware leaf address.

Q9. Is `provider` a Group target?

No. Provider is dropped from Group applicability.

Q10. What is the Owner person shape on the wire?

accountable_person: required name, surname, email; optional role (position). Matches the shared API / OpenAPI person schema.

Q11. Are Frameworks and Integrations the same as Groups?

No. Groups are customer classification dimensions with assignable values. Frameworks and Integrations are catalogue enablement surfaces on the same axis: they record which external standards / tool taxonomies apply. They share Backup YAML under the Groups package (frameworkSelections plus fw_* / int_* shells) but must not be authored as ordinary custom Group value lists for catalogue ids.

Q12. Can OSM appear under Frameworks?

No. OSM seeds and shapes the Technology catalog. It is never a Framework selection on the Groups axis.

Examples

The following are illustrative YAML for the definition model.

Group with direct values only

groups:
  - id: business_line
    name: Business Line
    key: business_line
    accountable_person:
      name: Ana
      surname: Ruiz
      email: ana.ruiz@example.com
      role: Group Strategy Office
    values:
      - id: bl_infra
        name: Infrastructure
        key: infrastructure
        accountable_person:
          name: Carlos
          surname: Vega
          email: carlos.vega@example.com
          role: Domain Lead — Infrastructure
      - id: bl_energy
        name: Energy
        key: energy
        accountable_person:
          name: Lucia
          surname: Soto
          email: lucia.soto@example.com
          role: Domain Lead — Energy
    subgroups: []
    rules:
      - entityType: application
        required: true
        inheritance: true
        allowOverride: true
        cardinality: one

Pick (entity selects a leaf): { groupId: business_line, valueId: bl_energy } — no subgroupId.

Group with subgroups only (each subgroup owns values)

groups:
  - id: modernization_wave
    name: Modernization Wave
    key: modernization_wave
    accountable_person:
      name: Ana
      surname: Ruiz
      email: ana.ruiz@example.com
    values: []
    subgroups:
      - id: wave_region_eu
        name: EU Waves
        key: eu_waves
        accountable_person:
          name: Ana
          surname: Ruiz
          email: ana.ruiz@example.com
        values:
          - id: wave_2025
            name: Wave 2025
            key: wave_2025
            accountable_person:
              name: Miguel
              surname: Ortega
              email: miguel.ortega@example.com
          - id: wave_2026
            name: Wave 2026
            key: wave_2026
            accountable_person:
              name: Miguel
              surname: Ortega
              email: miguel.ortega@example.com
      - id: wave_region_latam
        name: LATAM Waves
        key: latam_waves
        accountable_person:
          name: Ana
          surname: Ruiz
          email: ana.ruiz@example.com
        values:
          - id: wave_latam_1
            name: LATAM Wave 1
            key: latam_1
            accountable_person:
              name: Sofia
              surname: Mendez
              email: sofia.mendez@example.com
    rules: []

Pick: { groupId: modernization_wave, subgroupId: wave_region_eu, valueId: wave_2026 }.

Group with both direct values and subgroups

groups:
  - id: regulatory_class
    name: Regulatory Classification
    key: regulatory_class
    accountable_person:
      name: Ana
      surname: Ruiz
      email: ana.ruiz@example.com
    values:
      - id: reg_none
        name: Not regulated
        key: not_regulated
        accountable_person:
          name: Ana
          surname: Ruiz
          email: ana.ruiz@example.com
    subgroups:
      - id: reg_eu
        name: EU regimes
        key: eu_regimes
        accountable_person:
          name: Ana
          surname: Ruiz
          email: ana.ruiz@example.com
        values:
          - id: reg_nis2
            name: NIS2
            key: nis2
            accountable_person:
              name: Elena
              surname: Cruz
              email: elena.cruz@example.com
          - id: reg_dora
            name: DORA
            key: dora
            accountable_person:
              name: Elena
              surname: Cruz
              email: elena.cruz@example.com
    rules:
      - entityType: application
        required: false
        inheritance: true
        allowOverride: true
        cardinality: many

Pick direct leaf: { groupId: regulatory_class, valueId: reg_none }
Pick under subgroup: { groupId: regulatory_class, subgroupId: reg_eu, valueId: reg_dora }

Invalid shapes (must reject)

# Subgroup under subgroup — forbidden
subgroups:
  - id: outer
    name: Outer
    key: outer
    accountable_person: { name: A, surname: B, email: a@example.com }
    subgroups: # ← invalid nesting
      - id: inner
        ...

# Subgroup with no values — incomplete / invalid when published
subgroups:
  - id: sg1
    name: Empty
    key: empty
    accountable_person: { name: A, surname: B, email: a@example.com }
    values: []

# Free-text owner instead of accountable_person — invalid
values:
  - id: v1
    name: Leaf
    key: leaf
    owner: 'Ada Owner'

# Non-canonical ownership key — invalid (use accountable_person)
values:
  - id: v1
    name: Leaf
    key: leaf
    ownerPerson:
      name: Ada
      surname: Owner
      email: ada@example.com

# provider in rules — dropped
rules:
  - entityType: provider
    required: true

# Pick subgroup without valueId — invalid (subgroup is not a leaf)
{ groupId: modernization_wave, subgroupId: wave_region_eu }

Model summary

This version (1.2) defines:

The Groups axis has three Config containers: Groups, Frameworks, Integrations.
A Group is a customer-defined global strategic classification dimension, not part of Organization hierarchy.
Frameworks enable catalogue standards / compliance; Integrations enable catalogue tool taxonomies (not Asset instance ids). OSM is never under Frameworks.
Data Sensitivity, Environment, and Lifecycle are not Groups; Technology hierarchy membership is not a Group.
Identity: id + key + name on Group, value, and subgroup containers (slug-valid id/key).
Ownership: accountable_person only on Group, subgroup containers, and values — UI label Owner; person shape name, surname, email, optional role; no free-text owner / accountable and no ownerPerson.
Tree: a Group may have direct values, container subgroups (each with values[]), or both — no XOR.
Values ≠ subgroups. Values are assignable leaves; subgroups are containers.
Nesting: one level only — subgroup → values; no subgroup → subgroup.
Leaf product term: value.
Path-aware leaf address: valueId; subgroupId only under a container.
Picks live on the classified entity as group_values. Groups definitions omit assignments[].
Rules: applicability, required, cardinality, inheritance, override per entity type; no provider.
A missing required pick is an error on a new write and a warning on existing data. An inherited value does not satisfy required.

7lens Data Model — Groups

Purpose

Three containers

DOs

DONTs

Concepts

Group

Definition

Identity and ownership

What a Group is not

Ownership wire shape

Tree structure

Values versus subgroups

Structural rules

Value

Definition

Required attributes

Ownership and access

Subgroup

Definition

Required structure

Rejected readings

Classification picks

Definition-time addressing

Product home for picks — entity-side

Entity applicability

Inheritance, override, and required picks

Groups versus Domains versus composition

Rules

Non-goals

Q&A

Q1. Is a Group’s option a value or a subgroup?

Q2. Can a Group have both a flat value list and subgroups?

Q3. If we use subgroups, where do the options live?

Q4. Does every value need accountable_person?

Q5. How does an entity pick a value when subgroups exist?

Q6. What happens if a required Group has no value on an entity?

Q7. Does this replace Business Domains?

Q8. Where do classification picks live in the product?

Q9. Is provider a Group target?

Q10. What is the Owner person shape on the wire?

Q11. Are Frameworks and Integrations the same as Groups?

Q12. Can OSM appear under Frameworks?

Examples

Group with direct values only

Group with subgroups only (each subgroup owns values)

Group with both direct values and subgroups

Invalid shapes (must reject)

Model summary

Q4. Does every value need `accountable_person`?

Q9. Is `provider` a Group target?