ED02 - The SME Organizational Model: Tenants, Spheres, Roles

Problem

An entrepreneur founds an organization - and faces the question: How do I structure my organization so that compliance obligations are mapped in a cleanly separated, traceable, and audit-proof manner?

Current practice in the SME sector knows no clean separation:

• Everything in one pot - private and business documents get mixed together in one mailbox, one drive, one cloud account.
• No tenant separation - a holding with several companies keeps all books in a single instance, without any clarity as to which record belongs to which company.
• No sphere separation - with non-profit status, ideal, asset-managing, purpose-related, and commercial transactions get mixed together in one account, one folder, one repo.
• No role separation - the entrepreneur does everything themselves (managing director, bookkeeper, payroll, R&D), but the repo does not know in which role they are currently acting.
• No clear identity - records have no unambiguous identifier that assigns them to an organization, a sphere, a role.

Key Message

Structuring an organization as a GitCover federation means: Tenant (organization), Sphere (area of activity for non-profits) and Role (function of the actor) are defined as mandatory fields of every artifact - not as optional metadata. Git hooks check on every commit that the separation is complete. This creates Compliance by Design: The structure of the organization is anchored in the structure of the repo.

Compliance by Design: Tenant, sphere, and role are not labels added afterwards - they are structural mandatory fields without which an artifact is not accepted into the repo.

The Three-Level Model: Tenant, Sphere, Role

Level 1 - Tenant (Organization)

A Tenant is a legally independent organizational unit for which separate record-keeping obligations exist. In the GitCover federation, each tenant is maintained as its own Organization (Git User) with associated Git repos (or its own branch namespace).

Practical example: An entrepreneur (E1) runs a holding (ORG-1) with two subsidiaries (ORG-1a, ORG-1b). Each subsidiary is its own tenant with its own repo. The holding has a meta-repo that links the subsidiaries via V7GUID references - but the subsidiaries' books remain separate.

Level 2 - Sphere (Area of Activity, only for Non-Profits)

The Sphere is only relevant for non-profit organizations - but then it is mandatory. Tax law (§ 51–68 AO) requires the separation of the four spheres so as not to jeopardize non-profit status.

Risk of missing sphere separation: Commingling of assets (§ 55 Abs. 1 Nr. 5 AO) is a ground for revoking non-profit status. A non-profit organization that does not separate commercial and ideal transactions risks revocation of its non-profit status - and with it retrospective taxation of reserves (up to 15(!) years retroactively).

Level 3 - Role (Function of the Actor)

The Role documents in which function an actor acted. This is important because in many organizations one person often holds several roles (especially in SMEs) - and because the role determines which obligations apply.

Practical example: The entrepreneur E1 is simultaneously GF, bookkeeper, researcher, developer, and head of R&D. For every artifact, the repo documents in which role he acted - e.g., role: "GF" for a resolution, role: "F&E-Leiter" for an FZul hour record. This keeps it traceable whether a record originated from the GF perspective (administration) or the R&D perspective (research).

Implementation in the Git Repo

Directory Structure

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.v7g.json   # Tenant-Identität (V7GUID)
│   ├── dictionaries/           # Sphären, Rollen, Beleg-Typen
│   └── schemas/                # JSON-Schemata für Artefakte
├── diary/                      # Tagebuch (SSoT)
│   ├── entries/                # Tages-Einträge
│   └── tenants/                # Tenant-Sichten (Symlinks)
├── registry/                   # Behörden-Identifikatoren
├── sources/                    # Belegarchiv (PDF, XML, EML)
├── sidecars/                   # .v7g.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

JSON Artifact with Tenant, Sphere, Role

Every artifact (diary entry, voucher, land register entry) contains tenant, sphere, and role as mandatory fields. Central core principle of temporal traceability: The capture time is not a separate field but is anchored in the uuidV7 itself - as a 48-bit timestamp according to RFC 9562 §5.7. The uuidV7 can be generated from a predefined timestamp (not only now()) via the GitCover helper (UuidV7Gen), with the remainder filled with randomness. As a result, the capture time is cryptographically linked to the identity of the artifact and cannot be changed afterwards.

Important - What ends up in the Git repo: Only these structured artifacts (JSON entries, sidecars, vouchers) are added to the Git repo. Private documents are never added to the repo unless they have been explicitly introduced and classified as artifacts. Once it's in, it's in.

{
  "$schema": "https://gitcover.org/schemas/diary-entry-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "GF",
  "tenant": "ORG-1",
  "sphere": "ideell",
  "source": "E1",
  "source_sha256": "<SHA-256-...>",
  "tags": ["lohnabrechnung", "sv-meldung"]
}

Composite key explanation: V7GUID (Class Identifier) classifies the document/action based on the .gitcover registry (what/which type). uuidV7 (Object ID) is the concrete object identifier with the predefined timestamp (RFC 9562 §5.7, 48-bit Unix-ms). Together they form the GCPN Sidecar Composite Key V7GUID:uuidV7. A separate datetime or date string representation is redundant and is not maintained at the facts level - the 48-bit timestamp is already embedded in the uuidV7. String representations for DTO/HTMX transfer are the harness's responsibility, not the facts level.

Git Hooks Check the Separation

Tenant Federation: Multiple Organizations

A tenant federation (holding with subsidiaries, consortium) is linked via V7GUID references - not via shared repos. Each tenant keeps its own bookkeeping, but the holding's meta-repo can reference the subsidiaries' vouchers and entries without copying them.

Important: The meta-repo contains no postings - only cross-references. Bookkeeping remains with each tenant. The meta-repo is an index layer, not an accounting layer.

Risk Leverage

Harness Requirements (Preview)

Derivable from ED02:

The complete list of requirements can be found in Harness-Anforderungen.md.

Sources

• AO (§§ 51–68 - non-profit status, sphere separation, § 55 Abs. 1 Nr. 5 - commingling of assets)
• EStG (§ 3 Nr. 26/26a - flat-rate exemptions, sphere relevance)
• GoBD (BMF letters, process documentation, tenant separation)
• AFJD/agents/ (anonymized) - SSoT concept with tenant, sphere, role

Source Topology and CDN Reference Links

Note: This mapping of sources, mirror, and community hub reflects the current state and may change. Please check the respective canonical source on gitcover.org for the current state.