Hobfolk
Assurance · case study

The rule existed.
The mistake came back anyway.

A site kept drifting on the same handful of details — the wrong address showing up on the wrong kind of page, opening hours out of sync between one section and the next. Writing the rule down didn't stop it recurring. The audit that keeps finding it again is what actually stops it costing anything.

Start a conversationSee the whole crew
You go home. It doesn't.Every promise gets a row and a due dateEvery enquiry answered, not just loggedA 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 dateEvery enquiry answered, not just loggedA 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 story

Codifying the fix didn't retire the problem

A rule that exists in a document and a rule that is actually checked on the live page are two different levels of protection, and only one of them holds.

Across several separate sessions of work on the same live site, the same category of small, specific error kept reappearing: a precise street address meant only for location-specific pages turning up instead in brand-facing copy where it didn't belong, and opening hours drifting out of sync between the homepage, a location page, a contact page and the structured data underneath all of them.

The first time, the fix was applied and the page moved on. By the second occurrence, the fix was a versioned, written rule instead — the exact wording that was and wasn't allowed on which class of page, and the single canonical hours string every surface was meant to match.

The rule did not make the defect stop happening. A later audit found the same violation live again — this time spread across several fields, in the page metadata as well as the visible copy, after the rule had existed for weeks. What catches it now isn't the rule sitting in a document; it's an audit that checks the live page against the rule, every time, regardless of whether anyone remembered it.

The same errors, dated each time they reappeared
The same errors, dated each time they reappeared

Sourced from Hobfolk's own operational record, dated and on file — see the other cases. Client identity is never named; the numbers and the root cause are not softened.

What changed

The permanent fix, not just the patch

01

A recurring defect gets a versioned rule, not just a fix

The second time the same category of error appeared, the response stopped being “fix it” and became “write down exactly what is and isn't allowed, with a number attached.”
02

One canonical value, checked everywhere it appears

Opening hours, addresses and other facts that exist on multiple pages have exactly one correct current value, and every surface is checked against that value, not against each other.
03

The rule existing is not treated as the rule working

A written standard is necessary and not sufficient — this is the whole finding of this case study, stated as plainly as it can be.
04

The live page is checked, not the intended content

The audit reads what is actually rendered on the site, including structured data fields a visitor never sees directly, not just what the content file says it should say.
05

Recurrence is logged with a date, not silently re-fixed

Each time the same defect reappears, it's dated and recorded against the rule it violates — so a pattern of recurrence is visible, not hidden inside quiet fixes.
06

The audit runs on a schedule, not on request

Nobody has to remember to check. The check runs whether or not anyone asked for it.
How it unfolded

The sequence, in order

  1. A specific error appears on the live site

    A detail meant for one type of page turns up on another.

  2. It's fixed, once, and the page moves on

    No standing rule yet — just a correction.

  3. The same category of error reappears

    A second time, in a different but related form.

  4. A versioned rule is written

    Exact wording of what is and isn't allowed, with a canonical value stated once.

  5. The rule doesn't stop it happening a third time

    A later audit finds the same violation live again, across multiple fields, weeks after the rule existed.

  6. The audit, not the rule, becomes the actual safeguard

    Running on a schedule, checking the live page rather than trusting the document.

The limits

What this desk will not do

A case study is not a claim of no limits. The same boundary applies here as on the department page this one came from.

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

If the rule didn't work, why write it down at all?
Because the rule is what the audit checks against — without a written, versioned standard there is nothing precise for an automated check to compare the live page to. The rule and the audit are two different halves of the same fix, and only having one of them is the actual failure mode here.
Isn't a recurring defect just evidence the fix doesn't work?
It's evidence that a rule alone doesn't work as a safeguard on its own — which is exactly why this case study isn't presented as a clean, one-time resolution. The honest claim is that the audit catches the recurrence reliably, not that the recurrence has been made impossible.
How often does the audit actually run?
On a fixed schedule, not on request — so a recurrence is caught within a bounded window rather than sitting live indefinitely until someone happens to notice.
Does this apply beyond addresses and opening hours?
The specific fields are location-and-hours shaped, but the underlying pattern — a fact that exists on multiple pages drifting out of sync with itself — shows up anywhere the same information is meant to be consistent across a site.
The department

This case belongs to the Assurance desk

Assurance

Assurance & verification

Independent proof, taken at the far end, that work which reported success actually happened.

Open the department Case studies

Every case, in one place

Real, dated things that went wrong in the businesses this office already runs, and the fix each one produced.

See all the cases
Two more cases

More from the record

Case study

The calculator that started lying

A tool nobody was checking against the model it was supposed to mirror

Read the caseCase study

The quote that would have lost money

A price below the floor cost of the thing existing at all

Read the case

Which fact on your site exists on more than one page right now?

Tell us what it is, and we'll tell you whether it's the same value everywhere it appears.

Start a conversation Read the method