How to Add a Schema-Aware AI Field Validator in Sanity

Your content model says a product description is "150 to 300 words, neutral tone, no competitor names, no unverified medical claims." Then an editor pastes a block generated by an LLM, it reads well, it passes the character-count check, and three weeks later legal finds a comparative claim buried in paragraph two. The failure mode is not that AI writes badly. It is that most validation stops at data types and required fields, so nothing in the pipeline actually reads the meaning of the text against the rules you care about. Length is checked; intent, tone, and policy are not.

Sanity is the AI-native content platform, an intelligent backend where validation can be as smart as the content it governs. Because the schema, the editor, and the delivery layer share one foundation, an AI field validator is not a bolt-on script. It runs where editors work, understands the field it is checking, and blocks or flags content before it ships.

This guide shows how to add a schema-aware AI field validator in Sanity: what "schema-aware" buys you over a regex, how to wire the check into custom validation and Functions, and how to keep the whole thing governed and reviewable rather than a black box editors learn to ignore.

Why length and type checks miss the failures that hurt

Traditional CMS validation answers structural questions. Is this field a string? Is it under 300 characters? Is the slug unique? Does the reference point at a real document? These checks are fast, deterministic, and genuinely useful, and they catch a real class of bugs. What they cannot do is read a paragraph and decide whether it violates a policy that only exists in prose: no comparative claims, no promises about outcomes, no personally identifying detail, no tone that reads as legal advice.

The gap widens the moment AI enters the editorial loop. When a human writes a product description, they carry the brand's guardrails in their head. When an LLM drafts it, those guardrails live only in the prompt, and prompts drift, get truncated, or get overridden by a helpful model that decided a comparison would be persuasive. The output can be fluent, on-length, and perfectly typed while still breaking a rule that matters to legal, compliance, or brand. Structural validation sees a valid string and waves it through.

A concrete example: a supplements retailer allows editors to generate FAQ answers. The schema requires 40 to 120 words. An LLM produces a 90-word answer that implies a product treats a condition. Every structural check passes. The claim is a regulatory problem. The only validator that would have caught it is one that understands both the field's purpose and the rule expressed in natural language. That is the category of check a schema-aware AI validator is built to run, and it is why enterprises are moving validation up from the data type to the meaning.

What 'schema-aware' actually means for an AI validator

"Schema-aware" is the difference between a validator that sees raw text and one that knows what it is looking at. In Sanity, your content model is not a loose collection of fields; it is a typed schema that describes every document, every field, its role, its constraints, and its relationships. A schema-aware validator reads that context before it judges the content. It knows this string is a legal disclaimer and not a blog title, that this field belongs to a product in a regulated category, and that a sibling field already carries the SKU it must not contradict.

That context changes the quality of the judgment dramatically. A generic "check this text for policy violations" prompt has to guess what the text is for. A schema-aware check can say: this is the shortDescription of a document of type medicalProduct, the house rule for this field is no therapeutic claims, and here is the productName and category it must stay consistent with. The model is no longer grading an anonymous paragraph. It is grading a specific field against the exact rules that field is subject to.

This is where Sanity's architecture does the heavy lifting rather than a plugin bolted on top. Agent Actions are schema-aware by design: they operate against your typed content model, so an LLM-driven validate step receives the field, its type, and its constraints as first-class inputs. You are not serializing a document into a prompt and hoping the model infers the structure. The structure is the input. That is the practical meaning of AI being wired into the data model instead of stapled to the side of it, and it is what makes the validator's output trustworthy enough to gate a publish.

Wiring the validator into custom validation in the Studio

The most immediate place to add an AI check is where editors already feel validation: inside Sanity Studio. Sanity fields accept custom validation rules, functions that receive the field value and the surrounding document and return either true or an error message. This is the same mechanism you use for "end date must be after start date," extended so the rule is evaluated by a model rather than a comparison operator.

The pattern is straightforward. Your custom validation function assembles the field value plus the relevant schema context (the field's name, its documented policy, and any sibling fields it must stay consistent with) and asks the model a narrow, answerable question: does this text violate the stated rule, yes or no, and if yes, why. The function returns the model's verdict as a validation message. The editor sees a red underline and a plain-language explanation right next to the field, in the same UI that already flags a missing title. No context switch, no separate dashboard, no waiting for a nightly job to email them.

AI Assist lives in this same in-editor layer and is worth naming here, because the goal is a loop, not a wall. When the validator flags a comparative claim, AI Assist can offer to rewrite the block in the approved neutral voice, so the editor's next action is one click rather than a rewrite from scratch. Validation that only says no trains editors to route around it. Validation that says no and offers a compliant rewrite keeps them inside the governed workflow. Keep the check narrow and deterministic in its question so the same input produces the same verdict; a validator editors cannot predict is a validator they stop trusting.

Enforcing the check server-side with Functions

In-editor validation is the fast feedback loop, but it is not the enforcement boundary. An editor can dismiss a warning, an integration can write to the dataset over the API, and a bulk import can bypass the Studio entirely. For anything that must not ship, the check has to run server-side, on content changes, where no client can skip it. In Sanity that layer is Functions: serverless hooks that fire on content events such as publish.

The enforcement pattern is a validate-on-publish Function. When a document of the governed type is published, the Function runs the same schema-aware AI check the Studio ran, this time as the authority rather than a hint. If the content passes, publish proceeds. If it fails, the Function can block the transition, revert the change, or route the document into a review state and notify the owner. Because Functions run in Sanity's infrastructure and react to Content Lake events, the check applies uniformly whether the content came from an editor, an API integration, or an automated pipeline. The rule lives with the platform, not with each client that happens to remember to call it.

This two-layer approach maps cleanly onto how enterprises think about controls: a helpful check in the editor for speed, and an enforced check in the pipeline for safety. The same policy definition can feed both, so the editor's warning and the publish gate never drift apart. That consistency is the point. A validator that is advisory in one place and authoritative in another, with two different rule sets, is how contradictions and gaps creep in. One schema-aware definition, enforced at the boundary and surfaced in the editor, keeps the guarantee honest.

Keeping AI validation governed, reviewable, and safe

A validator that makes automated judgments about content is itself a governance surface, and treating it as one separates a durable system from a demo. Three questions decide whether an AI validator survives contact with an enterprise: can you see why it decided what it decided, can a human override it, and can you prove the whole thing to an auditor. If the answer to any is no, the validator becomes a liability the first time it blocks something it should not have, or waves through something it should not have.

Sanity is the AI Content Operating System, an intelligent backend designed to keep AI workflows inside the editorial loop rather than off in an opaque service. Content Releases let you stage AI-touched changes and review them as a set before they go live, so a batch of generated descriptions gets a human pass before publish. Roles & Permissions decide who can override a validator's verdict, and Audit logs record who did, giving compliance a trail rather than a shrug. The validator's decisions live in the same governed environment as the content, not in a black box editors learn to ignore.

The posture questions matter too. Sanity carries SOC 2 Type II, supports GDPR, and offers regional hosting and data residency, with a published sub-processor list covering the services in the pipeline, which is the baseline a regulated team needs before it lets a model gate a publish. The reframing this guide is arguing for lands here: an AI field validator is not a clever script you add and forget. It is a control. Built on a platform where the schema, the editor, the enforcement layer, and the audit trail share one foundation, it stays trustworthy at the scale where manual review stopped being possible.