Key Principles.

Content Ops is the discipline of creating, managing, improving, publishing, distributing, archiving, and retiring content across every digital channel. Machine Experience (MX) is the layer that keeps Content Ops work usable when an AI agent, or any other system, encounters the file outside the environment that produced it.

MX is not SEO, GEO, AEO, Schema.org, JSON-LD, or microdata. Those operate at the discovery layer, where an agent has to find a page and parse what it claims. MX is the layer above them, where an agent that has already found and parsed the page works out whether to act on what it just read. SEO got you found. GEO got you understood. MX gets you used.

This page covers both sides of the picture. The sections that follow set out the techniques MX uses at the discovery layer, the established standards MX defers to, and then the governance envelope MX adds above the discovery layer: provenance, lifecycle, locale conventions, agent affordances, and the signed record an agent verifies before acting. Both sides are required. A page strong at the discovery layer with no governance envelope is the £203,000 cruise misread waiting to happen; the case study is in Appendix I of MX: The Protocols.

Techniques MX uses at the discovery layer

These are the techniques every well-built MX page already employs. None of them is invented by MX. Each is an established web standard MX defers to and ensures is present, complete, and correct.

1. Structured Data - Make meaning explicit through Schema.org markup
2. Accessibility - Build on WCAG 2.1 AA as foundation for agent compatibility
3. Explicit Intent - Declare what things are and what they do, never rely on inference

The three sections below treat each technique in turn. After them, the section The governance envelope MX adds picks up where the discovery layer stops.

Technique 1: Structured Data (Schema.org)

Core principle: Stop making machines guess.

Every piece of information on your website that matters to visitors, prices, contact details, reviews, hours, availability, should be marked up with Schema.org vocabulary so machines can parse it with certainty.

Why Schema.org?

Schema.org is a collaborative vocabulary maintained by Google, Microsoft, Yahoo, and Yandex. It provides standardized ways to mark up content so machines can understand it.

Example: Product without structure

<div class="product">
  <div class="name">Wireless Headphones</div>
  <div class="price">$129.99</div>
  <div class="rating">4.5 stars (230 reviews)</div>
</div>

AI agent sees: Three generic divs with text. It might infer meaning, or it might not.

Example: Product with Schema.org

<div itemscope itemtype="https://schema.org/Product">
  <span itemprop="name">Wireless Headphones</span>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <span itemprop="price">129.99</span>
    <meta itemprop="priceCurrency" content="USD">
  </div>
  <div itemprop="aggregateRating" itemscope itemtype="https://schema.org/AggregateRating">
    <span itemprop="ratingValue">4.5</span> stars
    (<span itemprop="reviewCount">230</span> reviews)
  </div>
</div>

AI agent sees: Product entity with explicit name, offer with price and currency, and aggregate rating with value and count. No guessing required.

Common Schema.org Types for MX

Organization - Your company info, location, contact details LocalBusiness - Physical locations, hours, service areas Product - Items you sell, with specifications and pricing Offer - Pricing, availability, shipping details Review - Customer feedback with ratings and dates Article - Content with authorship and publication info FAQPage - Q&A format with structured questions and answers ContactPoint - Support channels, hours, languages

The Structured Data Mindset

Ask yourself: "If this information matters to a human visitor, can an AI agent parse it with certainty?"

• Prices? → Schema.org Offer with price, currency, availability
• Reviews? → Schema.org Review with rating, author, date
• Hours? → Schema.org OpeningHours with day and time ranges
• Contact? → Schema.org ContactPoint with phone, email, type

If the answer is no, add structure.

The boundary: Schema.org and JSON-LD describe what entities mean on a web page. MX adds governance metadata, provenance, lifecycle state, agent affordances, where Schema.org leaves gaps, and never duplicates what Schema.org already covers. A page with strong JSON-LD becomes a stronger MX surface, not a competing one.

Technique 2: Accessibility (WCAG 2.1 AA)

Core principle: Accessible design IS agent-compatible design.

The things that make websites accessible to humans with disabilities are the SAME things that make them readable by any machine. This convergence thesis is central to Machine Experience.

Why WCAG Matters for AI

WCAG 2.1 AA compliance requires:

• Semantic HTML - Agents understand <nav>, <main>, <article> instantly
• Proper headings - h1 → h2 → h3 hierarchy shows content structure
• Alt text - Describes images for vision-impaired users AND AI image models
• Form labels - Connects inputs to purposes for screen readers AND agents
• Contrast. Readable text for low-vision users. Agents don't care directly, but the discipline forces clear visual hierarchy.

Every WCAG fix you make simultaneously improves agent compatibility.

Semantic HTML: The Foundation

Use the right element for the job. Semantic HTML communicates purpose to assistive tech AND AI agents.

Bad (Non-semantic):

<div class="header">
  <div class="nav">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="content">
  <div class="article">...</div>
</div>

Good (Semantic):

<header>
  <nav>
    <a href="/">Home</a>
    <a href="/about">About</a>
  </nav>
</header>
<main>
  <article>...</article>
</main>

The semantic version tells agents: "This is navigation. This is the main content. This is an article."

Heading Hierarchy: Content Structure

Proper heading structure (h1 → h2 → h3, never skipping levels) shows agents how content is organized.

Why this matters: When an AI agent extracts information from your page, it uses heading hierarchy to understand relationships:

• h1: Page topic
• h2: Major sections
• h3: Subsections
• h4-h6: Further detail

Skipping levels breaks this structure. Agents can't tell if an h4 under an h2 is a subsection or an error.

Alt Text: Describe, Don't Decorate

Alt text serves two audiences:

1. Vision-impaired users using screen readers
2. AI agents understanding image content

Bad alt text:

<img src="photo.jpg" alt="image">
<img src="logo.png" alt="logo">

Good alt text:

<img src="team-meeting.jpg" alt="Development team reviewing MX implementation on whiteboard">
<img src="mx-logo.png" alt="CogNovaMX company logo">

Good alt text is descriptive, specific, and purposeful.

Technique 3: Explicit Over Implicit

Core principle: Don't make machines infer. Declare.

Humans are excellent at inferring meaning from context. Machines are not. If something is disabled, required, loading, or conditional, say so explicitly in your markup, not just visually.

State Must Be Explicit

Visual-only disabled state:

<button class="btn-disabled" style="color: gray; cursor: not-allowed;">
  Submit
</button>

Human sees: Grayed-out button, probably disabled. AI agent sees: Fully functional button with gray text.

Explicit disabled state:

<button disabled aria-disabled="true">
  Submit
</button>

Human sees: Grayed-out button (via browser default styling). AI agent sees: Button explicitly marked disabled. Do not attempt to activate.

Required Fields Must Be Declared

Visual-only required indicator:

<label>Email <span class="required">*</span></label>
<input type="email" name="email">

Human sees: Asterisk indicates required field. AI agent sees: Regular email input with no requirements.

Explicit required declaration:

<label for="email">Email <abbr title="required">*</abbr></label>
<input type="email" id="email" name="email" required aria-required="true">

Human sees: Same asterisk indicator. AI agent sees: Input explicitly marked required. Validate before submission.

Loading States Must Be Announced

Visual-only loading state:

<div class="spinner"></div>

Human sees: Animated spinner, content is loading. AI agent sees: Empty div with class name. Purpose unclear.

Explicit loading state:

<div role="status" aria-live="polite" aria-busy="true">
  <span class="spinner" aria-hidden="true"></span>
  <span class="sr-only">Loading content, please wait...</span>
</div>

Human sees: Spinner (or hears "Loading content" via screen reader). AI agent sees: Content area in busy state, wait before interacting.

Navigation Must Be Structured

Ambiguous navigation:

<div class="menu">
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/support">Support</a>
</div>

Human sees: Menu with links. AI agent sees: Generic container with links. Is this navigation? A footer? A sidebar?

Explicit navigation:

<nav aria-label="Main navigation">
  <ul>
    <li><a href="/" aria-current="page">Home</a></li>
    <li><a href="/products">Products</a></li>
    <li><a href="/support">Support</a></li>
  </ul>
</nav>

Human sees: Same menu. AI agent sees: Primary navigation with current page indicated.

How the three discovery-layer techniques interconnect

The three techniques above reinforce each other at the discovery layer:

Structured Data + Accessibility

Schema.org markup works best on semantically structured HTML. When you use proper elements (<article>, <nav>, <time>), adding Schema.org attributes becomes natural.

Accessibility + Explicit Intent

WCAG requires explicit state declarations (required, disabled, invalid). These same declarations help AI agents understand interaction constraints.

Explicit Intent + Structured Data

When you explicitly mark something as a product, price, or review, you're simultaneously making it accessible and providing structured data for agents.

Example: All three discovery-layer techniques working together

<article itemscope itemtype="https://schema.org/Product">
  <h2 itemprop="name">Premium Wireless Mouse</h2>

  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <data itemprop="price" value="79.99">$79.99</data>
    <meta itemprop="priceCurrency" content="USD">
    <link itemprop="availability" href="https://schema.org/InStock">
    <span class="stock-status" aria-label="In stock">✓ Available</span>
  </div>

  <button type="submit"
          aria-label="Add Premium Wireless Mouse to cart">
    Add to Cart
  </button>
</article>

This markup:

• Structured: Schema.org Product and Offer entities
• Accessible: Semantic article element, proper heading, aria-label on button
• Explicit: Stock status declared in both Schema.org and aria-label

It works perfectly for humans, screen readers, and AI agents.

The three discovery-layer techniques together produce one practical property at this layer: the structure, accessibility hooks, and explicit intent are all inside the file rather than in the system that surrounds it. So when an agent extracts the file from a CMS, a knowledge base, an LLM-wiki, or a training corpus, the receiving context can read it directly without inferring what was lost in transit. They tell the agent what the page is about. They do not yet tell it whether to act on what it just read. That is the next half of the picture.

The governance envelope MX adds above the discovery layer

Schema.org names a price. It does not say who issued the figure, when, against which booking conditions, or whether the version on the page is the version the publisher actually issued. That is the work the MX layer does. Every MX record carries:

• Provenance. Who wrote it, who maintains it (often a different person from the author), the canonical URI where the durable record lives, and a cryptographic signature the agent can verify against the publisher's public key
• Lifecycle. When it was created, when it expires, what triggered the last update, and whether a later record has superseded it
• Locale and conventions. Which decimal grouping is in force, which currency and timezone apply, which booking or contract terms the figure is attached to
• Agent affordances. What may a machine do with this record, under what terms, with what attribution
• Carrier-neutral instructions for use. The same record travels with the file when it leaves the web (PDF brochure, confirmation email, partner data feed, contract, archived court record) without losing any of the above

Together with the discovery-layer techniques, the envelope hands the agent a record it can act on rather than guess at. Schema.org carries the field; MX carries the version, the signer, the date, the locale, the canonical home, and the carriers the same record survives. The discovery layer alone is the £203,000 cruise misread waiting to happen; the case study is in Appendix I of MX: The Protocols.

Implementing the stack

Start with one pillar and expand:

Phase 1: Structured Data

• Identify your most important pages (products, services, contact)
• Add Schema.org markup for key entities
• Validate with Google's Rich Results Test

Phased Rollout Strategy

Phase 2: Accessibility

• Audit with axe DevTools or WAVE
• Fix semantic HTML issues (use proper elements)
• Ensure heading hierarchy is logical
• Add alt text to images

Phase 3: Explicit Intent

• Review forms for required/disabled states
• Check buttons for clear aria-labels
• Ensure loading states are announced
• Verify navigation structure is explicit

The goal: Every page passes all three discovery-layer techniques, and every record carries the governance envelope above them. Start with your homepage and core user journeys, then expand. Phase 4: Governance envelope. Once the discovery layer is solid, declare provenance, lifecycle, locale conventions, and canonical URI on each record so an agent knows whether the version it parsed is current and trustworthy.

Frequently Asked Questions

Deep Dives

Want to understand each pillar in depth?

→ Schema.org for AI Agents → Accessibility ↔ AI Convergence → Explicit Over Implicit

Ready to implement?

→ Our Services → Get MX Consultation