Governance Audit · Field Anatomy

What a governance decision records

Every AI-assisted access leaves a durable record. It is structured to answer the same six questions — readable for the customer, dependable for a post-incident analysis, and for the architect a reflection of clear, layered control.

Two real examples

kernel.mediated.decision Allowed

Whohmac:d434… · regular user

WhatGenerate an AI answer (call_llm, local)

DataKRITIS-bound · KRITIS-internal zone

Rule12 kernel checks passed (kernelabi:7)

Evidence2026-07-29 07:46:48 UTC · op-0aa1b9…-185

Record as JSON — identifiers shortened

{
  "event": "kernel.mediated.decision",
  "timestamp": "2026-07-29T07:46:48.857366534Z",
  "level": "audit",
  "owner_sub_pseudo": "hmac:d434…",
  "admin_bypass": false,
  "retention_class": "critical",
  "operation_id": "op-0aa1b9…-185",
  "step_seq": 1,
  "details": {
    "op": "call_llm",
    "verdict": "admitted",
    "provider": "local",
    "policy_engine_version": "kernelabi:7",
    "cumulative_class": "KRITIS-bound",
    "cumulative_layer": 4,
    "cumulative_zone": "KRITIS-intern",
    "decisive_rules": [
      "capability_op_authority", "abi_known_op", "step_budget",
      "resource_cost_validation", "resource_budget_tokens",
      "resource_budget_retrieval_docs", "resource_budget_recall_docs",
      "resource_budget_crossing_calls", "resource_budget_payload_bytes",
      "label_ceiling_layer", "label_ceiling_class", "label_ceiling_zone"
    ]
  }
}

authz.denied Blocked · 403

Whohmac:8a2a… · regular user

WhatRequest to a project (POST …/devops/query)

DataProject devops

RuleDenial recorded · rule not verbatim

Evidence2026-07-29 14:38:25 UTC · trace c69b1701…

Record as JSON — identifiers shortened

{
  "event": "authz.denied",
  "timestamp": "2026-07-29T14:38:25.26110952Z",
  "level": "audit",
  "owner_sub_pseudo": "hmac:8a2a…",
  "admin_bypass": false,
  "retention_class": "critical",
  "method": "POST",
  "path": "/api/projects/devops/query",
  "status": 403,
  "project": "devops",
  "trace_id": "c69b1701…",
  "details": {
    "outcome": "denied"
  }
}

Both are unchanged from the system — one allowed and one blocked access, both by regular users (no admin privileges), both durably recorded.

Six questions every record answers

The same fields — three perspectives

Who acted?

owner_sub_pseudoadmin_bypass

allowedhmac:d434… · regular blockedhmac:8a2a… · regular

The actor as a pseudonymised identifier — no plain-text name, but resolvable by authorised parties. admin_bypass says whether it was a regular access or a special privilege.

ArchitecturePseudonymisation at exactly one layer — privacy by design, without losing accountability. Exceptions carry the identifier too: no blind spot.

What was done or attempted?

eventopmethodpath

allowedGenerate an AI answer (call_llm) blockedProject request (POST …/devops/query)

The kind of decision and the concrete operation. event distinguishes an AI operation mediated by the governance kernel from a request checked at the access layer.

ArchitectureTwo event types from two enforcement layers — AI mediation and access control — flow into one shared audit. One language, wherever the decision was made.

Allowed or blocked?

verdictstatusoutcome

allowedpermitted (admitted) blockedrejected (403 · denied)

The outcome — clear and in both directions. For a review, the blocked decisions are the most revealing: they prove the control takes effect.

ArchitectureAdmission and denial are treated alike and both recorded — complete mediation. What the kernel does not explicitly permit does not happen, and stays visible.

Which data were affected?

cumulative_classcumulative_zoneproject

allowedKRITIS-bound · KRITIS-internal blockedProject devops

The protection classification or the affected project/mandate. An analyst sees at once whether an operation touched sensitive data and which zone it stayed in.

ArchitectureClassification-based access: the data’s classification decides, not chance. The zone in the record proves the operation did not leave the protected area.

By which rule?

decisive_rulespolicy_engine_version

allowed12 kernel checks (kernelabi:7) blockedDenial recorded · rule not verbatim

The decisive checks and the version that decided. An admission lists the rules passed; a kernel denial lists the one violated. Honestly: the access 403 records the denial but does not store the rule verbatim.

ArchitectureGovernance as explicit, versioned rules — no black box. Via the engine version, every decision is bound to a concrete, reproducible rule set.

When — and how provable?

timestamptrace_idoperation_id

allowed07:46:48 UTC · op-0aa1b9…-185 blocked14:38:25 UTC · trace c69b1701…

The time and a correlation anchor. These are exactly the IDs an incident analysis needs to reconstruct the whole sequence from individual records.

ArchitectureThe record is written before the effect (write-ahead) and is linkable via trace and operation ID — tamper-evident and fully reconstructable.

What the structure reveals

Three properties — straight from the fields

Complete. Allowed and blocked are witnessed alike, across both control layers — nothing permitted stays invisible, nothing blocked slips through.
Explicit. Every decision names its decisive rule and its version — governance as traceable code, no black box.
Provable. The record is written before the effect, pseudonymous yet linkable and tamper-evident.

So it shows not only what happened — but also why, and how it can be verified.

The fields shown here are the ones essential for the customer, the architect and post-incident analysis. A record also carries technical storage details (among them the dedup key <operation_id>:<step_seq>:<event>, which makes a double write idempotent). The identifiers (actor pseudonym, operation and trace ID) are shortened on this public page; the full values — essential for reconstructing an incident analysis — are available only in the internal, signed-in view (/admin/gdr/).