Hobfolk
Department 07 · Assurance

Not the report.
The far end.

One desk here exists purely to disbelieve the others. It checks the thing that actually matters — the recipient’s inbox, the live page, the carrier’s own record — and never accepts a log, a receipt or an exit code as proof that something happened. It comes with every plan.

You go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passA desk per department, one address eachNothing is sent that a human cannot read backThe folder exists before you price itYou go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passA desk per department, one address eachNothing is sent that a human cannot read backThe folder exists before you price it
The case for it

Assurance & verification

Unverifiable is never a pass.

Every failure worth remembering reported success while it was failing. A message that returned an id and never arrived. A deploy that exited zero over an unchanged page. A watcher that ran flawlessly for six weeks and could not see the thing it was watching.

That is not a quirk of automation, it is its default. A process reports on itself, and a process reporting on itself is the one witness with a reason to be wrong. So this desk never asks the doer. It goes and looks: the actual inbox, the actual live page as a visitor loads it, the actual carrier scan.

It returns pass, fail, or unverifiable. Unverifiable is not rounded up to a pass — it means the check could not be run, which is exactly the state in which the expensive failures live. A fail reopens the job automatically rather than filing a note in a report nobody opens.

Every failure worth remembering reported success while it was failing
Every failure worth remembering reported success while it was failing
The boardroom

“Never mark your own work”

Margaret Lisle · Head of Quality & Assurance · 1:15

The rule the whole company runs on: the party that did the work never marks it. Trust is not a feeling, it is an audit trail.

Captions on · the sound is worth it

What the desk does

Six things, every day, without being asked

Take the whole desk or one line of it. Everything below is included in the department retainer. None of it is an extra.
01

A claim, for every unattended action

Anything that runs without a person watching states plainly what it says it did, in a form somebody else can test. An action with no testable claim is not finished.
02

Checked at the far end, never from the log

A send is verified in the recipient’s inbox, not from a message id. A deploy is verified by loading the live page the way a visitor loads it, cache and all. A dispatch is verified by a carrier scan, because a bought label is not a movement.
03

Run by a desk with no stake in it

The one that checks is never the one that did it. A desk that both does the job and marks it is not checking anything, and it is the most common shape of assurance theatre there is.
04

Three verdicts, and only three

Pass, fail, or unverifiable. A check that cannot be run is not a quiet pass, and an exit code is not a verdict — a watcher that runs perfectly while blind exits zero every time.
05

A fail reopens the job

Automatically, with an owner and a date, in the same sweep. Not a line in a weekly summary that gets read the following Tuesday, if at all.
06

The incident record, uncurated

When something does go wrong, what it cost is written down and turned into a numbered test, so the same failure has to be new to happen twice. Failures that touched your work are reported to you.
Off the bench

Two things we got wrong, before the client saw them

The only corner on this site showing work that was withdrawn. Each pair is a superseded version beside the one that replaced it — caught here, not on site, and not by the client.

Withdrawn — the geometry was wrong

Built and rendered as a 4×4×4 stack. The puzzle it has to be is 3×3×3, so this version is not the product — it is a different object that happens to look like it. Caught in review, before it was shown.

Issued — twenty-seven modules, seven pieces

The corrected cube, with a person in frame for scale. Same brief, same day; the difference is that somebody checked the geometry against the puzzle instead of against the last render.

Withdrawn — the proportion was wrong

A handsome object, and not the one specified: the head is too deep and too short for the dimensions on the sheet. A visual that quietly disagrees with the drawing is worse than no visual, because the client believes the picture.

Issued — rebuilt to the dimensioned sheet

480 across, 152 high, drawn and then modelled to those figures rather than to the eye. The render and the drawing now say the same thing.

On the record

This desk, already at work

The real cases this desk has been through, the guide to its most-asked-for document, and anything you can try before you talk to anyone.
Depth

What this desk knows

One body of knowledge, and it is an awkward one: how to establish that something happened when the only thing volunteering to tell you is the thing that did it.

What a claim is

  • Every unattended action produces a claim with a runnable check — stated in advance, in a form somebody else can execute without being in the room.
  • The check is run by a desk with no stake in the answer. The one that did the work never marks it.
  • An action that cannot produce a testable claim is not shipped as autonomous. It keeps a person on it, and we say which ones those are.

Where a check is run

  • A send: in the recipient’s own inbox, and for a new domain, in the delivered message’s authentication result — never from a message id, and never from an intra-tenant message, which carries no such header at all.
  • A deploy: by loading the live page the way a visitor loads it, cache and all. A stable filename plus a long cache is how a shipped fix reaches nobody for a week.
  • A dispatch: on the carrier’s own scan. A bought label is a purchase, not a movement, and every channel marks it dispatched at the purchase.
  • A watcher: by putting something in front of it that it must see. Proving it ran is not proving it can see.

The three verdicts

  • Pass, fail, and unverifiable. Three, not two, because the failures that cost the most live in the third.
  • Unverifiable is never a pass. It means the far end gave no evidence either way, and it is reported as exactly that.
  • An exit code is not a verdict. A watcher blind for six weeks exits zero every single run, and a guard that silently skips its own test is worse than no guard.
  • A fail reopens the job automatically, with an owner and a date, in the same sweep — not a line in a summary that gets read on Tuesday.

The record

  • Every incident written down with what it cost, and converted into a numbered test on a checklist, so the same failure has to be new to happen twice.
  • The record is not curated. Failures that touched your work are reported to you with the cause, not summarised into a colour.
  • You can run any of it yourself, at any time, without telling us. A system that only passes when it knows it is being watched is not a system.

This is the unusual column of the whole company. Most automation reports its own success and is believed. Ours is disbelieved on principle, by something that did not do it.

The run of it

How a job moves through

  1. The work is claimed

    Whatever ran states plainly what it says it did.

  2. A check is written

    Runnable by someone else, against the far end, not the log.

  3. It is run

    By a desk with no stake in the answer.

  4. A verdict is returned

    Pass, fail, or unverifiable.

  5. A fail reopens it

    Automatically. Not a note in a report nobody opens.

  6. It becomes a test

    So it has to be a new failure next time, not the same one.

Where we stand

What we are liable for, said plainly

Most suppliers bury this. We would rather you read it now than find it in a schedule after something has gone wrong.

Our financial liability is limited to the implementation fees paid for the work in question. We do not underwrite your commercial outcomes, and we do not carry the consequential loss of a system we operate on your behalf. Any supplier who tells you otherwise at this price is either not reading their own contract or not intending to honour it.

That is only half a position, though, and the other half is the part that matters. A cap on liability is worthless to you if you cannot tell whether the thing is working. So the trade we offer is this: we limit what we owe, and in exchange we make the system provable by you.

Professional indemnity and public liability cover appropriate to the engagement is put in place and confirmed in writing before work starts, and the certificates go into your tender pack. The cap above is contractual and sits in the engagement agreement, in clear English, in the same size type as everything else.

What “provable by you” means concretely

  • Every automated action produces a check you can run yourself. Not a report we write about ourselves — a check, against the far end, that you or your auditor can execute without us in the room.
  • Your directors and stakeholders get their own access to the verification layer and the incident record. Not a filtered dashboard: the same view we use.
  • The incident record is not curated. Failures that affected your work are reported to you with what happened and what it cost.
  • Nothing is a black box. Every rule the system follows is written down in language a person can read, and the rules are yours.
  • You can test it adversarially, at any time, without telling us. We would encourage it. A system that only passes when it knows it is being watched is not a system.
The limits

What this desk will not do

Every department has a written boundary. A service that claims no limits has simply not found its own yet, and you will find it for them.

Where this desk stops

  • Verification does not fix the work. Deliberately. A desk that both does the job and marks it is not checking anything — a fail goes back to the desk that owns it.
  • It does not audit your accounts and it does not certify anything. It establishes that a specific action happened at the far end. That is a narrower claim than an audit and we will not let it be read as a wider one.
  • It cannot verify what leaves no trace. Where a system gives no far-end evidence, the verdict is unverifiable and stays unverifiable — we will tell you that rather than manufacture a check that only proves our own code ran.
Questions

Asked before, answered here

Who verifies the verifier?
The checks are runnable by you. Anything the assurance desk claims, you can re-run yourself, which is the only definition of verification worth having.
What does “unverifiable” actually mean in practice?
That the check could not be run — the far end gave no evidence either way. It is reported as its own verdict and never quietly counted as a pass, because that is precisely the state the expensive failures live in.
Is this not just monitoring?
Monitoring watches a system and reports what the system says. This checks the outcome from outside the system, on the assumption that the system is lying — including about whether its own monitoring can see anything.
Can we see the failures?
Yes. The incident record is yours and it is not curated.
What about GDPR?
Data is processed under a written agreement, scoped per department, and the privacy notice sets out recipient categories and transfers. See the privacy notice for the detail.
Next department

Logistics & dispatch

Then getting the thing to where it is going.

Open Logistics

What in your business reports success without anyone checking?

Tell us, and we will say whether this desk fits. A no is quicker for both of us. It comes with every plan, and on its own it is from £1,450 a month, thirty days' notice either way, and the first month is a paid trial.