AI Amplifies Whatever It Finds
Think about meter in poetry. Nobody hears iambic pentameter — but take it away and the words stop landing. When I have fears that I may cease to be is easy to remember because the structure carries it.
A content model is meter for an institution. It's the invisible structure that makes everything else cohere — programs, people, policies, publications, all typed and related. Nobody looks at the schema. But everybody notices when it's absent: the admissions page contradicts the program page, the newsletter contradicts both, and the AI cheerfully synthesizes all three into a confident wrong answer.
AI seeks salience the way electricity seeks ground — it follows the path of least resistance. If that path leads through structured, validated, relational data, the AI surfaces what's actually true. If it leads through a scatter of PDFs and page-builder layouts, it surfaces whatever pattern is most statistically convenient. Contradictions compound as quickly as coherence. And at machine speed, manual correction can't keep up.
This brief describes an architecture for organizations facing that gap. It assumes the reader already knows AI matters and is deciding what to do about the content underneath.
Decision Context
Three constraints shape every version of this conversation, regardless of sector:
- Time pressure. Leadership has announced an AI initiative. The organization needs visible progress, not a two-year platform migration.
- Governance exposure. Accreditation, compliance, or regulatory frameworks require that institutional data be auditable, consistent, and attributable. AI-generated content with no provenance is a liability.
- Organizational capacity. The team managing content today is not a development shop. Whatever gets built must be maintainable by editors, not only by the person who architected it.
Who's in the room, and what each one actually needs:
- Executive sponsor — Needs a credible path from current state to "AI-ready" that they can explain to a board. Cares about risk, timeline, and whether this locks them into a vendor.
- Content / communications lead — Needs to know their workflow won't break. Wants to publish without calling a developer. Suspicious of platforms that require technical skills to do basic tasks.
- IT / operations — Needs to know how this integrates with existing systems (identity, file storage, email). Cares about security, SSO, and who maintains what.
- Compliance / governance — Needs audit trails, role-based access, and content that can be traced to its source. Will ask: "If the AI generates something wrong, how do we catch it before it's published?"
Discovery & Workshops
Before proposing architecture, map the territory. Discovery has three objectives: inventory what exists, identify who owns what, and surface the constraints nobody mentions in the kickoff meeting. That third one usually determines the timeline.
Duration: 90 minutes. Attendees: Content leads, web team, one IT representative.
Agenda:
- Inventory all content channels (websites, intranets, apps, documents, social accounts). Map which team owns each.
- Identify content that is duplicated across channels — same information maintained in multiple places with no single source of truth.
- Flag content that is "locked" — trapped in a visual builder, a PDF, or a system with no API access.
Artifact produced: Content landscape map (channels × content types × ownership). This becomes the baseline for the content model.
Duration: 60 minutes. Attendees: Compliance lead, executive sponsor, IT security.
Agenda:
- Document regulatory and accreditation requirements that affect content (retention, attribution, accessibility, language).
- Map approval workflows: who can publish? Who reviews? What requires sign-off?
- Identify data that must not be exposed via API or AI (PII, internal financials, personnel records).
Artifact produced: Governance requirements matrix. Feeds directly into role-based access design and content validation rules.
Duration: 60 minutes. Attendees: Executive sponsor, content leads, IT.
Agenda:
- Define what "AI-ready" means for this organization — not abstractly, but in terms of specific use cases leadership actually wants (e.g., "answer parent questions from website content," "generate newsletter drafts from published articles").
- Assess which use cases are feasible with structured content and which require capabilities that don't exist yet.
- Establish the AI governance position: what gets automated, what gets human review, what stays manual.
Artifact produced: AI use-case matrix (use case × feasibility × governance requirement × phase). This becomes the roadmap for Phase 3.
After discovery, the executive sponsor decides: proceed with the phased plan, adjust scope, or stop. This is a genuine gate — not a formality. If the content landscape audit reveals that the organization's actual problem is editorial capacity rather than architecture, the honest recommendation is to solve that first.
Proposed Solution Pattern
The architecture follows a principle: content as infrastructure, not content as pages. A "program" is not a web page — it's a data object with a name, a description, a director, a department, a schedule, and a status. That object gets rendered as a web page, consumed by an API, queried by an AI agent, or exported to a report. The content is authored once and structured once. Expression is a downstream concern. This is the meter — the invisible structure that determines whether institutional expression is coherent or accidental across every channel that touches it.
A minimal enterprise content model for an organization managing programs, people, and publications:
- Page — Hierarchical (parent/child). Rich text body. SEO metadata. Used for static institutional content (About, Mission, Policies).
- Article — Timestamped. Author reference. Tags. Source tracking (manual, syndicated, external). Supports editorial workflow flags.
- Program — Typed (academic, operational, community). Description, lead person reference, status, related documents.
- Person — Name, role, department reference, contact, biography. Referenced by programs, articles, and pages.
- Department — Organizational unit. People belong to departments. Departments can be nested.
- Event — Date range, location, category, description. Can reference programs and people.
Every content type includes an SEO object (meta title, description, social image) and a governance object (last reviewed date, review owner, publication status).
- Validation rules are defined in the schema, not enforced by convention. A program must have a lead person. An article must have a publish date. A page must have a meta description. If the rule is important enough to exist, it's enforced at the data layer.
- Editorial flags mark content that needs human attention:
DATE_NEEDS_REVIEW,IMAGE_MISSING,BODY_NEEDS_REVIEW. These are queryable — you can surface every piece of content that isn't ready for production with a single API call. - Role-based access separates who can draft, who can publish, and who can modify the schema. Editors publish content. Developers define structure. Administrators manage access. These boundaries are enforced by the platform, not by agreement.
- Development — Schema changes, new content types, integration testing. Safe to break.
- Staging — Content preview with production data. Editors can see changes before publish. QA runs here.
- Production — Live content served via API. Deployments are explicit (CLI or CI), not git-triggered. No surprises.
Content and schema are versioned independently. A schema change doesn't require a content migration unless it introduces a breaking field change — and breaking changes are flagged at build time, not discovered in production.
Phased Implementation
Three phases, each delivering standalone value. The organization can stop after any phase and still have a working, improved system. This is not a roadmap that requires Phase 3 to justify Phase 1.
Goal: Replace the existing website with a structured content system. Visible improvement. Editors can publish without developer help.
- Define core content types: Page, Article, Person, Department.
- Migrate existing website content into structured documents. Programmatic extraction where possible; manual entry where content is too messy to automate.
- Build a reference frontend that renders all content types. Semantic HTML, JSON-LD structured data, responsive, accessible.
- Train editors on the content studio. Publish workflow: draft → review → publish.
Delivers: A working website backed by structured data. Content is now queryable via API. Editors are self-sufficient for routine updates.
Goal: Extend the content model to cover operational data. Content becomes institutional infrastructure, not just a website.
- Add operational content types: Program, Event, Media Gallery, internal documents with access controls.
- Build relationships between content types. A program references its director. A director belongs to a department. An event is associated with a program. These relationships are queryable.
- Implement workspace automation: when a new program is created in the content studio, downstream systems (file storage, notifications, directory listings) update automatically.
- Establish governance workflows: content review schedules, editorial flags, audit logging.
Delivers: A single source of truth for institutional data. Multiple systems consume the same content. Operational workflows are automated where the ROI is clear.
Goal: Enable AI capabilities that are grounded in structured institutional data — not internet-trained guessing.
- AI is not just the consumption layer — it's a discovery agent. An AI that can traverse structured relationships doesn't just answer the question asked; it surfaces questions worth asking. "Which programs have no director assigned?" "Which published pages reference a policy that was updated six months ago?" These aren't reports someone requested. They're things the structure makes visible.
- AI-assisted content drafting uses the schema as a constraint. The AI generates a draft article; the schema validates that required fields are present; a human editor reviews before publish.
- All AI-generated content is flagged with provenance metadata: source query, model used, human reviewer, publish date. If something is wrong, the audit trail shows exactly where it came from.
- AI capabilities are scoped to use cases validated in discovery (Workshop 3). No open-ended "AI does everything" — each use case has defined inputs, outputs, and governance.
Delivers: AI that amplifies institutional coherence rather than institutional confusion. Every AI-generated output is traceable, reviewable, and correctable.
Proof of Concept Plan
A time-boxed PoC validates the approach before organizational commitment. The PoC covers Phase 1 scope with a deliberately narrow content set.
- Content types: Article and Person only. Two types are enough to demonstrate typed content, references between types, and editorial workflow.
- Content volume: 5 articles, 3 people. Enough to demonstrate queries and relationships. Not enough to confuse the PoC with a migration project.
- Studio configuration: Minimal content studio with custom schema, validation rules, and preview. Editors can create, edit, and publish articles that reference people.
- Frontend: A single-page prototype that renders articles with author information, demonstrating API-driven content delivery. Semantic HTML, responsive, accessible.
- One integration pattern: Demonstrate content consumed by an external system — e.g., a structured data endpoint (JSON-LD) that an AI agent or search engine can parse without executing JavaScript.
The PoC passes when all of the following are demonstrably true:
- An editor can create and publish an article in the content studio without developer assistance. The article appears on the frontend within 60 seconds of publish.
- An article references a person, and changing the person's name in one place updates it everywhere that person appears. Single source of truth is verifiable.
- Validation prevents incomplete content. An article without a title or publish date cannot be published. The error message tells the editor exactly what's missing.
- The content API returns structured data that an external system can consume. A GROQ query returns articles with dereferenced author data in a predictable JSON shape.
- The frontend renders semantic HTML with correct heading hierarchy, JSON-LD structured data, and no JavaScript dependency for content access. An AI agent reading the page source gets the same information as a human reading the rendered page.
Migration of existing content. SSO integration. Custom design. Performance optimization. Multi-environment deployment. These are Phase 1 scope items that belong in a project plan, not a proof of concept. The PoC answers one question: does the architecture work for this organization's content?
Risk Controls
Every risk below has been observed in real implementations. These aren't hypotheticals.
Risk: AI-generated content is published without attribution, and an error is traced to "the AI" with no audit trail.
Control: All content carries provenance metadata: source (manual, imported, AI-assisted), author, creation date, last editor, publication status. AI-assisted content is flagged at the schema level — not by convention, but by a required field that cannot be bypassed.
Risk: An AI agent generates plausible but incorrect institutional information — wrong program descriptions, outdated contact details, invented policies.
Control: AI agents query the structured content API, not the open internet. Responses are grounded in typed, validated data. If the data doesn't exist in the content layer, the agent says so rather than inventing an answer. Schema validation ensures that the data the agent queries has been through editorial review.
Risk: Internal content (draft documents, personnel data, financial information) is exposed through the public API or consumed by an AI agent without access controls.
Control: Content types are separated by visibility: public, internal, and restricted. API tokens are scoped to visibility levels. The public API cannot return restricted content regardless of the query. Role-based access in the content studio controls who can create, edit, and publish each content type.
Risk: Over time, content editors create inconsistent categories, tags, and classifications. The content model degrades into a folder structure with extra steps.
Control: Taxonomies are defined in the schema as controlled vocabularies (enums or reference types), not freeform text fields. Adding a new category requires a schema change, which requires a code review. This is intentional friction — it prevents the "miscellaneous" category from swallowing everything else.
Risk: The architecture is sound but nobody uses it. Editors revert to email attachments and shared drives because the content studio feels unfamiliar. This is the hardest problem on the list, and the one with the least to do with technology.
Control: Knowing the right architecture is the straightforward part. Finding the approach that leads to adoption — reading the room, adjusting language, meeting people where they are rather than where the schema says they should be — that's the actual work. Phase 1 includes hands-on editor training with their actual content, not demo data. The PoC validates editorial usability before organizational commitment. Phased implementation gives editors an on-ramp rather than an ultimatum. And when the editors need a simpler publishing experience, that takes priority over schema purity.
Appendix: Sanity Implementation Examples
Synthetic examples using Sanity Studio v3 schema syntax and GROQ query language. These demonstrate patterns, not production code.
Defines an article with typed fields, a reference to an author, and validation rules. Uses defineType and defineField from the sanity package (v3).
import {defineType, defineField} from 'sanity'
export const articleType = defineType({
name: 'article',
title: 'Article',
type: 'document',
fields: [
defineField({
name: 'title',
type: 'string',
validation: (rule) => rule.required(),
}),
defineField({
name: 'slug',
type: 'slug',
options: { source: 'title' },
}),
defineField({
name: 'author',
type: 'reference',
to: { type: 'person' },
}),
defineField({
name: 'publishedAt',
type: 'datetime',
validation: (rule) => rule.required(),
}),
defineField({
name: 'body',
type: 'array',
of: [{ type: 'block' }],
}),
],
})
Note: Rich text (Portable Text) is defined as type: 'array' with of: [{ type: 'block' }]. There is no standalone 'portableText' type. Reference fields use to (not of) to specify the target document type.
Fetch published articles with dereferenced author data. The -> operator follows the reference to the target document.
*[_type == "article" && publishedAt < now()] | order(publishedAt desc) {
_id,
title,
slug,
publishedAt,
"authorName": author->name,
"authorRole": author->role,
body
}
Without ->, a reference field returns a raw reference object ({ _ref: "...", _type: "reference" }). The dereference operator follows it to the target document's fields. The pipe operator (|) before order() is required — GROQ ordering is not a method on the filter result.
The content API serves structured JSON. A frontend renders it as semantic HTML with JSON-LD. An AI agent can consume either the API directly (for structured queries) or the rendered HTML (for unstructured reading). Both return the same information because both derive from the same source data.
<!-- JSON-LD in page head -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Program Evaluation Results — Spring 2026",
"author": {
"@type": "Person",
"name": "J. Martinez",
"jobTitle": "Director of Assessment"
},
"datePublished": "2026-02-01",
"publisher": {
"@type": "Organization",
"name": "Example Institution"
}
}
</script>AI agents parsing this page get structured metadata (title, author, date, publisher) from JSON-LD and readable content from semantic HTML — without executing JavaScript. This is what "AI-readable" means in practice: the content is in the source, not rendered by a client-side framework.