Anatomy of a Pass¶
The Agent Readiness Operator runs a single pipeline:
web page → audit → decide → fix / ship / escalate
You hand it a single thing — a URL, or pasted page source. That is the whole interface.
The One Rule¶
Every pass ends with a binding decision, never a question.
The user sends a URL or pastes page source. That is the entire interface. From that single input I run the operator end to end — audit, decide, fix, escalate, manifest — and return a complete result. The user never picks a specialist, never orders the fix queue, never approves each dimension. I make every routing call.
The audit-tool-gap guard runs first¶
Most fetch tools convert HTML to markdown before I see it, and that conversion strips <script type="application/ld+json"> — exactly where JSON-LD schema lives. So a markdown-converted fetch makes a page rich in schema look schema-free. That is a false negative, not a finding.
Before scoring Structured Data, I check:
/llms.txtand/llms-full.txt— agent-native endpoints that survive markdown conversion and often reveal the entity data directly.- The raw page source, not the markdown render — look for the literal
application/ld+jsonscript blocks.
If I cannot get raw source (markdown-only fetch, JS-rendered SPA), a low Structured Data read is unverifiable, not a confirmed gap → verify against raw source, or ESCALATE the verification.
Five specialist packets¶
When I apply a dimension-specialist I hand it a tight packet — its own slice, the source-availability flag (so it knows whether a low read is a finding or a false negative), and the goal:
PACKET → [N-dimension-name]
- URL: <page url, or "pasted source" if no URL>
- Raw source: yes | no | stripped (per §1 — "stripped" = markdown-only fetch, JSON-LD not visible)
- Signals: <the observed signals relevant to THIS dimension only>
- Goal: score this dimension /20 and return its SHIP/FIX/ESCALATE route + draft fix if FIX
The specialist does not need the other four dimensions' signals; it scores its own dimension and returns its route. I assemble the five results into one verdict.
Adversarial challenge gate¶
After all five specialists return their findings — and before a single line of output is emitted — the adversarial specialist challenges every finding. This is not a manual review step; it runs automatically on every pass, including all-SHIP passes.
The adversarial specialist receives each dimension's evidence packet and finding in isolation (no cross-dimension contamination), then checks four things per dimension: does the score fit the rubric band the evidence supports; does the route match the canonical decision table; do the artifact facts trace to the packet; and does each artifact pass the fix-acceptance rubric. It then runs one cross-dimension consistency check against the full assembled verdict.
It issues a binding CLEAR or CHALLENGE per dimension. Every CHALLENGE must be resolved — re-scored, re-routed, or corrected — before the pass proceeds. The adversarial specialist does not re-run after resolution.
This is the drift guard. It re-reads each rubric band and decision route with fresh context, independent of the scoring pass that preceded it. Score inflation, invented URLs in sameAs arrays, and decision-table bypasses are caught here before they reach output.
Full adversarial gate reference →
Two modes¶
AUDIT — automatic on any URL or pasted source¶
One pass produces, in order: a Signal Map (one paragraph per dimension) → a score table (five rows + total) → a band → a per-dimension decision → AND the drafted fixes for every FIX-tagged dimension, in the same pass. AUDIT does not stop at "you should fix X." It produces the fix.
FIX — generate and ship the artifacts¶
- Drafting to a separate output needs no gate. Writing fixes to chat, or to
proposed-fixes/in Claude Code, is non-destructive — I just do it. - The only confirmation step is applying in-place over existing files in Claude Code (overwriting the live
robots.txt, an existing page's<head>). That single gate is a safety checkpoint before an irreversible write: I copy each target toproposed-fixes/backup/and emit the applied-changes manifest before any in-place write.
The fix queue is structural-first¶
Structured Data and Crawl Signal before Citability, Freshness, Entity Authority.
Content work built on a broken foundation compounds the problem. The priority routing rules govern the order:
- Rule 1 — Structured Data < 10 AND no
/llms.txt→ generate agent-native endpoints first. - Rule 2 — Crawl Signal < 10 → correct
robots.txtbefore anything else.
A locked robots.txt makes every other fix invisible to agents — so crawl is the harder block and runs first.