Warum

Fast jede Anwendung zeichnet auditierbare Vorgänge auf, und fast jede erfindet dafür ihre eigene Form. Das Ergebnis: Datensätze, die sich erst validieren lassen, wenn Jahre später ein Fehler in aufbewahrten Daten gefunden wird; Audit-Trails zweier Systeme, die sich ohne eigens gebaute Übersetzung nicht gemeinsam lesen lassen; dieselben Fragen — was ist ein Akteur, wie wird Handeln im Namen einer anderen Person erfasst, wohin gehört eine Freigabe —, die bei jeder neuen Anwendung neu verhandelt werden; und Audit-Daten, die still Geheimnisse und personenbezogene Daten ansammeln, weil niemand entschieden hat, was hineingehört. OpenAuditModel beantwortet diese Fragen einmal, in einer Form, die ein Validator prüfen kann.

Ein minimales Event

Sieben Pflichtfelder. Alles andere ist optionaler Kontext.

{
  "specVersion": "0.1",
  "id": "018f1b5c-6d2a-7c3e-9a1b-4f5e6d7c8b9a",
  "time": "2026-03-14T09:24:31.412Z",
  "event": {
    "name": "data.record.update",
    "category": "data-modification",
    "outcome": "success"
  },
  "actor": {
    "type": "user",
    "id": "user-123"
  },
  "resource": {
    "type": "record",
    "id": "resource-123"
  },
  "application": {
    "name": "application-service",
    "environment": "production"
  }
}

Ein Event prüfen

Keine Installation, kein Checkout. Erfordert Node.js 22 oder neuer.

npx @openauditmodel/cli validate audit-event.json
npx @openauditmodel/cli lint-privacy audit-event.json
npx @openauditmodel/cli check-profile audit-event.json --profile financial-transaction-management

Exit-Code 0: Ein Urteil wurde gefällt und bestanden. 1: gefällt und nicht bestanden. 2: Das Werkzeug konnte nicht laufen. 3: Kein Urteil wurde gefällt — das Profil enthält keine Regel für dieses Event, oder die Eingabe war kein Audit-Event und wurde nie geprüft. 3 ist niemals eine Freigabe.

Kanonische Schemas

Diese URLs sind die in der $id jedes Schemas hinterlegten Bezeichner. Sie sind stabil, und die versionierten Dokumente sind unveränderlich. Nichts muss sie abrufen: Die Validierung ist offline, und ein Bezeichner ist ein Name, keine Abrufanweisung.

Domänenprofile

10 durchsetzbare Profile, 127 Regeln — 113 als Fehler durchgesetzt, 14 beratend. Ein Profil ergänzt das Kernmodell nur um Anforderungen; keines lockert es. Ein Event, das keine Regel erfasst, wird als nicht anwendbar gemeldet, nie als konform.

Die folgenden Adressen liefern die Profildokumente aus. Sie sind Adressen, keine Identitäten: Ein Profil trägt name und version, keine $id; diese URLs sollten nicht als kanonische Bezeichner festgeschrieben werden.

Einführung

Nichts hier erfordert, den Speicherort Ihrer Daten zu ändern. Der Weg mit der geringsten Reibung ist ein Export-Mapper — zugleich die Form, nach der Unternehmenskunden fragen:

existing audit database → mapper → OpenAuditModel NDJSON → customer, archive or SIEM

Danach: einen neuen Dienst instrumentieren, Fixtures in der CI validieren und Events mit einem KI-Agenten über den MCP-Server entwerfen, der dieselben deterministischen Engines über Streamable HTTP bereitstellt:

claude mcp add --transport http openauditmodel https://mcp.openauditmodel.org/mcp

Es ist ein entfernter Dienst: Übermittelte Audit-Event-Inhalte verlassen Ihren Rechner. Für regulierte Daten bauen und betreiben Sie den Server stattdessen aus dem Quell-Repository — er ist in beiden Fällen zustandslos und speichert nichts.

Was es nicht ist

Kein Log-Speicher-Backend, keine Datenbank, kein SIEM, keine GRC-Plattform, keine Policy-Engine und kein Autorisierungssystem. Kein Ersatz für OpenTelemetry, CloudEvents, ECS, OCSF, CADF oder OSCAL. Es fügt sich mit ihnen zusammen.