Git-native Compliance: from concept to prototype

This experience report is anonymized (organization ORG-1, entrepreneur E1). It does not describe a finished solution, but a path: how an abstract guiding vision — “compliance that is anchored in .git itself” — became a verifiable prototype outline over a series of working sessions. The lesson from it is less technical than methodological.

Initial Situation

ORG-1 connects several legal entities: a non-profit entity, a development company, and the entrepreneur E1 himself as a sole proprietor. This constellation gives rise to three different compliance questions that are easily conflated:

Tax incentives (research allowance): Which hour belongs to which project?
Charitable status (§ 60a AO): In which sphere does an activity fall — ideal, purpose operation, asset management, or commercial business operation?
Proper accounting (GoBD/AO): Is every record traceable, immutable, complete?

In practice, these questions are often answered “by gut feeling” — and that is precisely where the risks arise that an audit later makes visible.

Conversation as a Design Tool

The special feature of this project: E1 works with a local, open-source AI agent as a counterpart. Not a code generator, but a dialogue partner that reads the existing company context (documents, conventions, decisions already made) and sharpens it in conversation.

The decisive effect was not speed, but consistency: every decision made was immediately checked against the existing architecture — “does this fit with what has already been normatively established, or are we unknowingly defining something twice?”

Lesson 1: An agent that only generates without checking the existing inventory creates redundancy. An agent that first finds and then suggests creates consistency.

The First Building Block: the Sphere Check as a Call-Back

It would have been obvious to build the sphere logic where it is needed — into every tool that records documents. That does not scale and distributes the same rule across many places.

Instead, an already existing pattern was found: a registry with action/call identifiers in the tenant-owned TOP/.gitcover directory. Every executable step carries a composite key made of two identifiers — “what it is” and “how it is executed”. A tool then does not need to know the concrete provider at all: it calls an identifier, and a resolution across levels (from the specific tenant to the general norm) finds the responsible handler.

Anfrage: "das ist ein gemeinnütziger Eintrag"
        │
        ▼
  Registry-Auflösung  (mandanten-spezifisch → normativ)
        │
        ├── gefunden  → Handler des Trägers (Sphärenprüfung § 60a)
        └── keiner    → bewusster No-Op (keine Prüfung nötig)

The principle is reminiscent of interface resolution in object-oriented programming: what is requested is a capability, not a concrete type. The side effect: non-charitable entities automatically get a clean “not applicable” — entirely without special cases in the code.

Lesson 2: A rule that applies everywhere belongs in one place with a stable interface — not copied into every tool.

The Second Building Block: Reproducible Compliance Artifacts

The second insight concerned the how of distribution. Regulatory knowledge — GoBD principles, GDPR principles, retention periods — today sits in manuals that nobody evaluates. The approach here: such knowledge becomes machine-readable, versioned artifacts in Git repositories.

Regulatorik  →  Katalog (maschinenlesbar)  →  Policies (ausführbar)
                                                     │
                                         Git-clone / Tool-Update
                                                     │
                                     prüfbares Ergebnis im Arbeitsverzeichnis

The model is not application CI/CD, but a “CI/CD for company facts”: the same update mechanism known from software tools here carries compliance knowledge — versioned, signable, verifiable.

What This Means in Practice

The record remains the record. The projections, weightings, and intentions behind an assignment do not belong in the published file — what stands there is the outcome, which must be demonstrable if in doubt.
Separation instead of labeling. An administrative activity does not become eligible for funding just because it is named in a research-related way. The auditing institution looks at the content, not the heading.
Private specifications remain private. The personal assessments, weightings, and balancing criteria of the approving person do not belong in the shared, versioned inventory — they are kept locally and not cited. Only from them do the decision documents emerge, which are then demonstrable. Agents observe such specifications but document only the result.
First find, then build. Before every new building block, the question is worth asking: Does this already exist — just under a different name?

Lesson 3: “From concept to prototype” does not mean building a lot of new things. It means taking the existing blueprint seriously and placing the next stone in the right spot.

What Is Signed Is Delimited in the Index

Another pattern concerns the signing itself. When a document is presented for signature (presented), only the original docs to be signed are staged (git add) — the Git index thus clearly shows what is to be signed, separated from the rest of the working state. A suitable commit text is prepared; committing is deliberately not done by the tool (gc-docsign present …). Only the signer signs the delimited commit (GPG). This keeps “presentation” and “signing” cleanly separated — and the record unadulterated.

Outlook

The outline is in place: a sphere check that dissolves itself where it is not needed; a rulebook that travels as an artifact through the same channels as code. Whether this becomes a productive tool for other small organizations is not decided by technology — but by the willingness to subject every assumption to a check before it becomes a habit.