Real problems, traced from the symptom to the source to the result. Each paper says what was tested, what failed, and what you can do yourself. Each one is useful even if you never hire us.
FIELD PAPER 01 · VERSION 1.0The site wasn’t broken. The domain wasn’t active yet.
Last tested
2026-11-06
Environment
A new domain moved to a DNS provider; a website ready to be attached to that domain
Sources
The DNS provider’s own status for the domain, read through its API; the release record
Tests
Domain status read twice, nine minutes apart; the site’s full local test suite
Result
Attached and verified from outside once the domain showed active
Corrections
None
Symptom
The finished site could not be put on its public address.
Reality
Every local test of the site passed. Nothing in the site depended on the domain. The failure only appeared at the step that joins the two.
Source
The DNS provider listed the domain as pending. The new nameservers had been set at the registrar but not yet confirmed by the provider.
Test
Read the domain’s status from the provider twice, nine minutes apart. Pending both times. That ruled out a passing glitch and ruled in a state that had to change before anything else could.
Failed line
The first assumption: that the problem was in the site or the release process. Changing either would have spent time and fixed nothing.
Change the check to require only what launch needs, and to fail if a parked feature ever shows something it shouldn’t.
Act
Two edits. Nothing visitors see changed.
Result
Checks pass, and they now guard against fake details appearing instead of demanding real ones too early.
Do it yourself: when a check blocks you, ask which decision it encodes and whether that decision is still the current one. Then fix the record, not the product.
NOTE 01 · VERSION 1.1The people aren’t lost. The doorway is.
People arrive, look around, and leave without doing what they came for. The usual conclusion is that they didn’t really want it. Most of the time they knew exactly what they wanted, and the doorway asked them to understand the building before letting them in.
Method. Stand where a stranger stands. Count what they must read, decide or understand before the first useful act. Move everything that isn’t that act one layer back: still there for anyone who wants it, never in front of the door.
Example. GROK’it’s front screen holds one question, one sentence, four optional doors, a box for the problem, a name and a way to reply, one safety line, and one button. The method, the price, the receipts and the fine print are one layer back.
Corrections. 2026-11-07: version 1.0 said the front screen showed the price in dollars. It no longer does: the price now comes after the problem is understood and scoped. Baton: Make the Next Move.
NOTE 02 · VERSION 1.0A tool can organize the work. It cannot create authority.
A script, an assistant or an automation can plan, check and even act. It is tempting to let it decide too, because it already has the steps lined up.
Method. Before work starts, list the acts that spend money, publish, or can’t easily be undone, and write who decides each one. Let the tool do everything up to that point, then stop and hand over exactly one decision: what it changes and how to undo it.
Example. Twice during GROK’it’s launch the release process stopped short of the public step: once because it will not attach a site without a passing test on record, once because publishing waited for the owner’s explicit go. Both times the work waited for the person.