Schema decays. Here's the half-life I've measured.

A team ships a clean schema architecture in week six of a Sprint. Validators pass, AI engines start citing them, organic revenue lifts, the post-launch report looks great. Twelve weeks later, citation share is back to where it was before the engagement and nobody can point to a single thing that broke.

This is the most expensive failure mode in the practice. The schema didn't break in any visible way. It decayed.

I've measured the decay timeline across enough engagements to put numbers on it. The numbers are why a Retainer exists, and why "we'll just maintain it ourselves" is a sentence that has cost teams six-figure rework projects.

The half-life I've measured: 60 to 90 days

On a team that ships weekly with no schema-aware CI gates, the time from a clean post-launch baseline to the first regression that materially affects AI citation share is 60 to 90 days. That's the half-life of unmaintained schema architecture in production.

By "first regression" I mean a change that breaks at least one of:
- An @id chain (most commonly someone shipping a new template that emits Organization with a different @id pattern, the same drift documented as bug #1 in the commerce audit catalog)
- A required field on a rich-result-eligible entity (Product missing priceValidUntil after a refactor of the price logic)
- The server-side rendering of the schema (a developer moves the JSON-LD into a client-only component to "modernize" the codebase, which is the catastrophic bug #8 in the same catalog)

The breakage is silent. Validators don't catch it because validators only see syntax. Search Console doesn't surface it because the rich result loss happens at the AI engine layer, which Google doesn't report on. The team finds out from a quarterly visibility review, by which point three more regressions have stacked behind the first.

Why decay is structural, not careless

Schema regressions are almost never caused by careless work. They're caused by code changes that have nothing to do with schema, made by engineers who don't know schema is a load-bearing layer.

A few patterns I see repeatedly:

A frontend refactor moves a component to client-only rendering. The schema generator for that template was server-side, embedded in the page-level component. The refactor unbundles the page-level component into smaller pieces, the schema generator gets pulled into a client-only wrapper, and AI engine fetchers stop seeing it. (How each AI engine handles client-rendered schema differently.)

A new product attribute gets added to the database. Marketing wants to surface it. Engineering ships the surface change. Nobody updates the Product schema to include the new field. The Product entity emitted to AI engines is now incomplete relative to what's on the page, which engines flag as a partial match and downweight.

A CMS plugin gets installed for a different reason. The plugin injects its own JSON-LD as a defensive default. Now there are two Organization blocks on the page with different @ids. Entity merge fails.

Someone "consolidates" multiple JSON-LD blocks into one for cleanliness. They lose @id references in the consolidation because the new structure doesn't have a place for them. The @graph is now flat.

In every case, the engineer who shipped the change had no idea schema was affected. They couldn't have known. The only way to catch these is in CI, before the change ships.

What the validator suite actually does

A schema validator suite in CI runs three layers of checks on every PR:

1. Schema.org compliance. Standard JSON-LD validation. Catches malformed JSON, unknown types, required fields missing.

2. Custom @graph rules from the architecture decision record. Encodes the project-specific decisions: every Product references the canonical Brand @id, every Article references the canonical Person @id, BreadcrumbList items use trailing-slash URLs only. These are the rules that don't exist in Schema.org but do exist in the architecture you shipped.

3. Entity resolution disambiguation tests. Runs a subset of pages through the same emulators RankLabs uses for AI engine extraction. Confirms that a Product still resolves to the right Brand, that the Article author still resolves to the right Person.

A PR that breaks any of these fails the build with a readable error pointing at the offending field. The engineer fixes it before merge. The 60-to-90-day decay timeline becomes irrelevant because regressions never reach production.

The cost of building this suite is real but bounded: usually a few engineer-days during the Sprint. The cost of not having it shows up as the schema architecture rebuild eighteen months later.

How to tell if your schema is decaying right now

If you've shipped schema work in the past year and don't have a CI validator suite, it's decaying. The question is by how much. Three quick checks:

Run your top ten template URLs through Google's Rich Results Test today. Then run them again in a month. Any rich result eligibility you lose between the two runs is decay.

Compare your live HTML against your codebase's schema generator output. If the live response is missing fields the generator emits, something downstream (a CDN, a caching layer, a tag manager) is mangling output.

Run your priority query set through ChatGPT or Perplexity today, then again in 60 days. If citation share drops on queries you previously won, your schema is leaking.

Any of those three checks failing means you've got regressions in production. The Audit will find them, the Sprint will fix them, the Retainer is what stops them from coming back.

Why "we'll maintain it ourselves" usually doesn't work

Almost every Sprint client says they'll maintain the schema themselves. Three of every four come back within a year asking for a Retainer or a remediation Sprint. The reason isn't capability. It's bandwidth.

Schema regression monitoring is one of those things that's only valuable when it's continuous. A team running it once a quarter sees five regressions and fixes them. A team running it on every PR sees zero regressions because they got caught at the source. The bandwidth ask isn't large, but it's continuous, and continuous engineering work that isn't in someone's quarterly OKRs gets dropped.

A Retainer exists because schema work is one of the things where my time is cheaper than yours, by a wide margin. I have RankLabs running every day, the regression patterns are pattern-matched, and the engineering cost of catching a regression on day three is an order of magnitude lower than catching it on day ninety.

If you've shipped schema work and you don't have monitoring, the Retainer is the most boring decision on this site to make. It is also the highest-leverage one.