How this site works

The AI policy says what AI is and is not used for here. This page shows the working: the tools, where a person sits in the process, what the automated checks check, and what they cannot.

What it is built with

The site is a Next.js application hosted on Vercel, with listings and builder records in a Supabase database. Research and first drafts are produced by scripted agents that call Claude with web search, then write their output to a review file rather than to the site.

How a listing gets here

1. A candidate is found from public sources — a business listing, a map result, a builder's client list.
2. A research agent gathers what it can against named public sources and produces a structured record: location, format, heat source, booking method, session type.
3. That record goes into a review queue. It is not on the site at this point and is not in the live database.
4. A person reads it, corrects it, or drops it. Applying an approved record is a separate, manual step.

The important part is the gap between steps three and four. No agent writes to the live database. Research and publication are different steps, and the second one is done by a person. Records that never get reviewed simply never appear.

How a guide gets written

Topics come from what people actually search for, not from a content calendar. A first draft is written to the site's editorial rules, then facts are checked against primary sources — legislation as enacted, official guidance, published prices — rather than against other AI output, which is how errors get laundered into looking like consensus. Guides carry a named byline because someone has to be answerable for them.

What the checks check

On every change:

• Types, linting and the automated test suite all run as part of the build itself. If any of them fail the build fails, no new version is published, and the site carries on serving the last good one. This was checked the only way worth checking it: by deliberately breaking a test and confirming the build stopped before it produced anything.
• A contract test runs against the live site and checks the things that quietly break — canonical URLs, the sitemap, redirects, structured data. That test is itself tested, by a self-check that deliberately feeds it bad input to prove it can still fail. A check that cannot fail is not a check, and the only way to know the difference is to try to break it.
• Search quality is measured against a fixed set of questions with known good answers, so a change to how search works can be compared against something rather than judged by feel.

What none of this guarantees

The checks above confirm that a page is well formed and that a claim has a source behind it. They cannot confirm that a sauna is still open this week, or that its prices have not changed since someone looked.

• Every listing shows when it was last checked, and the verification mark only stands while that check is current. When it goes out of date the mark goes, rather than sitting there implying something that is no longer true — see how we check listings.
• Nobody has visited every sauna in the directory. Nothing here describes a visit that did not happen, and where a first-hand account exists it is clearly one person's.
• Things still get through wrong. When they do, the corrections policy says what happens, and the fastest way to trigger it is to write in.

Why any of this is public

A directory that uses AI and stays quiet about it is asking readers to take its accuracy on trust. Setting out the method is a way of being checkable instead: if the process described here is weak, that is now something a reader can see and challenge, rather than something they have to guess at.

The longer engineering account of how this site is built and run — written for people interested in the method rather than in saunas — is at mylesmellor.co.uk.