Audit Trail

Tracking data changes for compliance and security

Scope

The audit trail captures governance decisions — changes to version constraints, approvals, team structure, and system ownership. Operational data that changes frequently through automated processes (components discovered via SBOM, repositories, hashes, external references) is excluded.

Audited Events

Governance Operations

  • Version constraint lifecycle — creation, status changes (ACTIVATE, DEACTIVATE, ARCHIVE), deletion
  • License decisions — ALLOW_LICENSE, DENY_LICENSE, whitelist ENABLE/DISABLE
  • Technology approvals — TIME framework categorization, version-specific approvals, revocations

Relationship Changes

  • Team membership — ADD_TEAM_MEMBER, REMOVE_TEAM_MEMBER (per-team granularity)
  • Ownership — system ownership, technology stewardship assignments
  • Version constraint enforcement — constraint-to-team application changes

Entry Schema

Each AuditLog node stores:

  • id — UUID
  • timestamp — Neo4j datetime
  • operation — e.g. ACTIVATE, DENY_LICENSE, ADD_TEAM_MEMBER
  • entityType — VersionConstraint, User, Technology, etc.
  • entityId / entityLabel — target entity identifier and display name
  • previousStatus / newStatus — before/after values
  • changedFields — array of affected field names
  • reason — auto-generated or user-provided
  • source — API, SBOM, System
  • userId — acting user's ID

Graph Relationships

  • (AuditLog)-[:AUDITS]->(entity) — links the entry to the affected node(s). A single entry can audit multiple entities (e.g., both the User and the Team in a membership change).
  • (AuditLog)-[:PERFORMED_BY]->(User) — links to the acting user. The UI resolves the user's display name through this relationship rather than storing it on the entry.

Audited Entity Scope

  • Technology & Version — approval decisions, stewardship changes, version range updates, risk level changes
  • Team — membership changes, responsibility area changes
  • VersionConstraint — status transitions, enforcement scope changes
  • System — ownership changes, criticality level changes
  • Team Approvals — TIME category changes, EOL dates, migration targets

Access Control and Retention

  • Read access requires superuser role. Entries are created server-side within the same transaction as the mutation — no client-side audit writes.
  • No credentials, tokens, or PII are stored in audit entries.
  • Entries are append-only with indefinite retention. No purge mechanism exists; implement one if retention rules require it.