CVR Semantic Organisation

CVR should be read in two layers:

1. Delivery layer: which entities are delivered by Datafordeler filedownload.
2. Semantic layer: which concepts those entities and attributes represent.

This avoids a common mistake: assuming each delivered entity is a standalone business concept.

Layer 1: Delivery Entities (Filedownload View)

CVR filedownload commonly exposes these entities:

• Adressering
• AndreDeltagere
• AnsvarligDataleverandoer
• Beskaeftigelse
• Branche
• CVREnhed
• CVRPerson (restricted access)
• e_mailadresse
• FuldtAnsvarligDeltagerRelation
• Kreditoplysninger
• Navn
• Produktionsenhed
• Reklamebeskyttelse
• Telefaxnummer
• Telefonnummer
• Virksomhed
• Virksomhedsform

These are delivery units, not final analysis objects.

Layer 2: Semantic Concepts (Interpretation View)

Use semantic concepts as the analysis entry point, then map to entities/attributes.

Semantic concept	Primary entities	Key attributes / signals
Legal business identity	CVREnhed, Virksomhed, Navn	CVREnhedsId, Navn, Virksomhedstatus
Organizational form	Virksomhedsform, Virksomhed	Virksomhedform, legal form rules
Industry activity	Branche	Branche, code/text values
Operational footprint	Produktionsenhed, Adressering	production site + address relation
Contactability	Telefonnummer, e_mailadresse, Telefaxnummer	contact channels
Governance and ownership	AndreDeltagere, FuldtAnsvarligDeltagerRelation (+ other ownership/leadership relation entities in GraphQL/object model)	decision power and ownership role signals
Financial and accounting context	Beskaeftigelse, Kreditoplysninger (+ Regnskab/Revision in broader model)	employment and financial status indicators
Social economy and supervision	SocialØkonomiskVirksomhed (object model), Virksomhedsform	SocialØkonomiskVirksomhed=true, IEFTilsyn, IEFTilsynTekst
Regulatory/privacy posture	Reklamebeskyttelse, AnsvarligDataleverandoer	outreach restrictions and data supply responsibility

Fast Routing from SPHERE Leaves

This table is the shortest route from user intent to execution plan.

Leaf	Primary entities	Supporting entities	Canonical join keys	Spatial path	Time-slice rule
|Firms	Virksomhed, CVREnhed, Navn, Virksomhedsform	CVRAdresse	CVREnhedsId, cvrnummer	legal address via CVRAdresse → DAR	filter on both registrering* and virkning*
|Economic Activities	Branche, Virksomhed, Produktionsenhed	Navn, CVRAdresse	CVREnhedsId, pnummer	CVRAdresse → DAR	filter on both registrering* and virkning*
|Business Locations	Produktionsenhed, Virksomhed, CVRAdresse	Navn, Branche	CVREnhedsId, pnummer, address tuple	CVRAdresse → Adresse → geometry	current snapshot usually enough unless historical site location is needed
|Ownership and Governance	Ejerforhold, Reelejerrelation, Legalejerrelation, Virksomhed	AndenDeltager, Ledelse, Kapitalforhold	CVREnhedsId, relation local ids	via owned or owning entity address if mapping is needed	apply time filter on each relation entity independently
|Economics and Employment	Regnskab, Beskæftigelse, Virksomhed	Revision, Revisorrelation, Stadfæstelse, Produktionsenhed	CVREnhedsId, accounting period	via reporting entity address only when spatial output is required	respect accounting period first, then bitemporal validity
|Services and Amenities	Produktionsenhed, Branche, CVRAdresse	Virksomhed, Navn	pnummer, CVREnhedsId, address tuple	Produktionsenhed → CVRAdresse → DAR	current snapshot usually used for service availability

Canonical Entity Roles

Entity	Role in analysis	Not to be confused with
Virksomhed	legal business anchor	Produktionsenhed operational site
Produktionsenhed	operational establishment	legal registration entity
CVRAdresse	structured address components	geometry-bearing address point
Branche	economic classification	company name or legal form
Ejerforhold	direct ownership relation	beneficial ownership
Reelejerrelation	beneficial ownership	legal ownership chain
Legalejerrelation	legal ownership chain	beneficial ownership
Regnskab	accounting-period financial report	quarterly or interval employment records
Beskæftigelse	employment measure over time	annual account statement

Critical Distinction: Firm vs Produktionsenhed

This distinction must be explicit in both human interpretation and AI workflows:

• Virksomhed (firm): the legal construction (juridical entity)
• Produktionsenhed: the active unit seen on the street (operational establishment)

Example:

• Coop as legal enterprise = Virksomhed
• each physical Coop shop = Produktionsenhed

Address implications

Both can have address records, but the semantic meaning differs:

• firm address can represent legal/administrative presence
• produktionsenhed address represents operational location of activity

Always decide which address type matches your research question before geocoding or density analysis.

Canonical Join Patterns

1. Business profile bundle

Virksomhed
    ├─ Navn
    ├─ Virksomhedsform
    ├─ Branche
    └─ CVRAdresse

2. Operations bundle

Produktionsenhed
    ├─ Navn
    ├─ Branche
    ├─ CVRAdresse
    ├─ Telefonnummer / e_mailadresse / Telefaxnummer
    └─ Beskæftigelse

3. Ownership bundle

Virksomhed
    ├─ Ejerforhold
    ├─ Reelejerrelation
    ├─ Legalejerrelation
    ├─ Kapitalforhold
    └─ AndenDeltager / Ledelse

4. Financial bundle

Virksomhed
    ├─ Regnskab
    ├─ Revision
    ├─ Revisorrelation
    ├─ Stadfæstelse
    └─ Beskæftigelse

Spatial Linkage Rule

CVR does not provide authoritative geometry for business entities. The canonical route to space is:

Virksomhed or Produktionsenhed
    -> CVRAdresse
    -> address normalization
    -> DAR address / house-number match
    -> point geometry

This is why the Business Locations leaf must remain the operational entry point for geocoding tasks.

Temporal Rule

• Use virkning* to answer “what was true at time t?”
• Use registrering* to answer “when was this recorded in the system?”
• For ownership and leadership, do not assume the parent Virksomhed time fields are sufficient; relation entities carry their own validity.

Important Example: Social Economic Enterprise

“Social economic enterprise” is not a top-level delivery package in your 17-entity list, but a semantic signal carried in object/attribute space.

Practical interpretation:

• treat SØV as a semantic classification built from multiple signals
• do not rely on one field in isolation unless your legal interpretation explicitly allows it
• include related supervisory context (IEFTilsyn, IEFTilsynTekst) when available

See SocialØkonomiskVirksomhed.

AI Guidance: Build Concept Bundles, Not Flat Tables

For AI workflows, build purpose-specific bundles:

1. Business profile bundle: CVREnhed + Virksomhed + Navn + Virksomhedsform + Branche
2. Operations bundle: Produktionsenhed + Adressering + contact entities
3. Governance/compliance bundle: participant/relation entities + Reklamebeskyttelse + relevant supervision signals

When both Virksomhed and Produktionsenhed are present, keep separate identifiers and separate address roles until the final analysis model is defined.

Then merge bundles by stable identifiers and temporal fields.

Minimum Execution Questions an Agent Should Answer Here

Before leaving this page, an agent should be able to answer:

1. Which entity is the legal anchor? Virksomhed
2. Which entity is the operational site? Produktionsenhed
3. How does CVR become spatial? CVRAdresse → normalized address → DAR geometry
4. Which entities answer ownership? Ejerforhold, Reelejerrelation, Legalejerrelation
5. Which entities answer financial state? Regnskab and Beskæftigelse

Codebook and Normalization Contract

For coding details that frequently break joins and filters (kommunekoder, DB07/DB25 transitions, BS/NACE hierarchy), use:

• CVR Codebook and Normalization Model
• cvr.codebook-resolution.policy.v1.json

Machine-readable companion

• cvr.semantic.entity-attribute-map.v1.json