ai-agent open-knowledge-format bigquery agent-development-kit gemini agents

Was ein Schema Ihrem Agenten nicht mitteilen kann: Das Open Knowledge Format in BigQuery

Ein Experiment mit BigQuery und Gemini ADK: Open Knowledge Format-Pakete in Git gaben einem Agenten das, was das Schema nicht bieten konnte, stabilisierten die Antworten und behebten einen 29%igen GMV-Fehler.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202613 Min. Lesezeit2961 Wörter

Quellen: **What Your Schema Cannot Tell Your Agent, Open Knowledge Format Can**

Die Prompt-Datei, der niemand gehört

Wenn ein KI-Agent mit einem Datenlager verbunden wird, taucht früher oder später ein vertrautes Dokument auf. Anfangs handelt es sich um drei oder vier ordentliche Zeilen im Systemprompt: Rückerstattungen aus den Einnahmen ausschließen, das Geschäftsjahr beginnt im April, interne Testkonten ignorieren. Im Laufe der Monate wächst die Datei auf etwa vierhundert Zeilen an. Ein einzelner Ingenieur wagt es, sie zu bearbeiten, während der Analyst, der eigentlich für die Definitionen der Metriken verantwortlich ist, sie noch nie gesehen hat.

Die enorme Größe ist das geringere Problem. Schlimmer ist, dass niemand die Datei warten kann. Ein Prompt-String hat keinen benannten Eigentümer, kein Überprüfungsverfahren und kein Ablaufdatum. Wenn die Finanzabteilung im Januar eine neue Einnahmenpolitik veröffentlicht, erfährt der Ingenieur davon nie, der Analyst hat keine Möglichkeit, den Code zu ändern, und der Prompt läuft auch nicht von selbst ab.

Unter solchen Reibungsverhältnissen veraltet das Wissen oder wird nie vollständig erstellt, wodurch der Agent mit unvollständigen Definitionen und unausgesprochenen Annahmen arbeiten muss. Lücken führen nicht dazu, dass der Agent sichtbar versagt – es gibt keinen Absturz, keinen SQL-Syntaxfehler und auch keine leeren Ergebnisse. Der Agent prüft das Rohschema, schätzt die fehlenden Geschäftsregeln ab und liefert eine ordentliche, glaubwürdige Darstellung, die schließlich auf dem Dashboard für Führungskräfte erscheint. Ein störender Wartungsaufwand verwandelt sich so leise in ein Problem der Genauigkeit.

Das Open Knowledge Format (OKF) zielt genau auf diese Lücke ab. Geschäftsregeln befinden sich nicht mehr in Prompt-Strings oder undurchsichtigen Vektordatenspeichern, sondern als einfache Markdown-Dateien mit YAML-Frontmatter, die in Git gespeichert werden. Die Zugehörigkeit wird klar definiert, Änderungen erfolgen über Pull Requests, und Ablaufdaten sind sowohl für Analysten als auch für Ingenieure sichtbar.

Skeptiker argumentieren, dass stärkere Modelle und größere Kontextfenster dies überflüssig machen, da dem Agenten das Rohschema sowie die Dokumente direkt übergeben werden können, damit er die Definitionen selbst ableiten kann. Ein kompaktes Experiment prüfte, wie hoch der Preis für unvollständiges Wissen ist und welche Veränderungen durch eine OKF-Begründung entstehen. Dabei wurden zwei BigQuery-Tabellen, eine einzige Geschäftsfrage sowie ein mit Google’s Agent Development Kit (ADK) erstellter Agent unter verschiedenen Wissensszenarien verwendet.

Das Testszenario

Der Kontext ist ein Online-Marktplatz mit einer orders-Tabelle und einer payments-Tabelle, sowie eine Frage, die ein Produktmanager an jedem Montagmorgen stellen könnte.

Wie hoch war der GMV der erfolgreich abgewickelten QRIS-Zahlungen in Jabodetabek im Juli 2026?

Drei Begriffe benötigen eine Erklärung. GMV steht für Gross Merchandise Value, also die Summe der im jeweiligen Zeitraum verkauften Waren. QRIS ist der nationale QR-Zahlungsstandard in Indonesien. Jabodetabek bezeichnet die Metropolregion Jakarta: Jakarta, Bogor, Depok, Tangerang und Bekasi.

Jede Spalte, die für die Frage benötigt wird, existiert im Lager, doch das Schema kann diese Frage nicht beantworten. In der Frage sind vier Entscheidungen verborgen, und jede davon wurde von einer Person getroffen:

Der Status, der beweist, dass das Geld eingegangen ist. Zahlungen enthalten sowohl status_code als auch transaction_status. Der gängige Wert status_code = 200 besagt lediglich, dass der Aufruf an das Zahlungsgateway erfolgreich war – auch bei Stornierungen. Die Mittel erreichen das Händlerkonto erst dann, wenn transaction_status = 'settlement' gilt. Die vorgegebenen Werte basieren auf der öffentlichen API eines echten Zahlungsgateways.
Die relevanten Bestellungen. Eine abgeschlossene Zahlung, die mit einer zurückgesandten Bestellung verbunden ist, stellt eigentlich Geld zurück, wird aber weiterhin als settlement angezeigt, bis die Rückerstattung bearbeitet wurde. Daher benötigt der Filter orders.order_status = 'completed', wobei das Schema dies nicht erwähnt.
Das Zeitstempel, das den Zeitraum festlegt. Die Abwicklung verzögert sich um Stunden oder sogar Tage. Wenn man Juli nach orders.order_ts aufteilt, erhält man einen Gesamtwert, während eine Aufteilung nach payments.settlement_ts einen anderen Wert ergibt – daher kann eine Bestellung vom 31. Juli in den August fallen.
Die Städte, aus denen die Region besteht. Es gibt keine region-Spalte. Jabodetabek muss als dreizehn exakte destination_city-Werte angegeben werden, und Kota versus Kab. bezeichnen zwei unterschiedliche Orte und keine Variantenschreibweisen.

Ein Fehler bei einem dieser Punkte führt dennoch zu einer ausgeführten Abfrage. Es gibt keinen Fehler, kein leeres Ergebnis und keinen Stack-Trace – nur eine ordnungsgemäß formatierte Zahl, die an das Board-System weitergeleitet wird.

Kontext versus Wissen

Die offensichtliche Lösung besteht darin, die vier Entscheidungen aufzuschreiben und sie zusammen mit dem Schema dem Modell zur Verfügung zu stellen. Ein leistungsstarkes Modell kann oft auf dieser Grundlage zur richtigen Antwort gelangen. Doch es tut dies erneut in der nächsten Sitzung, und es gibt nichts, was zwei Sitzungen zwingt, übereinzustimmen. Die Definition von GMV wird nirgends gespeichert. Sie wird auf Anfrage von einem Prozess neu berechnet, der sich nicht an die Schlussfolgerungen vom Vortag erinnert.

Dieser Unterschied bestimmt den weiteren Verlauf der Argumentation. Der Kontext ist das Material, über das das Modell nachdenkt. Wissen hingegen ist eine bereits erreichte und genehmigte Schlussfolgerung. Das Nachdenken muss in jeder Sitzung erneut bezahlt werden, während eine schriftliche Schlussfolgerung nur einmal bezahlt werden muss.

Wo wurde es denn geschrieben? Nicht in der Eingabestring, aus den oben genannten Gründen. Eine Datenbank oder ein Vektorlagerraum bietet Speicherplatz, erledigt aber die Überprüfung, da ein Analyst keinen Pull Request gegen einen Embedding-Lagerraum erstellen wird.

Was OKF ist

Googles Vorschlag ist OKF, und er ist absichtlich einfach gehalten. Ein Bundle ist lediglich ein Ordner mit Markdown-Dateien, die YAML-Frontmatter enthalten, und wird über Git geteilt – ohne Beteiligung von Datenbanken, Vektorlagerräumen oder SDKs. Jede Datei beschreibt ein Konzept, type ist der einzige obligatorische Frontmatter-Schlüssel, und gewöhnliche Markdown-Links verbinden die Dateien miteinander, wodurch aus dem Bundle ein Graph statt einer Ansammlung entsteht.

Die wichtigere Frage ist, was darin enthalten ist. Typen werden nicht zentral registriert, und die Nutzer müssen solche Typen akzeptieren, die sie nicht erkennen – daher handelt es sich bei dem Folgenden um ein Ausgangswortschatz und nicht um ein Schema. In den beiden veröffentlichten Beispielpaketen von Google sehen die Verzeichnisse wie folgt aus:

tables/ und datasets/ geben an, um welche Daten es geht: Was eine Zeile darstellt, wie Spalten miteinander verbunden sind und welche Enum-Werte vorhanden sind. Dieser Teil kann aus dem Datenlager abgeleitet werden, wie im nächsten Schritt gezeigt wird.
metrics/ erklärt, was eine Zahl bedeutet. GMV sowie seine vier Bedingungen werden hier aufgeführt.
references/ enthält fachliches Wissen, das nirgendwo in Form von Spalten vorliegt – beispielsweise die dreizehn Städte von Jabodetabek, eine Produkttaxonomie oder die Liste der internen Testkonten.

policies/ speichert das Dokument, auf das sich eine Definition bezieht – beispielsweise die Einnahmerkennungsregeln, die Finance jeden Januar erneut veröffentlicht.

computations/ und attesters/ bewahren die genehmigten SQL-Abfragen für eine Metrik sowie Code auf, der überprüft, ob das Ergebnis tatsächlich daraus stammt.

skills/ enthält Verfahren: Wann etwas verwendet werden soll, seine Voraussetzungen und die einzelnen Schritte.

Ein guter Test dafür, ob etwas in einen Bundle gehört: Würde es einem neuen Analysten in seiner ersten Woche erklärt werden? Wenn ja, kommt es in eine Datei.

Die Version v0.2 der Spezifikation fügt drei Frontmatter-Felder hinzu, die das Problem direkt angehen. sources listet auf, aus was ein Konzept abgeleitet wurde. verified sammelt Bestätigungsereignisse in der Form von {by, at}; ein Konzept ohne solche Ereignisse wird explizit als unverified gekennzeichnet. stale_after gibt den absoluten Zeitpunkt an, ab dem ein Konzept als veraltet gilt. Zusammen bieten sie einen Verantwortlichen, eine Überprüfungsstufe sowie einen Ablaufzeitpunkt – alles in einer Datei, die von Analysten bearbeitet und von Überprüfern als Pull Request gelesen werden kann.

Könnte ein Team einfach seine eigene Ordnerstruktur erfinden? Das wäre möglich, doch ein gemeinsames Vokabular ermöglicht Dinge, die eine private Struktur nicht kann. Der unten beschriebene Referenzagent kann bereits die Hälfte eines Pakets erstellen, weil er bereits versteht, was das Konzept einer BigQuery Table ist. Die Prüfer wissen, wozu die Freigabe mit verified sie verpflichtet. Zudem ist das Format an keinen Anbieter gebunden – es ist an keinen Agenten, kein Framework und keinen Modellanbieter gekoppelt – sodass Wissen, das heute erstellt wird, auch bei einem Wechsel der Technologiebasis erhalten bleibt.

Viele Leser werden denken, dass es sich um eine Agentenfähigkeit mit zusätzlichen Schritten handelt, und die Überschneidung ist tatsächlich groß genug, um behandelt zu werden. OKF verwendet type: Skill lediglich als einen Konzepttyp. In Googles Beispielpaket ist skills/run-on-bq.md in den Abschnitten „Wann anwenden“, „Voraussetzungen“ und „Schritte“ strukturiert, was einer gewöhnlichen Agentenfähigkeit ähnelt. Fähigkeiten sind ein Teilmenge von OKF und kein Synonym dafür. Eine Fähigkeit weist einen Agenten an, wie er handeln soll, während OKF erklärt, was die Begriffe bedeuten, wer sie zuletzt überprüft hat und wann die Antwort veraltet ist. Die Verwendung erfolgt in drei Schritten: Erstellen dessen, was das Lager bereits weiß, Aufschreiben dessen, was nur Menschen wissen, und Ermöglichen, dass der Agent beides liest.

Erster Schritt: Erstellen dessen, was das Lager bereits weiß

Wenn eine BigQuery-Tabelle bereits dokumentiert ist, muss der langweilige Teil nicht mehr von Hand eingetippt werden. Das OKF-Repository enthält einen Erstellungsagenten, und ein Befehl wandelt ein BigQuery-Datensatz in ein Paket um.

uv tool install git+https://github.com/GoogleCloudPlatform/open-knowledge-format

reference-agent enrich \
  --source bq \
  --dataset "$PROJECT_ID.marketplace" \
  --out bundles/generated \
  --no-web

Es erzeugt ein datasets/-Dokument, ein tables/-Dokument für jede Tabelle sowie regelmäßig aktualisierte index.md-Dateien. Durch das Hinzufügen von --no-web wird der optionale Schritt übersprungen, bei dem bestehende Dokumentation eingefügt wird, wodurch die erste Ausführung reproduzierbar wird.

Das Ergebnis ist besser als erwartet. Es beschreibt die Struktur jeder Tabelle, findet die richtige Verknüpfungsschlüssel und dokumentiert die Statuswerte. Selten werden Metric- oder Reference-Dokumente erzeugt, da eine BigQuery-Quelle nur Dataset- und Tabelle-Konzepte liefert und nichts weiter. Die Grenzen werden durch das festgelegt, was das Datenlager bereits über sich selbst aufzeichnet.

Überprüfen Sie dies, bevor Sie annehmen, dass sich ein anderes Lager genauso verhält. Die Statuswerte erscheinen in den generierten Dokumenten nur deshalb, weil jemand sie in die Spaltenbeschreibungen des DDL eingefügt hat. Richten Sie den Generator auf reine, undokumentierte Spalten aus – dann hat er weitaus weniger Anhaltspunkte.

Die generierten Dokumente können Fehler enthalten, und das Experiment liefert ein Beispiel dafür. Bei einem Durchlauf entstand ein Abframuster mit sum(t2.total_price), doch es gibt keine solche Spalte. Der tatsächliche Name lautet gross_amount, der bereits in der eigenen Schema-Tabelle des gleichen Files zwei Abschnitte zuvor korrekt angegeben ist. Der Ausführung dieses Codeausschnitts fehlt es an den notwendigen Informationen.

Dort kommt die Funktion verified ins Spiel. Jedes generierte Dokument weist generated: {by: reference_agent/...} auf, aber kein verified-Ereignis, wodurch das Format es als unüberprüft kennzeichnet. Ein Bundle dokumentiert seine eigene Herkunft, und die Trennung der maschinellen Ausgabe von menschlichen Entscheidungen erfordert keine Änderungen.

Zweiter Akt: Aufschreiben, was nur Menschen wissen

Zwei handgeschriebene Dateien im selben Bundle und im selben Format reichen aus, um die vier versteckten Entscheidungen festzuhalten. metrics/gmv.md ist die wichtigere davon, und sein Frontmatter zeigt an, wo die Vertrauensfelder ihren Platz finden.

---
type: Metric
title: Gross Merchandise Value (GMV)
description: Total settled transaction value for a period in IDR, excluding cancellations, reversals and returns.
tags: [metrics, finance, headline-metric]
generated: { by: human:analytics-lead@marketplace.example, at: 2026-09-01T09:00:00+07:00 }
verified:
  - { by: human:analytics-lead@marketplace.example, at: 2026-09-01T11:00:00+07:00 }
stale_after: 2027-01-31T00:00:00+07:00
---

Der Text erläutert alle vier Bedingungen ausführlich und macht klar, dass das Schema keine davon erfüllt. Eine Abwicklung bedeutet transaction_status = 'settlement' und ausdrücklich nicht status_code = 200. Die Bestellungen müssen order_status = 'completed' sein, wobei Rückerstattungen entfernt werden müssen. Für diesen Zeitraum gilt settlement_ts als Grenze; die Überprüfung erfolgt mit einem halboffenen Bereich mit einem expliziten +07-Offset: von 2026-07-01 00:00:00+07 einschließlich bis 2026-08-01 00:00:00+07 ausschließlich. Ein BETWEEN-Operator bei reinen Datumszeichenfolgen führt dazu, dass der letzte Tag weggelassen wird und jeder Zeitstempel als UTC betrachtet wird, wodurch jede Grenze um sieben Stunden verschiebt.

Der Wert stale_after erledigt die eigentliche Arbeit. Er löst das Januar-Problem in einer einzigen Zeile: Die Finanzabteilung gibt jeden Januar die Regeln zur Ertragserkennung neu heraus, wodurch die Definition am 31. Januar 2027 ausläuft, und dem Agenten wird mitgeteilt, diesen Wert statt des aktuellen Werts auszuweisen.

Die zweite Datei, references/jabodetabek.md, listet die dreizehn genauen destination_city-Werte auf und warnt vor LIKE '%Jakarta%', da dadurch acht dieser Werte unbemerkt übersehen werden würden.

Hier wird die Zusammenarbeit greifbar. Die Neudefinition des GMV erfolgt nun über einen Pull Request an eine Markdown-Datei, die der zuständige Analyst überprüfen kann, ohne dass sofortige Änderungen vorgenommen oder ein Backend neu bereitgestellt werden muss. Googles Beispielpaket beinhaltet sogar weiterhin die veraltete Datei gross-margin-legacy.md, damit historische Ergebnisse weiterhin reproduzierbar bleiben – etwas, was einfache, sofortige String-Änderungen nicht leisten können.

Akte drei: Der Agent, der sie liest

Zur Datenzugriff ermöglicht der Agent den verwalteten BigQuery MCP-Server von Google Cloud unter https://bigquery.googleapis.com/mcp, der aktiviert wird, sobald die BigQuery-API für das Projekt freigeschaltet ist. Es muss nichts bereitgestellt werden.

Der einzige benutzerdefinierte Code im Projekt ist ein Tool, das eine Datei liest.

def read_okf_concept(path: str) -> dict:
    """Read one OKF concept document from the local bundle.

    Args:
        path: Path relative to the bundle root, for example "metrics/gmv.md".
            Call this with "index.md" first to find which concepts exist.

    Returns:
        'status', and on success 'content' with the raw markdown and frontmatter.
    """
    doc = (OKF_BUNDLE / path.lstrip("/")).resolve()
    # `path` is model-controlled. Block anything that escapes the bundle.
    if not doc.is_relative_to(OKF_BUNDLE) or not doc.is_file():
        return {"status": "error", "error": f"no concept at {path}"}
    return {"status": "success", "content": doc.read_text(encoding="utf-8")}

Dann wird der Agent selbst definiert.

bigquery_mcp = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://bigquery.googleapis.com/mcp",
        headers={
            "Content-Type": "application/json",
            "Accept": "application/json, text/event-stream",
        },
        sse_read_timeout=300.0,
    ),
    header_provider=_bigquery_auth_header,
    tool_filter=[
        "list_dataset_ids",
        "list_table_ids",
        "get_dataset_info",
        "get_table_info",
        "execute_sql_readonly",
    ],
)

root_agent = Agent(
    name="marketplace_analytics_agent",
    model="gemini-3.7-flash",
    instruction=(
        "Before writing any SQL: call read_okf_concept('index.md'), then read every "
        "concept the question touches: the metric, the payment status, the geography.\n"
        "Use only the filters, joins and period cuts those concepts define. "
        "Never invent a status value or a metric formula.\n"
        f"Run queries with execute_sql_readonly, passing projectId='{PROJECT_ID}'.\n"
        "Show the SQL you ran, and name the concepts you relied on."
    ),
    tools=[read_okf_concept, bigquery_mcp],
)

Das Experiment führte anschließend dieses Gespräch durch.

Was tatsächlich geschah

Agent, Frage und Ausgangsdaten blieben in allen Konfigurationen unverändert. Nur der Ordner, auf den OKF_BUNDLE zeigte, änderte sich, und jede Konfiguration wurde viermal ausgeführt.

Ohne Wissensschicht, mit einem Lesetool, das auf einen leeren Ordner zeigte, und nur der Skriptintrospektion des MCP-Servers als Grundlage ergaben vier Durchläufe derselben Frage drei unterschiedliche Hauptwerte: IDR 371.251.000, 333.020.000 und 371.886.000. Der höchste Wert lag um 29 % über dem wahren Wert.

Mit dem generierten Bundle und einem einzigen reference-agent enrich-Durchlauf blieb der Wert konstant. Jedes Mal wurde IDR 329.590.000 ermittelt – stabil und reproduzierbar, aber dennoch um 15 % zu hoch.

Durch Hinzufügen der beiden manuell erstellten Konzepte wurde jedes Mal IDR 286.740.000 ermittelt. Das ist korrekt, und die Antwort nennt die Konzepte, auf die sie sich stützte.

Der Ablauf ist einfach: Die Genauigkeit der Antworten wird durch die Präzision der bereitgestellten Kenntnisse begrenzt. Ohne zusätzliche Schichten schätzt der Agent bei jedem Schritt die fehlende Logik und macht dabei unregelmäßig bis zu 29 Prozent Fehler. Ein aus Maschinen ableitbares Schema-Context beseitigt diese Instabilität und reduziert die Fehlerquote auf 15 Prozent, kann die Aufgabe jedoch nicht allein bewältigen, da der verbleibende Mangel in Geschäftsrichtlinien und nicht in technischen Aspekten liegt. Nur explizite, von Menschen überprüfte Definitionen für die ungeschriebenen Regeln – wie genaue Zeitstempelgrenzen und Bestellstatus – ermöglichen es dem Agenten, zuverlässig die exakte Zahl zu erzielen.

Als wichtigster Faktor für die Genauigkeit erwies sich weder ein längeres Prompt noch ein größeres Modell. Vielmehr sind strukturierte, versionsgesteuerte Fachkenntnisse entscheidend, die dort platziert werden, wo das Datenbankschema endet.

Was dieser Ansatz nicht behebt

Die Grundierung hängt von Anweisungen ab, sodass ein Modell sie gerne ignorieren kann, und nichts hindert daran, SQL vor dem Lesen eines Konzepts zu schreiben. Jeder, der eine feste Garantie wünscht, kann einen ADK before_tool_callback hinzufügen, der einen Abfragenaufruf ablehnt, wenn in diesem Zug kein Konzept gelesen wurde.

Markdown bietet ebenfalls keine Schema-Validierung. Ein Analyst könnte ein fehlerhaft formatiertes Konzept einreichen, und OKF bleibt absichtlich nachsichtig, indem es die Nutzer dazu zwingt, unbekannte Typen und tote Links zu tolerieren. Wahre Schutzmaßnahmen ergeben sich aus Code-Reviews in Pull-Requests sowie von verified und stale_after, die unüberprüfte oder abgelaufene Definitionen dem Agenten beim Lesen anzeigen. Die Spezifikation bezeichnet die Vertrauensstufen als beratende Signale, wodurch deren Nutzung demjenigen überlassen bleibt, der den Agenten entwickelt. Der Agent hier liest sie, und auch andere müssen das tun.

Auch diese Zahlen sind keine Vergleichswerte: eine einzige Frage, ein Modell und vier Ausführungen pro Einstellung mit vorgegebenen Daten, die dazu dienen, Fallstricke zu schaffen. Sie zeigen einen Mechanismus, sagen aber nichts über den durchschnittlichen Einfluss von OKF auf die Genauigkeit aus.

Die bleibende Lektion

Der Mechanismus hat weiterhin Wert. Wenn ein Datensystem falsch liegt, sieht die Antwort nicht falsch aus. Es wird keine Ausnahme ausgelöst, kein Ergebnis kommt leer zurück, und nichts färbt sich rot. Der SQL-Code ist gültig und die Darstellung erscheint plausibel, weshalb sie bereits früh auf einer Präsentationsdiashow erscheint, bevor jemand Zweifel hat.

Der gefährlichste Fehler ist nicht der unregelmäßige. Ohne Anleitung lieferte das System bei jeder Ausführung eine neue Zahl – das lässt sich bereits am Nachmittag leicht erkennen. Mit der Hälfte des Wissens lieferte es bei jeder Ausführung dieselbe Zahl und erwähnte beiläufig eine Alternative, deren Auswahl es nicht begründen konnte. Ein stabiles Ergebnis wirkt wie ein Beweis für Richtigkeit, beweist aber nichts.

Ein besseres Modell ist nicht unbedingt das, was die Lücke schließt. Ein einziger Befehl fasste alles zusammen, was das Lager über sich selbst sagen konnte, und endete genau dort, wo menschliche Entscheidungen beginnen: das Zeitstempel, der einen Zeitraum abgrenzt, die Bestellstatus, die gezählt werden, sowie der Status, der anzeigt, dass das Geld eingegangen ist. Das sind Entscheidungen und keine Fakten, und sie sollten einmal von der Person, die sie getroffen hat, an einem Ort aufgezeichnet werden, an dem man diese Person später befragen kann.

Eine gute Möglichkeit, anzufangen, ist ein kleineres Projekt. Wählen Sie den Metrikenwert, über den das Team ständig streitet – jenen, bei dem zwei Dashboards unterschiedliche Werte anzeigen und jeder weiß, an welchen Analysten er sich wenden soll. Führen Sie den Generator mit dem dahinterliegenden Datensatz aus und schreiben Sie anschließend die Definition zusammen mit dem zuständigen Verfasser in einer Datei sowie in einem Pull Request nieder. Das eigentliche Arbeitsthema ist das Gespräch darum. Das Format gibt lediglich einen Rahmen sowie Aufzeichnungen darüber, wer zustimmte und wann die Gültigkeit endet. Die Tools sind der langweiligste Teil. Interessant ist vielmehr, was passiert, wenn ein Analyst und ein Ingenieur sich auf einen Satz einigen und ihn festhalten müssen – und welche versteckten Entscheidungen dabei getroffen werden.