EU AI Act: Article-by-Article Mapping

This page exists so you can find the thing you need by citation. Each row names an obligation from Regulation (EU) 2024/1689, then names the mashin mechanism that produces evidence for it and how to see that evidence yourself.

What this page is not

This is our own plain-English mapping. It is not legal advice, not a conformity assessment, and not an endorsement or certification by any regulator or standards body. Whether a given system is high-risk, and whether its evidence satisfies a given obligation, is a determination for you and your counsel. What we can tell you is exactly what the runtime records, what it does not, and how to inspect both.

The short version

Most platforms treat audit logging as something you configure. In mashin there is no execution path that skips the record: every run emits an append-only, hash-chained ledger from ExecStart to ExecEnd, and effects can only happen by way of a governed directive that is recorded as it is decided. The record is not an observation of the run. It is part of how the run happens.

That property is what makes the mapping below short. You are not assembling evidence from logs after the fact; you are reading a record that could not have been omitted.

The mapping

Article 12: Record-keeping

High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.

Every run produces a behavioral ledger entry chain. Fourteen event types are defined in specs/behavioral-ledger-spec.yaml, including execution start and end, step start and end, policy decisions, guardrail violations, effect events, authorization grants and capability injections. Recording is not a setting. A run that produced no ledger is not a run that happened quietly; it is a state the runtime cannot reach.

Logging capabilities shall enable the recording of events relevant for identifying situations that may result in the AI system presenting a risk, and for facilitating post-market monitoring.

Guardrail violations, permission denials and policy decisions are their own event types rather than log lines, so “what was refused, and on what authority” is a query, not a text search. See Behavioral Ledger.

Article 12(3) / Article 19: Traceability and log retention

Each event carries an event hash, the previous hash and an index; the chain is verifiable end to end without trusting the process that wrote it. Tampering does not require detection heuristics, it breaks re-derivation. See Verifying Integrity.

Article 14: Human oversight

Human oversight shall be enabled through measures … appropriate to the risks.

Oversight is enforced: a machine can park at an approval, execution genuinely stops, a person decides, and the run continues from that decision.

It is also evidenced. The decision is written to the ledger as a control-flow event before the run moves, carrying who decided, what triggered the resumption (a person, a deadline, an external event), how long the machine waited, and a digest of the answer given. Like every other event it has a hash and an index, so it is part of the same tamper-evident chain as the steps around it.

The ordering is the part that matters for an auditor. The record is written first and the resumption does not proceed without it: if the record cannot be written, the resume refuses, the machine stays parked exactly where the person found it, and the answer can be given again. There is no path on which a machine acts on a human decision that the ledger cannot show was made. That is what makes the absence of a record meaningful rather than inconclusive.

One honest limit: the responder’s identity is only as good as what the answering surface supplies. The HTTP endpoint records the authenticated user, the approval inbox records whoever answered, and the timeout sweep names itself rather than impersonating a person. A surface that supplies no identity produces a record of the decision without a name on it.

Branch and gate decisions are a different matter and they are fully recorded. In the sample run below, a decide step appears in the audit trail with its own hash alongside the compute steps, which means the path the run actually took is part of the tamper-evident record rather than something reconstructed from outputs.

Article 15: Accuracy, robustness, and repeatability

Runs are deterministic given the same inputs, recorded model snapshot and recorded time, so a past run can be re-executed rather than merely re-read. What the record claims happened can be checked by making it happen again.

Article 50: Transparency obligations

The ledger records what was generated and which downstream systems were touched, because every external effect must pass through a governed directive to occur at all. “Which systems did this agent reach?” is answerable from the record without instrumenting the systems themselves.

Article 72: Post-market monitoring

Every run produces measures (outcome, duration, cost, token counts, and any domain metrics the machine declares). Monitoring is the same record read continuously, not a second pipeline that has to be kept in sync with the first.

Run it yourself

mashin compliance-report --run RUN_ID --format json

Here is the report from a real governed run of a small order-review machine, unedited:

%{
  run_id: "run_03407zqCzpGmkufDABRjxe",
  report_type: "run_compliance",
  governance_mode: "enforce",
  sections: %{
    run_summary: %{
      status: "completed",
      started_at: "2026-08-02T10:59:21.186223Z",
      completed_at: "2026-08-02T10:59:21.421373Z",
      duration_ms: 235,
      machine_hash: "sha256:b0ae9f38f0f392bc11d22346cd79a893fc8dec46ecdb7a30dbe5b33eea48be81",
      policy_hash:  "sha256:79bc77b7b64a1637522290a1bf68ddea24982609b3a9ec802751ceafc6a29d45",
      head_hash: "sha384:97793ee2170b2e149273d11d9fa5ea7f8cd038406983761891007f9967830e3b3e...",
      verification_status: "verified"
    },
    step_audit_trail: %{
      step_count: 3,
      steps: [
        %{name: "risk",     type: "compute", status: "completed", event_index: 2, hash: "sha384:4eb3131b..."},
        %{name: "route",    type: "decide",  status: "completed", event_index: 7, hash: "sha384:3fa8b04c..."},
        %{name: "escalate", type: "compute", status: "completed", event_index: 9, hash: "sha384:15ca1f0d..."}
      ]
    },
    hash_chain_verification: %{
      chain_present: true,
      chain_verified: true,
      chain_length: 3,
      chain_error: nil
    },
    violations: %{total_count: 0, violations: []}
  }
}

Three things worth noticing. route is a decide step carrying its own hash, so the branch the run took is evidence, not inference. The event indices are 2, 7 and 9 rather than 1, 2, 3: the steps are interleaved with the other ledger events in one chain, and chain_verified: true is the result of re-deriving that whole chain, not of checking that the three steps are contiguous. And policy_hash answers which policy version decided this run, on every trigger path: it is captured inside the runtime at the single point every run passes through, not by whichever entry point started it, so an HTTP-triggered run and a scheduled one carry it alike.

What this does not give you

Rows above are worth nothing if the limits are not stated with them.

• Step-level timing is not populated. Run-level duration_ms is real; per-step duration_ms currently comes back nil, so “which step was slow” is not answerable from the record. Use the run-level figure. Tracked as GAP-1295.
• Cost and token measures reflect what the run actually consumed. The sample is pure computation, so its zeros are correct rather than missing. A run with reasoning steps reports real figures.
• An oversight record is only as identified as its surface. The decision itself is always recorded. The name attached to it comes from whichever surface answered, so a surface that authenticates nobody produces an unattributed decision. See Article 14.
• This is evidence, not compliance. The Act obliges you to have risk management, documentation, data governance and conformity assessment. mashin produces the record-keeping and traceability evidence. It does not perform your conformity assessment, and no runtime can.
• mashin does not make a model safe. The claim here is narrow and it is about evidence: what a machine did is provable, because there is no path by which it could act without the record. That is a different claim from the model behaving well, and we do not make the second one.

Related

• Behavioral Ledger: the event types and what each records
• Verifying Integrity: how chain verification works