Process engine · phase 2

Get your hours back.
Keep the proof.

Rutter runs your regulated processes, keeps a hash-chained ledger anyone can recompute and drafts its own improvements. A person approves every change.

What we will not show you

No invented logos · no invented quotes · no invented stats. Rutter has no customers yet, so this page earns trust with arithmetic you can recompute.

01 — The timesheet

Where your weeks go.


The mechanism retires each of these tasks. Each is tied to a shipped capability, and none is rolled into an invented savings number.

  1. Chasing evidence6 h/wk
  2. Rebuilding audit trails3 d/audit
  3. Writing the runbook again2 wk/qtr
  4. Proving who approved what4 h/incident
  5. Updating the SOP after the fact∞

Deleted by: evidence binding

Evidence attaches itself to the requirement.

Steps declare what they need. A submission attaches to a requirement, verification binds the result to the step, and an unbound document satisfies nothing. The chase becomes a query.

evidence.submittedevidence.verified · checks: 11

Deleted by: the ledger

The audit trail is the execution record.

Every run writes hash-chained, append-only events as it happens. There is nothing to rebuild afterwards: the trail exists because the work ran, and anyone can recompute it.

fb82d723…aa9c1faa…7b240e00…

Deleted by: compile targets

One revision, five documents, zero rewriting.

A published revision compiles deterministically into runbook, checklist, decision tree, training guide and agent instructions, with no model call anywhere in the compiler.

runbookchecklistdecision-treetrainingagent

Deleted by: recorded approvals

Who approved what is a ledger event.

Approvals record a distinct actor, enforced down to the database: the engine rejects an approval from the actor who performed the step. The answer is a lookup, not an interview.

approval.recorded · sod: distinct-actor

Deleted by: the proposal loop

The SOP updates from its own evidence.

Drafted changes cite exact ledger events and may only tighten a control. No machine can publish one; the guard is enforced three layers down, to the database.

cites (run, seq, hash)no-auto-publish

02 — The ledger

A run, as the ledger stores it.


A complete vendor-onboarding run. Each row's hash is computed from the previous row's hash concatenated with that row's payload.

# Event Prev Hash
01run.started00000000…fb82d7238c2bfd6a
02step.startedfb82d723…aa9c1faa27cd7576
03evidence.submittedaa9c1faa…7b240e002244071f
04evidence.verified7b240e00…3b81ee73fd0b27d3
05tool.started3b81ee73…e9c23ac8b445dff0
06tool.succeedede9c23ac8…d6458bd14c78d631
07approval.recordedd6458bd1…26369cdbcd51a547
08run.completed26369cdb…962ac5342796e340
Recompute Them Yourself

Telling you to check and not handing you the inputs would be the same assurance-without-evidence this page argues against. Here are the exact payloads and the script. Paste it into Node.

const c = require('crypto');
const payloads = [
  '{"kind":"run.started","process":"vendor-onboarding","rev":7}',
  '{"kind":"step.started","node":"collect-w9"}',
  '{"kind":"evidence.submitted","requirement":"w9-form"}',
  '{"kind":"evidence.verified","checks":11}',
  '{"kind":"tool.started","op":"sanctions.screen"}',
  '{"kind":"tool.succeeded","receipt":true}',
  '{"kind":"approval.recorded","sod":"distinct-actor"}',
  '{"kind":"run.completed","outcome":"approved"}',
];
let prev = '0'.repeat(64);
for (const p of payloads) {
  prev = c.createHash('sha256').update(prev + p).digest('hex');
  console.log(prev.slice(0, 16));
}

It prints the eight hashes in the table, in order. If it does not, this page is wrong and we would like to know.

Verification is a walk down the chain.

Checking the ledger means recomputing each link and comparing. A break identifies the first event whose recorded hash disagrees with its recomputed value, which bounds the damage: everything before that index is intact.

The chain detects modification. It does not, by itself, prevent it; see what this does not claim.

03 — The loop

Hours, then weeks, then months.


The process improves from its own evidence. Each stage of the loop retires a different scale of drudgery.

04 — Limits

What this does not claim.


It is not certified.
There is no SOC 2, ISO 27001, PCI DSS, or HIPAA attestation for Rutter, and none is claimed here.
Tamper-evident, within a stated threat model.
The chain detects modification by a party that cannot also rewrite the verification path and every stored digest. It is not a defence against an operator with full control of the storage and the verifier. Anyone claiming otherwise about any hash chain is overselling it.
It is phase two.
The ledger, evidence verification, two-phase tool execution, approvals and separation of duties, tenant isolation, compile targets, aggregation, and the proposal loop with its no-auto-publish guard are built and gated. Autonomy beyond human-approved proposals is not built, deliberately.
It is not deployed.
Rutter has run against a local stack and its own test suites. It has not run in production, and it has not carried anyone's regulated workload.

05 — How it is built

Every phase has to fail on purpose first.


A gate that has never failed proves nothing. Each phase ships negative controls: deliberate defect patches applied to real source, which the suite is required to catch.

If the suite passes with the defect in place, the gate fails, because the tests aren't watching what they claim to watch. Each phase also emits a machine-written evidence file; a claim without a corresponding entry in it does not count as met.

If you evaluate this kind of system,
bring your hardest questions.

Rutter is pre-production and pre-attestation. The most useful conversation right now is with someone who'll try to break the threat model.