Why

Almost every application records auditable operations, and almost every application invents its own shape for them. The result: records that cannot be validated until a defect is found years later in retained data; two systems' audit trails that cannot be read together without bespoke translation; the same questions — what is an actor, how is acting on behalf of someone recorded, where does an approval go — re-litigated on every new application; and audit data that quietly accumulates secrets and personal data because nobody decided what belongs in it. OpenAuditModel answers those questions once, in a shape a validator can check.

A minimal event

Seven required fields. Everything else is optional context.

{
  "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"
  }
}

Check one

Not yet published to a package registry. Requires Node.js 22 or newer.

git clone https://github.com/OpenAuditModel/OpenAuditModel.git
cd OpenAuditModel && npm install && npm run build

npm run auditmodel -- validate audit-event.json
npm run auditmodel -- lint-privacy audit-event.json
npm run auditmodel -- check-profile audit-event.json --profile financial-transaction-management

Exit 0 means a verdict was produced and it passed. 1 means it failed. 2 means the tool could not run. 3 means no verdict was produced — the profile governs no rule for that event, or the input was not an audit event and was never scanned. 3 is never an approval.

Canonical schemas

These URLs are the identifiers recorded in each schema's $id. They are stable and the versioned documents are immutable. Nothing needs to fetch them: validation is offline, and an identifier is a name rather than a fetch instruction.

Domain profiles

10 enforceable profiles, 127 rules. A profile only ever adds requirements to the core model; none relaxes it. An event no rule governs is reported as not-applicable, never as conforming.

The addresses below serve each profile document. They are addresses, not identities: a profile carries name and version, not an $id, so nothing should pin these URLs as canonical identifiers.

Adopting it

Nothing here requires changing where you store anything. The lowest-friction path is an export mapper, which is also the shape enterprise customers ask for:

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

After that: instrument one new service, validate fixtures in CI, and design events with an AI agent through the MCP server, which exposes the same deterministic engines over Streamable HTTP:

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

It is a remote service: audit event content submitted to it leaves your machine. For regulated data, build and run the server from the source repository instead — it is stateless and persists nothing either way.

What it is not

Not a log storage backend, a database, a SIEM, a GRC platform, a policy engine or an authorization system. Not a replacement for OpenTelemetry, CloudEvents, ECS, OCSF, CADF or OSCAL. It composes with them.