ED02 - The SME Organization 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 represented in a cleanly separated, traceable, and audit-proof way?

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

• Everything in one pot - private and business documents get mixed in one mailbox, one drive, one cloud account.
• No tenant separation - a holding with multiple companies keeps all books in a single instance, without it being clear which record belongs to which company.
• No sphere separation - for non-profits, ideell, vermögensverwaltend, zweckbetrieblich and wirtschaftlich transactions get mixed in one account, one folder, one repo.
• No role separation - the entrepreneur does everything himself (GF, bookkeeper, payroll, R&D), but the repo doesn't know in which role he is currently acting.
• No clear identity - records have no unambiguous identifier that assigns them to an organization, a sphere, a role.

Core Message

Structuring an organization as a GitCover federation means: Tenant (organization), Sphere (area of activity in the non-profit case) and Role (function of the actor) are defined as mandatory fields of every artifact - not as optional metadata. Git hooks check with every commit that the separation is complete. This results in 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 after-the-fact 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 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 revocation of non-profit status. A non-profit organization that does not separate wirtschaftlich and ideell transactions risks revocation of its non-profit status - and thus subsequent 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. 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 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: SME
├── .gitcover/                  # GitCover configuration
│   ├── LEGAL_ENTITY.v7g.json   # Tenant identity (V7GUID)
│   ├── dictionaries/           # Spheres, roles, document types
│   └── schemas/                # JSON schemas for artifacts
├── diary/                      # Diary (SSoT)
│   ├── entries/                # Daily entries
│   └── tenants/                # Tenant views (symlinks)
├── registry/                   # Authority identifiers
├── sources/                    # Document archive (PDF, XML, EML)
├── sidecars/                   # .v7g.md sidecars
├── checks/                     # Deadline check, sphere check
└── {more as needed}/

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 is anchored in the uuidV7 itself - as a 48-bit timestamp according to RFC 9562 §5.7. The uuidV7 can be generated from a predetermined timestamp (not only now()) via GitCover Helper (UuidV7Gen), with the remainder filled with randomness. This way, the capture time is cryptographically linked to the identity of the artifact and cannot be changed retroactively.

Important - What ends up in the Git repo: Only these structured artifacts (JSON entries, sidecars, documents) 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 predetermined timestamp (RFC 9562 §5.7, 48-bit Unix-ms). Together, both form the GCPN Sidecar Composite Key V7GUID:uuidV7. A separate datetime or date string representation is redundant and is not maintained 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 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 documents and entries of the subsidiaries 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 a bookkeeping layer.

Risk Leverage

Harness Requirement (Preview)

Derivable from ED02:

The complete list of requirements 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 - lump sums, 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 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.