Article 12 —
Monthly Log-Integrity Report.

This package documents every action taken by Acme Bank UK Limited’s credit_review agent on behalf of its customers during March 2026. The package is structured so that an external auditor, internal audit lead, or regulator can:

• reconstruct any of the 184,402 individual decisions made in the period, end-to-end, including the prompt, the model version, the retrieved bureau data, the policy that fired, and the human approval (where one was given);
• verify cryptographically that the record has not been altered since capture, without depending on any system Runfile controls;
• map every event to the regulatory controls in scope, with the specific clauses cited and the satisfying events linked.

The agent under review is a credit-decision system that assesses personal loan applications between £1,000 and £75,000 against a published lending policy. It runs in production across Acme’s mobile and web channels. Outputs that fall outside the agent’s authority — applications above the agent’s £25,000 single-decision limit, applications where the debt-to-income ratio exceeds policy thresholds, applications where a credit-bureau anomaly is detected — are escalated to a human underwriter rather than auto-declined.

In March 2026, the agent processed 184,402 applications. Of these, 162,847 (88.3%) were approved automatically, 16,921 (9.2%) were declined automatically under published policy thresholds, and 3,317 (1.8%) were escalated to a human underwriter under the Article 14 human-oversight design. Of the 3,317 escalated cases, 2,000 received final approval from a human reviewer and 1,317 were declined.

A further 1,317 cases were initially routed to auto-decline but flagged by Acme’s complaints channel for review under Consumer Duty; the original decline events and the subsequent appeal events are both captured in the chain and visible in the per-appeal reconstruction queries.

Forty-seven events show guardrail refusals. These are not failures of the agent — they are the system correctly declining to act on out-of-policy input (such as applications mis-routed from a different product line, or prompts containing unredacted bureau identifiers). Refusal events are first-class evidence of effective oversight under EU AI Act Article 14 and demonstrate that the controls fired when they should have.

The package is INTACT. The 1,475,216 events recorded in the period form an unbroken per-event hash chain. Each day in the period was committed to a signed daily Merkle root, and each week’s roots were anchored to the public Sigstore Rekor transparency log. The integrity of the record can be re-verified independently using the Runfile Verifier CLI, without contacting Runfile’s infrastructure.

The package maps to nine regulatory controls. All nine are satisfied. The control-by-control breakdown begins on §03.

This section reconstructs one representative decision from the period in full. The decision is run 8a7b3c2d-credit_review-20260314T114203Z — a £24,500 personal-loan application processed on 14 March 2026 at 11:42:03 GMT for an existing customer (identifier tokenised at the SDK boundary).

The outcome was a decline, escalated to a human underwriter, who confirmed the decline. The reconstruction shows every event the agent recorded, in temporal and causal order, with each event’s hash chain entry visible.

Run ID:           run_8a7b3c2d-credit_review-20260314T114203Z
Agent identity:   did:web:acmebank.uk:agents:credit_review
Agent version:    3.2.1
Capture SDK:      runfile-sdk-python v1.0.4
Principal:        customer:hash:f8a2b9c1d3e4f567  (tokenised; resolution audit-logged)
Tenant:           acme-bank-uk-ltd
Environment:      production
Region:           eu-west-1
Started:          2026-03-14T11:42:03.117Z
Completed:        2026-03-14T11:54:22.291Z
Total duration:   12 minutes 19 seconds (of which 12m 17s in human review)
Final outcome:    declined

The agent executed eight events. Each event’s payload was canonical-JSON serialised (RFC 8785), hashed with SHA-256, and chained against the prior event’s chain entry. The full 64-character hash for each event is listed in the integrity table on §05; the first sixteen characters are shown inline below.

This single run satisfies, on its own, the following regulatory predicates:

• EU AI Act Article 12(1) — automatic recording of events over the lifetime of the system. Every event the agent emitted is in the chain. The completeness alarm (§05) confirms no events are missing.
• EU AI Act Article 14 — human oversight. The agent did not auto-decide; it escalated to a human underwriter, whose decision is recorded with identity, timestamp, and signed justification.
• GDPR Article 22(2)(b) — the decision is not “solely automated” within the meaning of Article 22, because a human reviewer made the final determination after meaningful review. The 737-second review duration is recorded and audit-defensible.
• GDPR Article 22(3) — right to obtain human intervention. The escalation path is recorded; if the customer subsequently exercises their right to challenge the decision, the appeal path begins from event 08.
• GDPR Article 30(1) — records of processing. The run records the tenant, principal, purpose (credit assessment), retention class, and processing-basis tag (legitimate interest under Acme’s published lawful-basis policy).
• FCA SS1/23 §5.2 — effective challenge. The threshold breach was challenged by a human reviewer with documented authority and a recorded outcome.
• Consumer Duty — fair value test. The decline is supported by a recorded objective threshold (DTI 0.620 vs maximum 0.500), with the policy version captured.

The same predicates apply, at scale, to every other run in the period.

The following tables map every regulatory control in scope for this engagement to the events that satisfy it. Each control cites the specific clause, summarises what the clause requires, and links to the population of events that demonstrate compliance.

For an external auditor, this is the table to sign against. The population counts are exact; the satisfying events are queryable from the Runfile Audit Workbench using the run identifiers in §07.

The following frameworks were noted but not included in this engagement, by agreement with Acme’s Head of Internal Audit:

• SOX §404 — out of scope because the agent’s outputs do not flow into a financial control under SOX. Would be in scope if the agent were a revenue-recognition assistant.
• HIPAA — not applicable (no PHI in scope).
• DORA Article 17 — covered separately under Acme’s DORA incident-reporting pipeline. The agent’s events are available to that pipeline on request.
• PCI-DSS — the agent does not touch cardholder data.

A representative sample of the operational and compliance metrics for the period. The full per-day breakdown is in Appendix B.

The following KPIs are monitored continuously against thresholds set in Acme’s model-risk policy. All values for the period were within tolerance.

A completeness alarm is armed continuously: the ingest pipeline expects a per-tenant baseline event volume, and a drop below 75% of the 28-day moving average triggers an alert. The alarm did not fire in the period. The full alarm-armed log is in Appendix B.

Runfile Systems Limited attests that the events listed in this package were captured by the Runfile SDK v1.0.4 running in Acme Bank UK Limited’s production environment between 2026-03-01T00:00:00Z and 2026-03-31T23:59:59Z, hashed using SHA-256 with canonical JSON serialisation per RFC 8785, chained per-event, committed daily to signed Merkle roots, and anchored weekly to the Sigstore Rekor public transparency log.

The integrity of this package can be verified offline using the Runfile Verifier CLI without requiring trust in Runfile.

The four weekly meta-roots above were aggregated into a monthly meta-root and committed to the Sigstore Rekor public log on 2026-04-01.

The key used to sign every daily Merkle root in this period is held in AWS KMS, FIPS 140-2 Level 3 HSM-backed, in a dedicated key per tenant.

The public key is published at https://runfile.ai/keys/rf-acme-bank-uk-ltd-2026q1.pub and is bundled in /keys/ within this package.

The agent runtime — the SDK running in Acme’s environment — does not hold this signing key, has never seen it, and has no IAM permission to invoke a KMS sign operation. The separation between the entity that captures events and the entity that signs the manifests is the substance of the chain-of-custody claim. AWS CloudTrail records every invocation of this key and is available to Acme’s Internal Audit under their existing AWS audit pipeline.

For the worked-example run reconstructed in §02, the full per-event SHA-256 hash chain is reproduced here. Any party with the canonical-JSON serialisation of each event (bundled in /runs/run_8a7b3c2d-credit_review-20260314T114203Z.jsonl) can recompute these hashes independently.

The final chain entry a3f1ed4d6b1b3b2e… is itself an input to the daily Merkle tree for 2026-03-14, whose root is a7dcd5a41bcde46e347be9ae16e78df9aff5dd8bc7d49ef0111a1fa3719e690e (see weekly anchor table above).

The Runfile Verifier CLI was run against this package on 2026-04-02 at 09:14:22 UTC, in offline mode, on a Linux workstation in Acme’s Internal Audit environment with no network access. The CLI binary used was runfile-verifier-linux-amd64-v1.0.2, SHA-256 e8c4f1a9b7d3... (full hash in /verifier/binary.sha256).

The verifier consumed only the contents of this package and the bundled Sigstore Rekor inclusion proofs. It did not contact Runfile infrastructure.

A passing verification, as above, confirms five independent integrity properties:

1. Schema integrity — every event is well-formed and validates against the published schema.
2. Per-event integrity — no event in the period has been altered since recording.
3. Daily integrity — the day’s events form the Merkle tree whose root was signed at the time of capture.
4. Signature integrity — the signatures are valid against a public key whose fingerprint is independently published.
5. External integrity — the daily roots are committed to a public transparency log that Runfile cannot retroactively alter.

A failure on any step prevents the next step from running and produces a specific error code in the JSON report. The verifier is conservative: it refuses to assert integrity if any check is ambiguous.

This section documents the assumptions, scope decisions, and methodology under which this package was prepared. An external auditor reviewing this package should review this section before relying on the integrity claims.

The control mapping version applied to a given run is recorded with the run. This package applied v1.4 to all 184,402 runs because all runs in the period occurred after the v1.4 release. Runs from prior periods reference earlier mapping versions; the earlier mappings remain bundled in this package’s /mappings/ directory.

All timestamps in this package are UTC. The clock source for the capture SDK is the host operating system’s monotonic clock, with absolute time taken from AWS Time Sync Service (which is itself synchronised against Stratum 1 sources). At ingest, every event is additionally timestamped by the Runfile event processor using a signed RFC 3161 timestamp from AWS’s qualified time service. Where there is discrepancy between the host-emitted timestamp and the ingest timestamp greater than 60 seconds, the run is flagged in Appendix B; no such flags occurred in this period.

• Every event emitted by the named agent in the named environment during the period.
• All eight event classes (identity, LLM calls, tool calls, retrievals, approvals, refusals, side effects, outcomes).
• Cryptographic chain-of-custody artefacts (hashes, signatures, Rekor proofs).
• Control mappings as held in runfile-controls-v1.4.

• The cleartext of LLM prompts and responses. Only hashes leave Acme’s environment; cleartext is held in Acme’s environment under their existing retention.
• The cleartext of the credit bureau payloads. Only hashes and structured fields needed for reasoning are captured; the bureau cleartext is held in Acme’s environment.
• The cleartext of human-reviewer justifications. Only hashes are captured; cleartext is held in Acme’s environment.
• The substantive correctness of any individual credit decision. This package proves what happened; it does not opine on whether the decision was right. Decision quality is reviewed under Acme’s separate quality-assurance pipeline.
• Bias, fairness, or disparate-impact testing. These are reviewed under Acme’s separate fairness pipeline and are out of scope here.
• Real-time guardrail effectiveness. The 47 guardrail refusal events are recorded as evidence that the guardrails fired; whether the guardrail logic itself is well-calibrated is reviewed separately.

All events in this package were captured, processed, signed, and stored within AWS region eu-west-1. No event payload, no hash, no manifest, and no signing operation crossed an EU border during the period. Sigstore Rekor anchoring posts only the monthly meta-root (a single 32-byte hash) to the public log; the meta-root does not contain or reveal any payload data.

The capture SDK records events at every framework hook point in LangGraph, Anthropic’s Claude SDK, the OpenAI Agents SDK, and any MCP-instrumented tool. For the agent in question, the SDK is configured in full capture mode (every framework event recorded) rather than sampled mode. No sampling was applied during the period.

The completeness alarm armed against a baseline of the trailing 28-day mean event volume, with a threshold of 75%. The alarm did not fire in the period. Two manual completeness queries were run by Acme’s IT audit during the period (on 2026-03-12 and 2026-03-25); both queries reconciled the recorded event count against Acme’s own LangGraph telemetry within tolerance (< 0.01% difference, attributable to clock skew).

This package is designed to be re-verified by any third party without requiring trust in Runfile. To re-verify:

The Runfile Verifier CLI is a single statically linked Go binary, distributed through Runfile’s public GitHub releases.

The binary’s published SHA-256 is e8c4f1a9b7d3… (full hash in the GitHub release notes and bundled in /verifier/binary.sha256 within this package). Verifying the binary against this hash before running is recommended.

The verifier source is open and licensed Apache 2.0 at https://github.com/runfile/verifier. The binary is reproducibly buildable from source per the build instructions in the repository.

The public key used to sign the manifests in this package is published at:

The published key’s SHA-256 fingerprint is a50325270c83d8f686403c5ffd270ca02d06323d4693d674cc0aa4b91bb2ad1b. The key is bundled in /keys/ within this package; comparing the bundled key to the published key confirms they match.

The --offline flag instructs the verifier to read Sigstore Rekor inclusion proofs from the package’s bundled /proofs/ directory rather than fetching them from the public Rekor instance. This is appropriate for air-gapped audit environments.

If network access is permitted, omit --offline to have the verifier fetch the inclusion proofs directly from https://rekor.sigstore.dev and confirm they match the bundled proofs.

The verifier produces two output files: a PDF report (suitable for attaching to a workpaper) and a JSON report (suitable for ingest into a downstream audit pipeline).

The verifier’s PDF output and the integrity-attestation page of this package (§05) should match. If they do not, the package has been tampered with after capture and the verifier output is authoritative.

If the verifier produces a FAIL result, the JSON report specifies which check failed at which line. Runfile cannot retroactively alter a signed package without producing a meta-root that contradicts the public Rekor entry; any such alteration would be visible to any third party who downloaded the package before the alteration.

The verification depends on the following inputs and nothing else:

• The verifier binary (open source, reproducibly buildable, fingerprint published).
• The public signing key (published at a stable URL, fingerprint published, bundled in the package).
• The package itself (this file and its associated zip archive).
• The Sigstore Rekor inclusion proofs (bundled in the package or fetched from the public Rekor instance).

The verification does not depend on:

• Any service Runfile operates.
• Any credential Runfile holds.
• Any decision Runfile makes after this package is sealed.
• Any continued existence of Runfile as a company.

If Runfile ceases to exist tomorrow, the packages signed today remain verifiable. This is the intended design.

This package is distributed as RF-2026-Q1-04812.zip (size: 4.8 GB compressed, 23.1 GB uncompressed). The accompanying PDF (this document) is the human-readable cover.

The manifest.json at the top level is itself signed and lists the SHA-256 of every file in the package. The package’s integrity, as a whole, can be verified by recomputing this manifest.

For an actual evidence package tailored to your remit (EU AI Act, DORA, SOX, HIPAA, FCA SS1/23, GDPR, or any combination), book a design-partner call at runfile.ai.