Skip to content

DeterminismSeptember 27, 20261 min read

What a run should leave behind

Every run of a workflow keeps a record: what came in, what each step did, who approved what. It is the difference between trusting a process and checking one.

When a person does a task, they leave traces: an email, a note on the file, a memory of why they did it that way. When a workflow does a task, it leaves exactly what it was built to leave. So we build it to leave a lot.

Every run keeps its receipts

Each run of a Vector & Frank workflow records:

  1. what came in — the invoice, the email, the form,
  2. what each step did with it, in order,
  3. what the judgment step decided, and on what,
  4. who approved anything that went to a person, and when,
  5. the outcome, and what it was billed as.

Why bother

Because the promise is that you can check what it did yesterday. That promise is only as good as the record behind it.

It pays off in three places. When somebody asks why a payment went out, the answer is one click away. When a step starts going wrong, you can see exactly which runs it touched. And when the auditors come round, the workflow is the easiest part of the business to explain.

Trusting a process and checking a process should feel the same. The run history is how they do.

The record is also where improvement starts. Every case the gate sent to a person is a case somebody could teach the workflow to handle next time.

Every article

DeterminismOctober 13, 20262 min read

Where the path ends and judgment begins

Every workflow we build has a line through it: one side is rules, the other is judgment. Drawing that line is most of the design work.

OutcomesOctober 6, 20261 min read

Pay for the invoice matched, not the seat

Software is usually sold by the seat. We bill by the outcome — one invoice matched, one claim checked — because that is what you were paying people for.

Book a call