Blog
5 min read
Turning Homeschool Coaching Into a Bookable Product: International School of America
Jun 12, 2026
A year ago we wrote about guardrails for AI-edited websites — checkpoints, review, the human gate. This is the sequel about what we've learned since, compressed into one sentence: the more an AI produces, the more your safety lives in validators — small, mechanical, opinionated checks at every boundary an artifact crosses. Review catches what's wrong with a draft; validators catch what's wrong with the system that accepts drafts. You need both, and the second one is the one that scales.
TL;DR: AI editing production safely isn't one big safety system; it's many small validators, each owning one boundary: schemas validate generated artifacts before they're accepted, server-side checks re-validate at every public door, domain validators encode hard-won product rules ("headings must be plain text"), and structural graphs refuse to save in invalid shapes. The architecture rule: validate at the boundary the artifact crosses, fail loud with a reason the producer can act on, and write a new check every time an incident teaches you a rule you didn't know you had.
The shift: from gating people to gating artifacts
The original guardrails post assumed the scarce thing was changes — a human or AI makes an edit, the edit gets reviewed, checkpoints make it reversible. That still holds. What changed is volume: when AI drafts forms, documents, pages, and posts all day, review attention becomes the bottleneck — and anything mechanical that review is spending attention on is waste. The answer is a division we now apply everywhere: validators own the mechanical; review owns the judgment. A human should never burn attention noticing a malformed field, a broken reference, or a structural rule violation — a validator caught that before the human arrived, or the system is misbuilt.
A field guide to the validators we actually run
| Boundary | What validates | What it knows |
|---|---|---|
| AI output → system | Schema validation on generated artifacts | The artifact's contract: required fields, types, shapes |
| Public door → storage | Server-side checks on every submission | The definition file, enforced at the boundary |
| Content → publish | Domain validators on posts and pages | Product rules: structure, references, conventions |
| Graph → save | Structural validation on journeys | Graph-shape rules: entries, reachable exits, required timeout branches |
| Write → durable | Read-back verification | The producer's intent, compared byte-for-byte |
Three of these deserve a closer look, because each taught us something general.
Schemas: the contract AI is held to
Everything AI generates around here is an artifact with a schema — a form definition, a page's metadata sidecar, a post bundle. The schema is what makes "AI writes production artifacts" a bounded claim instead of a brave one: generation can be creative; acceptance is mechanical. The artifact validates or it doesn't enter the system, and the error says exactly which field violated what. This pairs with the deepest lever we have — constrained languages and constrained vocabularies shrink the space of invalid things an AI can even produce; schemas catch the remainder.
Domain validators: incidents, fossilized
The most valuable validators we run are the least glamorous: checks encoding product rules we learned the hard way. Our content pipeline's validator is the honest example — among its checks is one that sounds absurd until you know its history: headings must contain plain text only. Why? Because the editor's document model rejects inline elements inside headings, and the failure mode wasn't an error — it was a silently half-imported post. One incident, one regex, zero recurrences. That's the pattern we now reach for reflexively: every incident postmortem ends with "which validator would have caught this?" — and the answer becomes a check with a comment explaining the scar it covers. A validator suite, read top to bottom, is the institutional memory of everything that ever went subtly wrong.
Structural validation: graphs that refuse to be invalid
For artifacts with shape — journey graphs especially — validation goes beyond fields to structure: does every path reach an exit? Does the wait node have its timeout branch? Is the entry wired? The interesting design choice is when this runs: at save, not at run. A journey that would strand users in an unreachable branch is rejected as a draft, with the error pointing at the node — not discovered as a cohort of customers frozen mid-sequence three weeks later. The earlier a structural rule fires, the cheaper its violation; the save boundary is the last cheap moment.
The rules that make validators good
- Validate at the boundary, own the boundary. Each validator guards one crossing — output-to-acceptance, door-to-storage, draft-to-publish. Validators that try to check everything from everywhere drift into nobody's ownership.
- Fail loud, fail specific, fail actionable. "Invalid" is useless to a human and worse for an AI producer — which will retry blindly. "post_settings.tags[2].id: unknown tag" lets either producer fix and resubmit. The error message is the API.
- Make them fast and total. A validator slow enough to skip will be skipped; a validator that samples will miss. Mechanical checks earn their place by being cheap enough to run on every artifact, every time.
- Never auto-fix silently. A validator that quietly "corrects" artifacts is a second producer with no review — the same class of bug as the no-op that reports success. Reject with reasons; let the producer produce.
- Grow the suite from incidents, prune never. Checks are cheap to keep and expensive to re-learn. The absurd-sounding rule is usually the one with the best story.
The stack, assembled
Put the layers together and you get the actual answer to "how do you let AI edit production?" — defense in depth where each layer covers a different failure class: constrained vocabularies shrink what can be produced; schemas gate what's accepted; domain validators enforce the rules incidents taught; structural checks refuse invalid shapes at save; read-back verification confirms what landed; and human review — the original guardrail — spends its scarce attention purely on judgment: is this right, not is this well-formed. The layers are individually humble. The stack is why an AI can draft a form at 9pm Saturday, have it validated, accepted, wired, and verified by 9:01 — and why the human who reviews it Monday is checking the offer, not the plumbing.
Key takeaways
- Validators own the mechanical; review owns the judgment: any attention a human spends noticing malformed artifacts is attention the system failed to spend first.
- Generation is creative; acceptance is mechanical: schemas at the AI boundary make "AI writes production artifacts" a bounded claim — validate or it doesn't enter.
- Domain validators are fossilized incidents: every postmortem ends with "which check would have caught this?" — and the suite becomes institutional memory of everything that went subtly wrong.
- Structural rules fire at save: the graph that would strand users is rejected as a draft with the node named — the save boundary is the last cheap moment.
- The error message is the API: specific, actionable failures let both humans and AI producers fix and resubmit — "invalid" makes an AI retry blindly.
- Never auto-fix silently: a validator that corrects is an unreviewed producer — reject with reasons and let the producer produce.
Frequently asked questions
Doesn't validation everywhere slow the whole system down?
Mechanical checks on structured artifacts are microseconds-to-milliseconds — rounding error against the network hop that delivered the artifact. The performance question worth asking runs the other way: what does a missing validator cost? Our honest accounting says every incident that a one-millisecond check would have prevented cost hours of diagnosis and repair. Validation isn't overhead on the pipeline; it's the cheapest component in it.
How is this different from just having good tests?
Tests check the system's code before deploy; validators check the system's data in production, on every artifact, forever. They're complementary and non-interchangeable: tests can't see the artifact an AI generates next Tuesday, and validators can't verify your logic. The overlap trap is relying on tests for data-shaped risks — the same lesson as our distributed-writes postmortem: production conditions produce artifacts test suites never imagine, so the check has to live where the artifacts actually arrive.
What stops the validator suite from becoming a bureaucracy that blocks everything?
Two properties keep it honest: every check is mechanical (it tests a decidable rule, not a vibe — "headings contain no inline elements," never "content is good"), and every check carries its reason (the comment explaining the incident it fossilizes). Checks that fail those bars don't get added. Judgment calls belong to review, and a validator that tries to encode taste is review with worse manners — that's the line, and keeping it is what keeps producers trusting red as "broken," not "disliked."
Where should a small team start if they're adopting AI editing today?
At the acceptance boundary, with one schema: define what a valid artifact looks like for the one thing AI produces most, validate every artifact against it, and make the failure message name the field. That single gate converts "AI edits sometimes break things" into a list of specific rejections you can read. Then grow exactly the way we did — each incident adds its check — and you'll have a suite shaped like your actual risks instead of a framework shaped like someone else's.
The validator stack ships under everything Faster's AI touches — which is why describing a change is safe enough to be the default. More engineering notes: the engineering blog.