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

Problem

An entrepreneur founds an organisation - and faces the question: How do I structure my organisation so that compliance obligations are cleanly separated, traceable and auditable?

Today's practice in the SME sector knows no clean separation:

• Everything in one pot - private and business documents mix in a single mailbox, a single drive, a single cloud account.
• No tenant separation - a holding with several companies keeps all books in one instance, without it being clear which record belongs to which company.
• No sphere separation - in non-profit organisations, ideal, asset-managing, purpose-operated and commercial activities mix in a single account, a single folder, a single repo.
• No role separation - the entrepreneur does everything themselves (MD, accountant, payroll, R&D), but the repo does not know in which role they are acting at any given moment.
• No clear identity - records have no unique identifier that assigns them to an organisation, a sphere, a role.

Core Statement

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

Compliance by Design: Tenant, Sphere and Role are not after-the-fact labels - they are structural mandatory fields, without which an artefact is not admitted to the repo.

The Three-Level Model: Tenant, Sphere, Role

Level 1 - Tenant (Organisation)

A Tenant is a legally independent organisational unit for which separate record-keeping obligations exist. In the GitCover federation, each tenant is maintained as its own Git repo (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 books of the subsidiaries remain separate.

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

The Sphere is only relevant for non-profit organisations - but then mandatory. Tax law (§ 51-68 AO) requires the separation of the four spheres in order not to jeopardise non-profit status.

Risk if sphere separation is missing: Asset mixing (§ 55 Abs. 1 Nr. 5 AO) is a ground for revocation of non-profit status. A non-profit organisation that does not separate commercial and ideal activities risks losing its non-profit status - and consequently re-taxation of reserves (up to 15 years retroactively).

Level 3 - Role (Function of the Actor)

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

Practical example: The entrepreneur E1 is simultaneously MD, accountant, researcher, developer and R&D lead. In the repo, every artefact documents in which role they 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 MD 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

JSON Artefact with Tenant, Sphere, Role

Every artefact (diary entry, document, ledger entry) contains Tenant, Sphere and Role as mandatory fields. Central core principle of temporal traceability: the recording time is not a separate field, but anchored in the uuidV7 itself - as a 48-bit timestamp according to RFC 9562 §5.7. The uuidV7 is generated from a predefined timestamp (not now()) via the GitCover helper (UuidV7Gen), the rest filled with randomness. This cryptographically links the recording time to the identity of the artefact and makes it non-modifiable after the fact.

Important - what lands in the Git repo: Only these structured artefacts (JSON entries, sidecars, documents) are admitted to the Git repo. Private documents are never admitted to the repo unless they have been explicitly introduced and classified as artefacts.

{
  "$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 kept in the facts - the 48-bit timestamp is already contained in the uuidV7. String representations for DTO/HTMX transfer are the harness's responsibility, not the facts layer.

Git Hooks check the Separation

Tenant Federation: Multiple Organisations

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 documents and entries of the subsidiaries without copying them.

Important: The meta-repo contains no bookings - only cross-references. The bookkeeping stays with each tenant. The meta-repo is an index layer, not an accounting layer.

Risk Leverage

Harness Requirements (Preview)

Derivable from ED02:

The full requirements list in Harness-Anforderungen.md.

Sources

• AO (§§ 51-68 - non-profit status, sphere separation, § 55 Abs. 1 Nr. 5 - asset mixing)
• EStG (§ 3 Nr. 26/26a - lump sums, sphere reference)
• GoBD (BMF letter, procedural documentation, tenant separation)
• AFJD/agents/ (anonymised) - SSoT concept with Tenant, Sphere, Role

Source Topology and CDN Reference Links

Note: This assignment 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.