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 cleanly separated, traceable, and represented in an audit-proof manner?

Current practice in the SME sector does not provide clean separation:

• Everything in one pot — private and business documents mix in one mailbox, one drive, one cloud account.
• No tenant separation — a holding with several companies keeps all books in one instance, without clarity about which record belongs to which company.
• No sphere separation — in nonprofit status, ideell, vermögensverwaltend, zweckbetrieblich, and wirtschaftlich transactions mix in one account, one folder, one repo.
• No role separation — the entrepreneur does everything himself (GF, accountant, payroll, R&D), but the repo does not know in which role he is currently acting.
• No clear identity — records have no unique identifier that assigns them to an organization, a sphere, a role.

Key Statement

Structuring an organization as a GitCover association means: Tenant (organization), sphere (activity area in nonprofit status), 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 subsequent labels — they are structural mandatory fields without which an artifact is not admitted into the repo.

The Three-Level Model: Tenant, Sphere, Role

Level 1 - Tenant (Organization)

A tenant is a legally independent organizational unit for which its own record-keeping obligations exist. In the GitCover association, 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 (activity area, only for nonprofit status)

The sphere is relevant only for nonprofit organizations — but then mandatory. Tax law (§ 51–68 AO) requires separation of the four spheres so as not to jeopardize nonprofit status.

Risk of missing sphere separation: Commingling of assets (§ 55 Abs. 1 Nr. 5 AO) is grounds for revocation of nonprofit status. A nonprofit organization that does not separate commercial and ideell transactions risks revocation of nonprofit status — and thus retroactive 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, accountant, researcher, developer, and R&D lead. In the repo, every artifact documents in which role he acted — e.g. role: "GF" for a resolution, role: "F&E-Leiter" for an FZul hourly record. This keeps it traceable whether a record originated from the GF perspective (administration) or the R&D perspective (research).

Role is not person: The role describes the function (and, in the case of declarations, the represented party), not the identity. The same person can act or sign a document in several roles; the technical execution identity (account, key) is again a separate level. The five levels person · function · represented party · execution identity · signature act are described in ED03.

Implementation in the Git Repo

Directory Structure

ORG-1/                          # Tenant: KMU
├── .gitcover/                  # GitCover-Konfiguration
│   ├── LEGAL_ENTITY.gc.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/                   # .gc.md Sidecars
├── checks/                     # Fristen-Check, Sphären-Check
└── {weitere bei Bedarf}/

JSON Artifact with Tenant, Sphere, Role

Every artifact (diary entry, document, 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 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 (gc-v7guid), with the rest filled with randomness. Thus the capture time is cryptographically linked to the artifact's identity and cannot be changed subsequently.

Important - What ends up in the Git repo: Only these structured artifacts (JSON entries, sidecars, documents) are admitted into the Git repo. Private documents are never admitted into the repo unless they have been explicitly introduced and classified as an artifact. Once it is in, it is in.

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

Explanation Composite Key: V7GUID (Class Identifier) classifies the document/the 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 level.

Git Hooks Check the Separation

Tenant Association: Multiple Organizations

A tenant association (holding with subsidiaries, consortium) is linked via V7GUID references — not via shared repos. Each tenant retains its own bookkeeping, but the holding's meta-repo can reference the subsidiaries' documents 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 level, not an accounting level.

Risk Leverage

Harness Requirement (Preview)

Derivable from ED02:

The complete requirements list in Harness-Anforderungen.md.

Sources

• AO (§§ 51–68 - nonprofit status, sphere separation, § 55 Abs. 1 Nr. 5 - commingling of assets)
• EStG (§ 3 Nr. 26/26a - flat-rate allowances, sphere reference)
• GoBD (BMF letter, procedural documentation, tenant separation)
• E1/agents/ (anonymized) - 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.