Agents inside regulated processes, with the controls written down

In a regulated process the outcome is not the only deliverable — the evidence is. Who changed the record, on what basis, who approved it, and can you prove none of it was edited afterwards. An agent that writes directly to the system of record answers none of those questions.

ActionsLedger sits between the agent and the record: deterministic policy decides what is permitted, a named human approves what matters, and each merge produces an append-only entry that commits to the one before it.

[ 01 / 03 ] · WHERE IT BREAKS // without a review layer //sha 4b227w

No demonstrable human in the loop

The process requires a human decision, but the system only records an API call from a service account. There is nothing to show a reviewer.

CONTROL → NAMED APPROVER PER CHANGE

Model output treated as a control

Guardrails live in a prompt, so the same channel that carries untrusted input also carries the rules. Controls have to be code to be testable.

CONTROL → POLICY AS DETERMINISTIC CODE

Mutable history

Records can be updated in place with no retained prior state. Deletion and backdating are indistinguishable from normal operation.

CONTROL → APPEND-ONLY HASH CHAIN

Uncontrolled data residency and retention

Evidence, prompts and diffs accumulate wherever the tooling happens to store them, with no retention window and no tenancy boundary.

CONTROL → SCOPED TENANCY + RETENTION

[ 02 / 03 ] · THE REVIEW LOOP // propose, verify, merge //sha 6b86n2

Define the permitted change surface

Objects, fields, value ranges and allowed transitions are declared as code and version-controlled. Anything outside the declared surface is rejected before review, not after.

Evidence is mandatory, not optional

Every proposed value carries a verifiable citation — document span, message ID, query result — so the reviewer validates a source instead of trusting a summary, and an auditor can re-derive the value later.

Approval with separation of duties

The proposer cannot approve. Approval is attributed to a named person, with the policy verdict they saw, at the version of policy in force at that moment.

Produce the audit artifact automatically

Before/after values, evidence references, policy version and verdict, approver and timestamp — appended once, chained by hash, exportable as the evidence pack for a control review.

[ 03 / 03 ] · POLICY // what auto-merges, what waits //sha d4735e

What a reviewer will ask for

Which changes required human approvalAnswered by the policy version in force at merge time.

Who approved this changeNamed identity on the entry, distinct from the proposer.

What was the record beforeBefore/after snapshot stored with the entry.

On what basis was the value chosenEvidence reference per field, not per change set.

Could the trail have been alteredEach entry commits to the previous one by hash.

How long is this retainedRetention window configured per tenant, with the boundary enforced.

regulated workflow — evidence pack

policy                versioned code, fail closed
evidence              required per field
approver              named, not the proposer
merge worker          sole writer, declared surface only
audit trail           append-only, hash-chained

entry N commits to entry N-1 (sha256)
policy version recorded with every verdict
tenancy and retention enforced per workspace

Automate the work, keep the evidence a regulator would accept.

Policy as code, mandatory evidence, separation of duties and an append-only trail — produced as a by-product of doing the work.

Start for free All use cases