Schema stripped by fetch — Functional¶
Input: https://www.meridiananalytics.io — Meridian Analytics, a B2B data analytics SaaS in Austin, TX. The fetch tool returned markdown only (no raw source available), and the markdown shows no schema. This is exactly the false-negative trap from rules.md §1 and audit-tool-gap.md: HTML→markdown conversion strips <script type="application/ld+json">, so a schema-rich page reads as schema-free.
Audit-tool-gap check (before scoring Structured Data)¶
This is the discipline that separates an operator from a generator. I run the §1 verification before I score, and I refuse to score a stripped fetch as a confirmed gap.
/llms.txt→ fetched → 404. Confirmed absent./llms-full.txt→ fetched → 404. Confirmed absent.- Raw source → not available in this session (markdown-only fetch). Google Rich Results Test not runnable here.
What the markdown does show: the company name, an Austin address, a contact email, a product description, and footer links to LinkedIn, Crunchbase, and X. Entity data renders fine — so the page is serving HTML correctly; only the JSON-LD layer (the part markdown strips) is unobservable.
Conclusion: JSON-LD presence is unverifiable, not confirmed-absent. Per the rule, an unverifiable schema read is never grounds to "fix" by generating duplicate schema — that would risk shipping a second Organization block on top of one that may already exist, which is a fabricated fix. I set a floor score for the confirmed gap only (/llms.txt / /llms-full.txt absent) and escalate the verification.
Score¶
| Dimension | Score (/20) | Finding |
|---|---|---|
| Structured Data Coverage | 7 (FLOOR) | JSON-LD unverifiable (fetch stripped it); /llms.txt + /llms-full.txt confirmed absent. |
| Citability | 16 | Product/pricing claims are specific and extractable. |
| Crawl Signal Clarity | 16 | All five AI crawlers allowed; sitemap referenced. |
| Content Freshness | 14 | Dated changelog, most recent entry ~2 weeks old. |
| Entity Authority | 12 | LinkedIn + Crunchbase + X consistent; no Wikidata/Wikipedia seen. |
| Total | 65/100 (provisional) | Band: Functional — Structured Data row is a floor, not a verdict. |
The total is explicitly provisional: the Structured Data row is a floor pending verification, so the real total may be higher once raw source is read.
Per-dimension decision¶
| Dimension | Route | Why |
|---|---|---|
| Structured Data | FIX (confirmed part) + ESCALATE (unverifiable part) | llms files confirmed-absent → FIX. JSON-LD unverifiable → ESCALATE verification, do NOT fabricate. |
| Citability | SHIP | 16/20. |
| Crawl Signal | SHIP | 16/20. |
| Content Freshness | SHIP (no producible gap) | 14/20 — the dated changelog is the freshness signal; remaining items at this band are verifications, not artifacts. |
| Entity Authority | SHIP (no producible gap) | 12/20 — the producible fix (sameAs expansion) is blocked behind the escalated JSON-LD verification; the remaining lift (Wikidata) is action in the world — noted, not forced. |
The operator's signature move here: it FIXes what is confirmed-absent and refuses to fabricate the part it cannot see.
What the operator did¶
FIX (confirmed-absent only) — /llms.txt and /llms-full.txt¶
These are confirmed 404s regardless of schema status, so they are a real gap and I produce them now. All facts are from the markdown that did render.
/llms.txt (serve at root as text/plain):
# Meridian Analytics
> Meridian Analytics is a B2B data analytics platform based in Austin, TX, that
> ingests event data from 40+ sources and returns governed dashboards in under
> 60 seconds. Contact: support@meridiananalytics.io.
## Key pages
- [Product](https://www.meridiananalytics.io/product): Data ingestion, governed dashboards, and delivery times.
- [Pricing](https://www.meridiananalytics.io/pricing): Named tiers with monthly pricing.
- [Changelog](https://www.meridiananalytics.io/changelog): Dated release notes.
- [Contact](https://www.meridiananalytics.io/contact): Support email and company address.
## Full facts
- [llms-full.txt](https://www.meridiananalytics.io/llms-full.txt): Complete product, pricing, and entity facts.
/llms-full.txt (serve at root as text/plain):
# Meridian Analytics — Full Facts
## Identity
- Name: Meridian Analytics
- Type: B2B data analytics SaaS
- Location: Austin, TX, US
- Email: support@meridiananalytics.io
- Website: https://www.meridiananalytics.io
## Product
- Ingests event data from 40+ sources
- Returns governed dashboards in under 60 seconds
## External profiles
- LinkedIn: https://www.linkedin.com/company/meridian-analytics
- Crunchbase: https://www.crunchbase.com/organization/meridian-analytics
- X: https://twitter.com/MeridianData
Plus the top-of-<body> discovery link so agents reach these files first.
I am NOT generating an
OrganizationJSON-LD block here. It may already exist in the raw source the fetch stripped. Generating one blind risks a duplicate entity definition — a fabricated fix. The JSON-LD question is escalated below, not papered over.
ESCALATE — verify the JSON-LD before any schema fix¶
Dimension: Structured Data Coverage (Dimension 1)
Specific blocker: The fetch tool returned markdown only and strips <script type="application/ld+json">. I cannot confirm whether JSON-LD exists. /llms.txt and /llms-full.txt are confirmed 404, but those are a separate layer from on-page schema. I attempted the §1 verification (both llms endpoints checked, raw source unavailable, Rich Results Test not runnable) before escalating — this is not a generic "ask the user."
What an agent observes instead: Production crawlers read raw HTTP and would see any JSON-LD that exists, so a real-world agent may already be parsing this entity cleanly. The risk is on my side: if I generate duplicate schema, the page ships two conflicting entity definitions, which degrades parsing for the very agents it was meant to help.
Exact action that unblocks it: Open view-source:https://www.meridiananalytics.io and search for application/ld+json, or run the page through Google Rich Results Test (https://search.google.com/test/rich-results), or paste the raw HTML here. If schema is present, the Structured Data floor lifts and no schema fix is needed (only sameAs expansion to the confirmed profiles). If schema is genuinely absent, I generate an Organization block from fix-templates/jsonld-organization.md using the facts in /llms-full.txt above.
Deploy manifest¶
| # | Dimension | Artifact | Where it goes | How to verify |
|---|---|---|---|---|
| 1 | Structured Data | /llms.txt |
site root | fetch as text/plain → entity description + key pages |
| 2 | Structured Data | /llms-full.txt |
site root | fetch as text/plain → facts, not just URLs |
| 3 | Structured Data | Discovery link block | top of <body> |
links are first body element, not footer |
Projected score: 65/100 (provisional) → 73/100 (provisional, Functional). Only Structured Data claims lift (7→15, the llms adjustments from the audit-tool-gap reference) — still capped pending the escalated JSON-LD verification. Every other dimension is a control and should not move at re-audit.
Decision: FIX the confirmed-absent llms files now; ESCALATE the JSON-LD verification rather than fabricate duplicate schema. Score 7/20 on Structured Data is a stated floor, not a verdict.
Why this run matters¶
This run demonstrates the Operator's refusal to fabricate fixes when raw source is unavailable — a critical discipline that separates reliable operators from generators of empty action plans. Meridian Analytics presents a false-negative trap: the markdown-only fetch strips JSON-LD, making a schema-rich page appear empty. The Operator correctly identifies this as an unverifiable state rather than a confirmed gap, sets a floor score of 7/20 for the confirmed-absent llms files, and produces those artifacts while escalating verification rather than guessing at schema that may already exist.
This discipline — refusing to duplicate or fabricate JSON-LD when the truth is unverifiable — prevents a common failure mode where automated tools generate duplicate entity definitions that degrade parsing quality. The Operator's signature move here is to FIX what it can verify (the llms files) and ESCALATE the unverifiable part (JSON-LD presence) with precise instructions for verification. The score of 65/100 is explicitly provisional, signaling that the real score may be higher once raw source is available. This transparency about uncertainty — distinguishing confirmed gaps from tool artifacts — is what makes the Operator trustworthy when dealing with imperfect information.