One rubric, 8 site profiles: why a publisher should not be asked for a product feed

A scanner that does not know what kind of site it is looking at will still answer. Point it at a news publisher and it returns a confident, specific, correctly formatted instruction: publish a product feed. The recommendation is wrong, and the publisher pays for it with a day of work that should never have been requested. Site profiles, added in rubric v0.4, exist to remove that failure.

The failure, in two examples

A flat rubric measures everything it can reach. On a publisher, the report can list product-schema and inventory-freshness as misses. Both are real checks with real fixes attached; neither applies. A product feed describes SKUs, prices and stock, with availability and price validity carried the way schema.org's Offer type defines them. A newsroom has articles, authors and a licensing position, not stock. An owner who follows the fix builds a surface that describes nothing, then maintains it.

The same happens to a clinic told to ship an OpenAPI document. In the baseline readiness model that document is required for Level 4, sitting in the set next to mcp-card, oauth-discovery and api-catalog. A clinic has no API and never will. Told it cannot reach the level without one, it either publishes a decorative document nothing consumes or concludes the scoring model was not written for it. Both outcomes are the tool's fault.

The obvious repair — delete the API checks — is worse: a developer platform needs exactly those checks. The problem was never the check, but applying it without knowing whose site it is.

A false demand spends the owner's time first and their trust second. An audit that issues one instruction the owner knows to be nonsense has taught them to read the rest of the report as optional.

Every check declares a scope

Scope is the mechanism. Each of the 61 checks carries one of three values, and the value decides whether the check is scored at all.

The commercial scope is not new: earlier versions already removed the six commerce checks from numerator and denominator unless the site showed a commercial signal, so a non-commercial site was never penalised for having no payment standard. Profiles apply the same move one level up — not "is this commercial" but "what kind of site is this".

The nine profile checks are where the type-specific demands live. inventory-freshness applies to shops and marketplaces, where stock and prices go stale. sandbox-environment applies to SaaS and API platforms, which need somewhere to integrate before production. licensing-terms applies to publishers and institutions, whose content may be mined under a declared policy such as the TDM Reservation Protocol. booking-action applies to service businesses, whose agent-facing task is a completed schema.org ReserveAction booking, not a page view.

Scope is one field per check, printed on every page under checks and published in /rubric.json.

The governing rule

No profile-specific demand without a positively identified profile. Failing to understand a site must never turn into work for its owner.

Read that as a constraint on the tool, not a courtesy to the owner. Detection must produce evidence, because a classification the owner cannot inspect can only be accepted on faith; there must be an outcome that says "we could not tell", because the alternative is presenting the nearest guess as a finding; and every check removed from the scoring set has to be named. The full policy is published at site profiles.

Detection is deterministic, and it shows its evidence

A site profile is not assigned by a language model or inferred from tone. A fixed list of signals is matched against documents the scanner has already fetched, so detection adds no requests and returns the same answer on every run:

• Structured-data types on the homepage — Product and Offer for retail, NewsArticle or Article for a publisher, LocalBusiness for a service business.
• Paths that respond — /checkout for a shop, /openapi.json for a developer platform, /pricing for a SaaS product.
• Page copy — "add to cart", "book an appointment", "rate limit".
• The domain suffix — .gov and .edu for institutions, .org as a weaker hint.

Selection is arithmetic rather than judgement. Signals carry weights between 1 and 3, and a profile is chosen when its score reaches 3 and it beats the runner-up by at least 2. One weight-3 signal, such as Product schema on the homepage, can reach the threshold alone; weight-1 signals such as a .org suffix only matter in company.

Every matched signal is reported with the label that fired: "NewsArticle schema on the homepage", "a blog index responds". The purpose is to be arguable — if a report cannot show why it decided your site is a shop, the owner cannot tell a detection bug from a fact about their own site. Detection and scoring are also kept apart: inventory-freshness is scored only after the e-commerce or marketplace type has been identified by other signals, and its absence is never evidence that the site is a shop.

Three outcomes, and only one of them gives instructions

Identified. The profile's stance applies, and a stance changes four things: the category weights, which checks are in scope, which are explicitly out of scope, and what each readiness level requires. A publisher is weighted toward content and discoverability, with commerce down at 12%; a service business has openapi out of scope, so a clinic is never asked for it, while a SaaS product has it in scope at Level 4.

Ambiguous. Two candidates score too close to separate — a publisher that also sells print subscriptions can fire Article schema and a checkout path in one scan. The scanner does not resolve that by picking the larger number: baseline weights apply, profile-scoped checks are reported as not scored, both candidates are named, and the owner is asked to confirm the stance.

Unknown. Nothing reaches the threshold. Baseline weights apply, profile-scoped checks are reported as not scored, and the report states plainly that the site profile could not be determined.

In both non-identified outcomes, those checks leave the denominator as well as the numerator, and the report gives the reason. They are never counted as failures. Counting a check we chose not to measure as zero would be the same error one step removed: it would convert our uncertainty into the owner's problem. No profile-specific demand without a positively identified profile. Failing to understand a site must never turn into work for its owner.

Nor is unknown a soft pass: an unidentified site is still measured on the 46 universal checks, plus the commercial ones if a commercial signal fired. The fallback is less specific, not unscored.

When the owner knows better

Detection is inference over a handful of documents; the owner has ground truth. A site owner can declare the type, and the record then says the profile was declared, not detected.

The distinction is kept because the claims are not equivalent: a detection can be re-run against the same signals, while a declaration is an assertion. It also moves scope in either direction — declaring "publisher" on a site the scanner read as a shop removes commerce demands and adds licensing ones — which is why the record does not launder it into a detection.

What this costs, and why we paid it

Profiles are more machinery than a flat rubric. The 8 profiles, with weights, signals, out-of-scope entries and level requirements each, are a matrix someone has to maintain, and every row is a place to be wrong. Detection reads the homepage and a few related documents, so a site that changes what it does without changing what it publishes can be classified on stale evidence — a blog that starts selling a course, a shop whose product markup only some routes emit. And because removal changes the denominator, two sites under different profiles are not scored over identical check sets: totals should be read with the stance in view, not as a league table.

We accepted that because the two error directions are not priced the same. A missed optimisation costs a site some upside: it stays on the baseline stance, is measured on the checks that apply to every site, and loses only the extra specificity its type would have earned. An incorrect instruction costs the owner their time, and it costs the tool its credibility: a claim the owner can see is false contaminates every other line of the report. The threshold sits where it does for that reason, the evidence is printed, and an owner who disagrees can override. We choose to under-claim rather than over-demand.

What this still gets wrong

• Type can hide below the homepage. A SaaS product with no pricing path, or an institution on a .com, may land in unknown. The matched signals are still listed, so the owner can see what the scanner saw; the report is simply less tailored than the site deserves.
• Sites that straddle types lose detail. A publisher with a real shop is genuinely two things. Ambiguity is reported rather than resolved: honest, but not as useful as a correct stance.
• A declaration is unverified. The record says so, and a reader should treat it accordingly.
• The weights are editorial judgements, not measurements. Publisher content 30% and commerce 12% reflect an argument about what a publisher's agent-facing job is. The numbers are published in /rubric.json so they can be argued with rather than trusted.

None of this is hidden. The methodology page is the scoring contract, and what the product cannot yet do is published next to what it can.

The point of all of it

Profiles do not make the rubric more forgiving: the same 61 checks ship, and a check that applies still costs the same points when it fails. What changed is that a check has to apply before its failure can be quoted back as a task.

A publisher asked for a product feed is not being audited strictly; it is being audited by something that did not read the site. Specificity is only worth something when it lands on the right kind of site.