Run free scan
Run free scan

/methodology · published reference · v3.2

The Caboo Score.

Six sub-scores, weighted by what predicts whether a buyer asks AI and ends up at your door. The full equation, signed and versioned. This document is the contract: when something Caboo says about your business is challenged, this is the page we're held to. We measure the reproducible, non-personalized baseline anyone can verify via API — not the personalized answer logged-in users see.

Signed Methodology v3.2 · published May 1, 2026 Caboo Methodology Committee

§ 1.Overview

What the score measures, in one paragraph.

The Caboo Score is a 0–100 number that estimates how often a buyer asking AI for what your business sells ends up reading your name. It rolls up six measurable signals into one figure. It does not measure what individual users see (they get personalized answers), or how good your business actually is (we leave that to your customers). It measures one specific layer: the recommendation surface AI assistants present when asked.

The score is comparable across businesses in the same category and region. It updates each scan; week-over-week swings of ±5 points are normal model variance and are not on you. Larger movements reflect real changes in your visibility — or your competitors'.

§ 1.1.Freshness layer

How Caboo stays current as AI surfaces change.

Caboo measures the reproducible, non-personalized AI-search visibility baseline across live AI search surfaces. Personalized consumer answers can differ.

v3.2 actively probes the crawler-directive and search-eligibility layer for each provider: OAI-SearchBot, ChatGPT-User, and Bing visibility for ChatGPT Search; Brave visibility plus Claude-SearchBot and Claude-User for Anthropic; Google-Extended for Gemini API grounding; Googlebot indexing and snippet eligibility for AI Overviews and AI Mode; and PerplexityBot plus native Sonar Pro Search for Perplexity.

These are not interchangeable controls. Bing is a confirmed ChatGPT Search provider signal, but OpenAI also uses its own crawlers and provider relationships. Claude has strong Brave Search dependency evidence, but Anthropic also documents its own search and user-fetch agents. Google-Extended controls Gemini API and Vertex grounding; Google Search AI features use Googlebot and snippet eligibility instead.

Each (prompt, provider) pair runs as a single-shot probe in v3.2. We don't yet sample variance across prompt seeds or model temperatures; that's a known limit, not a hidden one. Variance sampling is targeted for v3.3.

Each scan is tied to a scan profile and model pack. New models first enter candidate and shadow mode, run through canary prompts, then become active only through a published methodology change. Older scans are marked fresh, warm, or cold so customers know whether a score is current or needs a retest.

Caboo measures the reproducible, non-personalized AI-search visibility baseline across live AI search surfaces. Personalized consumer answers can differ.

Freshness health Static baseline Live health appears when the API status endpoint is available.
Active profile 2026-05-generic-smb-us-local The complete methodology bundle used by new scans.
Model pack 2026-05 The exact AI surface bundle used for comparable scoring.
Crawler directive set ai-crawlers-2026-05 The robots.txt policy behind Fix Pack crawler advice.
Surface coverage Direct + OpenRouter breadth Direct surfaces expose deeper diagnostics; breadth surfaces expand coverage.
Current
Methodology v3.2 baseline

Current scan profile, model pack, contextual prompt pack, and crawler directive set.

May 1 2026

§ 2.The equation

The full math, in one block.

Each sub-score is a 0–1 measurement, multiplied by its weight, summed, and rendered as a 0–100 score. The weights are not arbitrary; each one defends itself in the relevant section below.

Caboo Score
Visibility
Preference
Accuracy
Source Strength
Technical
Percentile

§ 3.Sub-scores in detail

Each weight defends itself.

For every sub-score, four things are documented: what we measure, how we measure it, a worked example against a sample business, and the caveats we know about. The caveats are where a lot of trust gets earned — methodology pages that hide their limits aren't being honest about them.

Visibility § 3.1

0.35 weight
What we measure

How often the business appears at all — by name — when AI assistants are asked the kind of question a buyer would ask.

How we measure it

Each scan generates 10 buyer-intent prompts from the business intake and scraped website context, then runs them across 4 platforms (40 responses total). Visibility = appearances ÷ 40. Tangential mentions count; competitor-only mentions do not.

Worked example

Foster & Lin Law appeared in 11 of 40 responses. Visibility = 0.275. Weighted contribution = 0.275 × 0.35 = 0.096.

Caveats

Visibility ≠ Recommendation. A buyer reading "Foster & Lin Law is one option, though Northwest Estate Group is more frequently cited" sees the name but isn't being steered. That distinction is what Preference catches in §3.2.

Step-by-step walkthrough
  1. 01

    Compose 10 buyer-intent prompts from the submitted category, location, and site evidence ("best estate planning attorney near 97205", "top rated HVAC contractors in Phoenix", etc.) and run each through ChatGPT, Claude, Gemini, and Perplexity — 40 responses logged.

  2. 02

    Match by name: tangential mentions count, competitor-only mentions don't. Foster & Lin Law surfaced in 11 of 40.

  3. 03

    Compute raw visibility: 11 ÷ 40 = 0.275.

  4. 04

    Apply weight: 0.275 × 0.35 = 0.096 contribution to Caboo Score (out of a possible 0.35).

Preference § 3.2

0.18 weight
What we measure

Whether AI recommends the business actively, or just mentions it among options. The difference between "go to Foster & Lin Law" and "Foster & Lin Law is one option."

How we measure it

Each appearance is graded into one of three positional tiers — recommended (named first or as the answer), among-options (named in a list), buried (named only in a comparative or qualified clause). Preference = (3·top + 2·mid + 1·low) ÷ (3 · total appearances).

Worked example

Foster & Lin Law's 11 appearances graded as 1 top, 4 mid, 6 low. Preference = (3 + 8 + 6) ÷ 33 = 0.515. Weighted = 0.093.

Caveats

We can't read the model's mind-state. A neutral mention before a competitor and a neutral mention after are weighted the same. We're tracking ordering effects in v3.2.

Step-by-step walkthrough
  1. 01

    For each appearance, classify the position: top (named first or as the answer) = 3 pts, mid (in a list) = 2 pts, low (only in a comparative qualifier) = 1 pt.

  2. 02

    Foster & Lin Law's 11 appearances graded: 1 top, 4 mid, 6 low.

  3. 03

    Sum points: (3·1) + (2·4) + (1·6) = 17. Maximum possible: 3 · 11 appearances = 33.

  4. 04

    Compute: 17 ÷ 33 = 0.515. Apply weight: 0.515 × 0.18 = 0.093.

Accuracy § 3.3

0.13 weight
What we measure

Whether the AI describes the business correctly — services offered, location, hours, price band, distinctive offerings. Hallucinations get caught here.

How we measure it

For each appearance, the AI's description is fact-checked against the business's website + verified directory listings (Yelp, Google Business, Apple Business Connect). Accuracy = supported facts ÷ (supported + contradicted facts). Unverifiable claims are excluded from the denominator.

Worked example

Foster & Lin Law's appearances contained 23 verifiable facts: 15 supported, 5 unverifiable, 3 contradicted. Accuracy = 15 ÷ (15 + 3) = 0.833. Weighted = 0.108.

Caveats

AI confidence ≠ AI correctness. A model can confidently state hours that aren't real. We log contradictions and surface them on your dashboard for review — they're not just deductions, they're warnings.

Step-by-step walkthrough
  1. 01

    Extract every factual claim made by AI about Foster & Lin Law — services, hours, address, certifications, price band. 23 verifiable claims surfaced across all appearances.

  2. 02

    Cross-check each against the canonical truth set: business website + Google Business Profile + Yelp + Apple Business Connect.

  3. 03

    Bucket: 15 supported, 5 unverifiable (excluded from denominator), 3 contradicted.

  4. 04

    Compute: 15 ÷ (15 + 3) = 0.833. Apply weight: 0.833 × 0.13 = 0.108. The 3 contradictions surface on the dashboard as alerts.

Source Strength § 3.4

0.22 weight
What we measure

Whether AI is citing and corroborating the business through strong, current sources — the business site, review platforms, category directories, forums, social/video, Wikipedia/Wikidata, news, and marketplaces.

How we measure it

Each cited URL is classified into source classes — own site, business profiles, review platforms, category directories, general directories, forums, social proof, video, press/local news, Wikipedia/Wikidata, marketplace, or other — then weighted by class coverage. Independent citation studies show different domain mixes per engine, so Caboo classifies sources rather than assuming one universal optimization path.

Worked example

Foster & Lin Law's grounded responses cited 8 sources — 0 Tier-1, 6 Tier-2 (Yelp ×4 review, Google ×2 directory), 2 Tier-3 (Reddit forum). Average = 0.55. Weighted = 0.121.

Caveats

Citation availability varies sharply by platform. Perplexity exposes richer citation data through native Pro Search, Gemini exposes grounding metadata, and Claude/ChatGPT expose deeper diagnostics only when web-grounded. Businesses on platforms that hide citations may score lower without doing anything wrong.

Step-by-step walkthrough
  1. 01

    Tag each citation in Foster & Lin Law's grounded responses by tier: T1 (major press, .gov, .edu) = 1.0, T2 (industry directories, verified review platforms) = 0.7, T3 (social, blog, low-authority) = 0.4.

  2. 02

    Foster & Lin Law's 8 citations bucketed: 0 T1, 6 T2 (Yelp ×4, Google ×2), 2 T3 (Reddit threads).

  3. 03

    Sum tier scores: (0·1.0) + (6·0.7) + (2·0.4) = 5.0. Compute average: 5.0 ÷ 8 = 0.625. (Reported as 0.55 after clamping for citation-confidence.)

  4. 04

    Apply weight: 0.55 × 0.22 = 0.121. The 0 T1 citations are flagged as the highest-leverage gap.

Technical Extractability § 3.5

0.07 weight
What we measure

Whether the business's website is extractable after eligibility is satisfied: schema markup, FAQ structure, canonical facts, sitemap discovery, semantic HTML, and stable crawl access.

How we measure it

Eligibility is treated as a gate: robots/CDN access, indexability, sitemap availability, noindex status, WAF behavior, and recency signals. Extractability is then scored from schema, FAQ structure, headings, canonical business facts, OpenGraph metadata, and page structure. llms.txt is optional future-compatible infrastructure, not a current score driver.

Worked example

Foster & Lin Law passed the homepage fetch but lacked schema and FAQ structure. Technical = 0.10. Weighted = 0.007. The Fix Pack prioritizes crawler access, schema, source coverage, and service-page structure before optional files.

Caveats

A high Technical score doesn't earn AI recommendation by itself; it's a floor, not a ceiling. AI can find you without schema — it just costs more compute and the answer is less reliable.

Step-by-step walkthrough
  1. 01

    Run the eligibility gate first: indexability, robots/CDN access, sitemap availability, noindex status, and WAF behavior. If a site fails eligibility, Caboo flags that before recommending extractability work.

  2. 02

    Foster & Lin Law passed only one item: mobile-responsive. Total: 1 / 10.

  3. 03

    Compute extractability after eligibility: 0.10 × 0.07 = 0.007.

  4. 04

    The Fix Pack installs schema and FAQ structure, repairs crawler instructions, and points manual work toward third-party sources. Optional llms.txt is generated only as future-compatible infrastructure.

Category Percentile § 3.6

0.05 weight
What we measure

How the business's combined sub-scores rank against similar businesses in the same {category, region, size}. Pure relative measurement.

How we measure it

For each business in the same cohort, we rank its previous five sub-scores. Percentile = rank position ÷ cohort size, inverted (higher = better). We require a minimum cohort of 30 peer businesses; smaller cohorts return "insufficient cohort" instead of forcing a number.

Worked example

Foster & Lin Law ranked 88 of 142 estate planning attorneys in the Portland metro. Percentile = (142 − 88) ÷ 142 = 0.380. Weighted = 0.019. Reported as "Bottom 38%."

Caveats

Cohort definition matters. We currently bin by SIC-equivalent category and ZIP3 region; we are testing finer cohorts in v3.2. A business in a sparsely-scanned category may briefly dominate its cohort without dominating its actual market.

Step-by-step walkthrough
  1. 01

    Identify the cohort: estate planning attorneys in the Portland metro (ZIP3 970-972), SIC-equivalent Legal Services. Cohort size: 142 peer businesses (≥30 minimum required).

  2. 02

    Combine each cohort member's previous five sub-scores; rank ascending. Foster & Lin Law ranked 88 of 142 — better than 54 peers, worse than 87.

  3. 03

    Compute: (142 − 88) ÷ 142 = 0.380. Apply weight: 0.380 × 0.05 = 0.019.

  4. 04

    Surface as plain language: "Bottom 38% of Portland-metro estate planning attorneys." Cohorts smaller than 30 return "insufficient cohort" rather than a forced number.

§ 4.The Fix Pack

From measurement to install.

A score that doesn't tell you what to install isn't credible. Every Caboo dossier closes with a Fix Pack — a small bundle of code, schema, and copy that maps directly to the sub-scores above and is ready to paste into a CMS, a robots.txt, or a footer. Each item is generated from a deterministic skeleton (template cms-fixpack-v1) that the model fills with site-specific facts; the model never invents structural fields, branded names, or claims that weren't present in the intake or scrape. Across the current Fix Pack item types, install acceptance averages around 76% within thirty days of dispatch — measured by re-scan delta, not by self-report.

The pipeline below explains how a Fix Pack item gets from "the score said you're weak on Source Strength" to "here is the JSON-LD block you paste into your <head>." Six current item types are documented at §4.1–§4.6; new types are versioned through the same methodology committee that owns this document.

Fix Pack items are produced by the same scoring run that generated the score — never re-derived after the fact, and never rewritten on re-open. Each item is signed against the model pack and template version that produced it.

Stage 01 Skeleton Deterministic cms-fixpack-v1 template selects item types from the sub-score gap, not from model preference.
Stage 02 Site evidence Intake fields, scraped page contents, and any verified third-party links are injected as the only allowed sources of business-specific text.
Stage 03 Model proposes The active model pack drafts the per-field fills (descriptions, FAQ answers, location copy) constrained to the evidence above.
Stage 04 Threshold merge Fields below the per-type confidence threshold revert to the conservative skeleton default rather than ship a guess.
Stage 05 Code validation Rule SR-SANITIZE-001 strips <script> tags, event handlers, javascript: URLs, oversize bodies, and any branded invention.
Stage 06 Persisted once The validated Fix Pack is written to the dossier and never regenerated on re-open — only on a fresh scoring run.

For every item type, four things are documented: what it ships, where it installs, what the model is allowed to write, and what gets stripped. The first worked example is open by default so you can see the deterministic-skeleton pattern before opening the rest.

Schema § 4.1

JSON-LD format
What it ships

A LocalBusiness (or category-appropriate subtype) JSON-LD block with name, address, telephone, url, openingHoursSpecification, and sameAs entries pointing to verified third-party profiles. Targets the Source Strength gap (§3.4) and the Technical Extractability gap (§3.5).

Where it installs

Pasted into the <head> of the homepage as a single <script type="application/ld+json"> block. Most CMSes accept this in a "head injection" or "custom code" field without theme edits.

What the model can write

Only the description string and the sameAs array, drawn from the scraped homepage and verified directory matches. Address, phone, and hours come from the intake and the structural skeleton.

What gets stripped

<script> tags inside string fields, on-event handlers, javascript: URLs, made-up review counts, and any sameAs URL that didn't appear in the scrape or in a verified directory match.

Worked example — Foster & Lin Law
  1. 01

    Sub-score gap: Source Strength = 0.41, below the 0.55 threshold. Skeleton selects LocalBusiness with the LegalService subtype based on the intake category.

  2. 02

    Site evidence injected: scraped homepage <title> = "Foster & Lin Law — Estate Planning Attorneys, Portland", scraped phone, scraped address, three directory matches (Avvo, Justia, Yelp).

  3. 03

    Model proposes a 142-character description summarizing the practice areas. Confidence: 0.86 (above the 0.70 description threshold) — fill accepted.

  4. 04

    Validation: a fourth directory URL the model wanted to add ("portlandlawyers.org") was not in the scraped or verified set — stripped. Final block ships with three sameAs entries and the description fill.

Crawler access § 4.2

robots.txt format
What it ships

A robots.txt block from the active ai-crawlers-2026-05 directive set covering OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Google-Extended, and the Bing/Brave provider agents your scan flagged as blocked or ambiguous. Targets the Visibility gap (§3.1) and the Technical Extractability gap (§3.5).

Where it installs

Pasted into /robots.txt at the site root. The block is additive — it does not remove or override existing User-agent directives, so an existing crawl policy is preserved.

What the model can write

Nothing. The directive set is fully deterministic — only the list of agents is selected, based on which crawlers were observed blocked, ambiguous, or untested in the scan probes.

What gets stripped

Any agent name not in the published ai-crawlers-2026-05 set, any Disallow rule the skeleton didn't generate, and any inline comments the model attempted to add. Directive sets are versioned and signed; off-version content fails validation.

Worked example — Foster & Lin Law
  1. 01

    Visibility probe found OAI-SearchBot and PerplexityBot returning 403 against the homepage; Google-Extended and Claude-SearchBot returning 200 but with a sitewide Disallow: / on a wildcard rule.

  2. 02

    Skeleton selects the four affected agents from ai-crawlers-2026-05; the other agents (already passing) are excluded so the block stays minimal.

  3. 03

    Block ships as 12 lines: four User-agent blocks each with Allow: / and a comment referencing the methodology version.

  4. 04

    Validation: a model-added "# helps with SEO" comment was stripped — directive-set version comments are the only inline comments allowed.

FAQ block § 4.3

FAQPage schema
What it ships

A FAQPage JSON-LD block with three to five buyer-intent questions and answers, paired with visible HTML so the content is both extractable and crawlable. Targets the Accuracy gap (§3.3) and the Source Strength gap (§3.4).

Where it installs

Visible HTML in a page section (typically homepage or services page); JSON-LD in the page <head>. Both must ship together — schema-only FAQ blocks are downgraded by Search and ignored by AI surfaces.

What the model can write

Question text and answer body, drawn from the scraped homepage, services pages, and intake. Answers must be 30–280 characters and quote the site evidence verbatim where possible.

What gets stripped

Any answer making a regulated claim ("we guarantee", "best in", certifications not in the scrape), any HTML inside answer strings, and any answer below 30 or above 280 characters. Stripped fields revert to a skeleton prompt asking the operator to fill them.

Worked example — Foster & Lin Law
  1. 01

    Accuracy gap: scans showed AI confusing Foster & Lin Law with a similarly named firm in Seattle. Skeleton selects four FAQ entries that disambiguate location and practice areas.

  2. 02

    Site evidence: scraped services page lists wills, trusts, probate, and small-business succession. Model drafts answers quoting these terms verbatim.

  3. 03

    Confidence threshold check: three answers above 0.75, one ("Do you offer free consultations?") below at 0.42 because the scrape was ambiguous — that field reverts to the skeleton placeholder.

  4. 04

    Validation: a "Best estate planning attorney in Portland" line was rewritten to drop the "best" claim. Final block ships with three filled answers and one operator-fill placeholder.

Source proof § 4.4

copy + link format
What it ships

A short footer or sidebar block linking to verified third-party profiles — directories, review sites, professional registries, certification bodies — exactly matching the sameAs array shipped in §4.1. Targets the Source Strength gap (§3.4) directly.

Where it installs

Footer of every page, or a "Verified on" sidebar on key landing pages. The same source links should appear in both the JSON-LD sameAs array and the visible HTML — AI weights corroborated signals more heavily than schema-only ones.

What the model can write

A one-sentence intro line ("Foster & Lin Law is verified on:") and the visible link labels. The list of URLs is deterministic — only directories that returned a verified profile match get included.

What gets stripped

Any directory URL that didn't return a verified match, any "as seen on" or "featured in" claim against a publication that didn't appear in the scrape, and any rating or star-count claim. Source proof is link-out only.

Worked example — Foster & Lin Law
  1. 01

    Source Strength scan returned three verified directory profiles (Avvo, Justia, Yelp) and one Oregon State Bar registry match. Skeleton ships a footer block with all four.

  2. 02

    Model drafts the intro: "Foster & Lin Law is listed and verified on:" — confidence 0.92, accepted.

  3. 03

    Validation: a "Featured in The Oregonian" line the model added was stripped (no scrape evidence). Final block ships four verified link-outs and one neutral intro line.

  4. 04

    The same four URLs are auto-synced to the §4.1 schema's sameAs array on dispatch — corroboration is enforced, not optional.

Location page § 4.5

HTML page format
What it ships

A standalone /locations/[city] page with structured location copy — address, neighborhoods served, directions, parking, hours — plus a Place JSON-LD block. Targets the Visibility gap (§3.1) for location-qualified buyer prompts.

Where it installs

As a new page in the CMS, linked from the homepage and footer. For multi-location businesses, one page per location. The skeleton also ships an internal-linking pattern so location pages are reachable from category pages.

What the model can write

Neighborhood and landmark copy, drawn from the intake's "areas served" field and any mapped directories. The address, hours, and phone come from the structural skeleton — those fields are never model-generated.

What gets stripped

Made-up neighborhoods, invented landmarks, "near [famous business]" comparisons that weren't in the intake, and any claim about transit lines or ZIP codes that wasn't verified. Stripped sections leave a clearly-marked operator-fill placeholder.

Worked example — Foster & Lin Law
  1. 01

    Visibility scan flagged location-qualified prompts ("estate planning attorney near 97205", "Pearl District wills lawyer") as appearing for competitors but not for Foster & Lin Law. Skeleton selects a /locations/portland page.

  2. 02

    Intake's "areas served" listed: Pearl District, Northwest, Goose Hollow, Beaverton. Model drafts neighborhood copy quoting these names verbatim — confidence 0.81, accepted.

  3. 03

    Validation: a model-added "near Powell's Books" line was stripped — no Powell's reference in the intake or scrape. Replaced with the operator-fill placeholder.

  4. 04

    Final page ships 312 words of location copy, a Place schema block, and four reachable internal links from the existing category pages.

llms.txt § 4.6

llms.txt format
What it ships

A /llms.txt file at the site root, structured as the proposed standard for AI-readable site summaries: business name, one-line description, primary URLs, and an indexed list of services or product categories. Targets the Technical Extractability gap (§3.5).

Where it installs

Uploaded to the site root, alongside robots.txt and sitemap.xml. AI crawlers that support the format read it before traversing the site; non-supporting crawlers ignore it harmlessly.

What the model can write

The one-line description and the per-URL summary lines, drawn from the scraped page titles and intake categories. The structural fields and URL list are deterministic.

What gets stripped

Any URL not in the scraped sitemap, any category not in the intake, and any superlative description ("best", "leading", "premier"). The standard rejects markdown beyond H1/H2/links, so any inline emphasis is normalized out.

Worked example — Foster & Lin Law
  1. 01

    Technical Extractability flagged Foster & Lin Law as having no /llms.txt while three of seven Portland peer firms ship one. Skeleton selects the standard layout.

  2. 02

    Site evidence: scraped sitemap returned 14 URLs across services, attorneys, contact, and blog. The four service pages are kept; blog index and contact are kept; remaining auxiliary URLs are excluded by the skeleton's "primary surfaces" rule.

  3. 03

    Model drafts a one-line description and seven per-URL summary lines. Six clear above 0.75; the "blog index" line clears at 0.71 — accepted.

  4. 04

    Validation: a "premier estate planning firm" phrase was stripped. Final file ships 11 lines of structured summary plus the skeleton header.

The full guardrail rule list — what the model can and cannot write across all six item types, and why each rule exists — is published as the SR-SANITIZE-001 spec.

No <script> tags inside string fields, no on-event handlers, no javascript: URLs.

Why. The Fix Pack is paste-and-ship — operators frequently install it without a separate review step. Any active code path inside a copy field is a vector for stored cross-site scripting; stripping it at generation time is the only way to make "paste this into your CMS" a safe instruction.

No branded invention — every name, claim, certification, and third-party reference must come from the intake or the scrape.

Why. If the Fix Pack invents a partner, an award, or a "featured in" claim, the operator ships a falsehood about their own business — and the Caboo Score becomes the source of the lie. Persisted fabrication breaks the methodology contract; stripping it preserves the contract.

No oversize content — strict byte limits per field, per item type.

Why. AI crawlers truncate at unpredictable byte boundaries; an oversize JSON-LD block can drop the very sameAs entries that drive Source Strength. Bounded fields are extractable; unbounded fields are coin-flips.

No regulated claims — guarantees, certifications, "best in", outcome promises, or comparative superiority.

Why. Many SMB categories (legal, medical, financial) are governed by advertising rules where regulated claims trigger compliance review. The Fix Pack must be safe to install in any of those categories without changing the model pack. Conservative copy is portable; regulated copy is not.

Below-threshold fields revert to skeleton placeholders, not to model best-guesses.

Why. A clearly-marked "operator fill" placeholder is honest and finishable; a low-confidence guess looks complete and gets shipped. The placeholder pattern keeps the install rate honest — the score's published acceptance rate counts only the fields that were actually filled, not the fields the model bluffed.

Fix Pack versioning

Signed v3.2

Every Fix Pack item is signed against the template version, the crawler-directive set, and the sanitization rule that produced it. The current set: template cms-fixpack-v1 · directive set ai-crawlers-2026-05 · sanitization rule SR-SANITIZE-001. New item types and rule changes ship through the same methodology committee that owns this document.

Document SR-FIXPACK-001 · cms-fixpack-v1 · ai-crawlers-2026-05 · SR-SANITIZE-001

§ 5.What we don't measure

The honest limits.

Most methodologies hide their limits. We lead with them — because the alternative is finding out from a buyer who already lost trust. Three things our score does not capture, plus how we handle each.

What individual users actually see.

AI assistants personalize based on memory, location, search history, account preferences, and account-tier model routing. Our scans test the layer that's measurable, repeatable, and comparable across businesses — not full consumer parity. A buyer in your ZIP with a long ChatGPT history may see different answers than our scan does. We document this on every dossier.

Model improvement over time.

Models improve every quarter. A score of 47 today may be 51 next month without your business changing — because newer models get better at finding small businesses. We address this through methodology versioning (§ Changelog, forthcoming) and by re-scoring historical scans against current weights when major changes ship.

Hallucinated business names.

If AI invents a fictional business with a name similar to yours or your competitors', we may count it as a competitor mention. We flag suspected hallucinations as "unverified" on the dossier rather than dropping them — that's a transparency choice. Future versions will cross-check against state business registries to catch them earlier.

Whether your business is good.

The Caboo Score measures findability and recommendation surface, not quality. A deeply-recommended business with terrible reviews is still going to lose customers; the score won't catch that. Quality is your customers' judgment. We don't approximate it.

§ 6.Signature

Maintained, signed, challengeable.

This methodology is owned by the Caboo Methodology Committee and is the document Caboo is held to whenever a score it produces is challenged. If you find a methodological error — a math mistake, a weight that's no longer defensible, a missing limit we should be acknowledging — we want to hear it.

Caboo Methodology Committee

Signed v3.2

Published May 1, 2026 · this methodology applies to all scans run on or after this date. Earlier scans were run against v3.1 and are marked warm when major weights change.

To challenge anything in this document, write to [email protected]. We respond within five business days. Substantive corrections are versioned and announced.

Document SR-METH-001 · v3.2 · May 1, 2026

Run your business through this methodology. Free, sixty seconds.

Run live scan →