Status
Accepted on 2026-03-08 by Jan Ivar Beddari.
Context
Dataverket is building a sovereign open source datacenter automation system composed of multiple services for compute, Kubernetes, identity, app deployment, and object storage. Each service needs an authoritative name for use in documentation, CLIs, architecture, and later public-facing communication.
The parent organization already follows a Norwegian institutional naming style in the tradition of names such as “Vegvesenet” and “Jernbaneverket”. The service naming scheme needs to fit that overall identity rather than introducing a disconnected internal vocabulary.
Decision Drivers
- Each service needs one stable identifier that works across documentation, architecture, and tooling.
- The naming scheme should feel consistent with the parent Dataverket identity.
- Names should be memorable and suitable for both internal and external communication.
- The platform should avoid a split between internal service identifiers and a separate marketing name set.
Considered Options
Norwegian single-word service names aligned with Dataverket
Use Norwegian nouns that describe the service domain and can act as both internal and external service identities.
English service names
Use English names to align more directly with international engineering terminology.
Separate internal identifiers and external brand names
Use one set of implementation-facing names and another for documentation or outward-facing branding.
Decision
Each service gets a Norwegian service name: a single descriptive noun consistent with the parent organization. The service name also serves as the service’s brand identity in documentation, web presence, and other external-facing contexts.
The initial service names are:
| Service name | Purpose |
|---|---|
| Sentral | Control plane, orchestration, billing |
| Maskin | Compute — VMs and bare metal |
| Plattform | Kubernetes platform |
| Identitet | Identity and access management (Zitadel) |
| Tjeneste | Application/service deployment (SaaS layer) |
| Objekt | Object storage (S3-compatible) |
| Nett | Datacenter network automation and tenant network products |
The naming principles are:
- Service names are Norwegian, single-word, and descriptive of the service domain.
- The names should feel institutional and authoritative, consistent with the parent organization.
- Each service name doubles as branding. No separate brand layer is introduced.
Consequences
Positive
- The platform gets a coherent naming scheme that fits the Dataverket identity.
- Service names become stable identifiers across documentation, CLI tooling, branding, and architecture.
- Future services can follow a clear and repeatable naming pattern.
Negative
- English-speaking engineers may need a short learning curve before the names feel natural.
- Later renaming becomes more expensive because the names are intentionally reused across many surfaces.
Neutral
- These service names may later appear as subdomains under
dataverket.org, for examplemaskin.dataverket.org. Nettis the authoritative service identity corresponding to thedvnetCLI and thenettinternal subject or service segment.
Decision Outcome
Accepted. Dataverket will use Norwegian service names as the canonical service identities across the platform.
Related Decisions
- 002-cli-naming-and-structure.md defines how CLI names derive from these service identities.
Links
- No external links are required for this ADR.
More Information
- New services added later should follow the same naming heuristic: choose a Norwegian noun that clearly describes the service domain.
Audit
- 2026-03-08: ADR created and accepted.