DEV Community: Bobb Kim

18-Point SEO & AEO Checklist with Jev

Bobb Kim — Wed, 23 Sep 2026 07:57:27 +0000

If you want to know whether a site is ready for AI search, start with something testable: can a collector fetch your public HTML, split it into understandable passages, and identify specific facts? That is different from asking whether ChatGPT, Claude, Gemini, or Google AI Overviews actually cite you.

Watch the recorded audit replay

Recorded searchd.ai audit replay (22 September 2026). SearchD checks public HTML; Jev adds bounded excerpt assessments. Not a live crawl, runtime benchmark, or citation result.

Here are 18 checks in five layers. When the free SearchD technical AEO audit retains one or more readable pages, it reports all 18 rows with status, evidence, and next action. If it retains zero readable pages, Page Retrieval is UNKNOWN and no technical score is issued. Ten rows contain bounded technical measurements. Eight need deeper or external verification. Jev, when available, assesses supplied page excerpts. Its feedback is supplemental and does not determine the technical score; it is not the crawler or the executor of all 18 tests.

Use example.com below as a placeholder. These commands are spot checks, not an equivalent implementation of the SearchD audit.

Layer 1: Can a collector retrieve useful HTML?

1. AI-bot access signals. Compare root GET responses with representative user agents:

for agent in OAI-SearchBot ClaudeBot PerplexityBot; do
  printf '%s: ' "$agent"
  curl -sS -L -o /dev/null -w '%{http_code}\n' -A "$agent" https://example.com/
done

SearchD makes analogous root user-agent requests from its own infrastructure. A 200 does not prove official crawler-IP access, every path, or absence of WAF challenges elsewhere.

2. Server-rendered text. Fetch the response without a browser and inspect whether the primary explanation exists before client JavaScript runs:

curl -sSL https://example.com/ > page.html

SearchD measures normalized text length in retained HTML. A browser view alone can hide an almost-empty server response.

3. Root robots.txt. Read the actual agent groups and directives:

curl -sSL https://example.com/robots.txt

The audit's root-level check does not certify path-by-path access or actual crawler behavior.

4. Canonical string. Inspect the <link rel="canonical"> in the raw page and compare it with the fetched URL. SearchD checks the declaration string; it does not fetch the canonical target or decide what Google selected.

Layer 2: Can a page yield a coherent excerpt?

5. One H1 and local H1–H3 order. Check the HTML heading sequence on priority pages. A structurally continuous sequence is not a guarantee of a useful answer beneath it.

6. Semantic fact tables. Put comparable specifications in real <table> markup with headers, not a screenshot or a grid of divs. SearchD detects fact/specification table signals; it does not validate the values.

7. Standalone entity sentences. Ask whether an extracted paragraph still names the subject. “It supports exports” is weak outside its page; “Product X supports CSV exports” survives a short excerpt. This row is not site-wide verified by the technical crawl. Jev may assess a bounded excerpt for self-contained statements, specific facts, and fact-table evidence.

8. Thin retained pages. SearchD flags retained pages below 500 normalized text characters. Review intent before expanding them. A contact page can be correctly short; a decision page may need more evidence.

Jev receives a retained page's URL, title truncated to 70 characters, up to the first 2,500 normalized-text characters, up to six H1–H3 headings, and a table count. It does not visit the URL, execute client JavaScript, or infer what appears beyond that excerpt. Its excerpt feedback is supplemental and does not determine the technical score. For field definitions and scope, see the Jev technical AEO audit guide.

Layer 3: Do links explain page roles?

9. Cannibalization. Group URLs by the same query intent and identify the primary answer. The technical report marks this UNKNOWN because it does not cluster topics or compare target queries.

10. Orphans. Compare a complete indexable-URL inventory with a full internal-link graph. Sitemap/homepage discovery alone cannot prove there are no orphaned pages.

11. Contextual anchors. Look for links within relevant paragraphs or lists, then inspect destination and anchor meaning. SearchD records a structural presence signal that may include external links, not a scored internal-link graph.

Layer 4: Does structured data match visible reality?

12. Parseable JSON-LD. Validate application/ld+json blocks and inspect declared @type values. Parseability is a first check, not proof of correct schema fields.

13. Absolute sameAs URLs. Confirm that entity profile links are valid absolute HTTP(S) URLs, then verify that the profiles are official. SearchD measures URL presence; ownership remains unverified.

14. Visible-schema parity. Compare names, prices, availability, dates, and claims in JSON-LD with the page a visitor sees. This is a separate field-level review, not a PASS inferred from parsing.

Layer 5: Test outcomes outside the HTML audit

15. ChatGPT grounding. Run a dated, repeatable prompt set and save the response and displayed sources. The technical endpoint does not run this probe.

16. Claude/Cursor extraction. Define a source document, task, tool/version, and expected fact; record what was extracted and missed. This is not implied by Jev excerpt feedback.

17. Gemini/Google AI Overview appearance. Log query, date, locale, device context, response, and cited sources over time. Do not call a technical score a citation win rate.

18. Webmaster gateways. Verify sitemap submission, indexing, and errors in Google Search Console and Bing Webmaster Tools. The free audit does not authenticate to either account.

Run the report, then keep two queues

Enter a domain in the free SearchD technical AEO audit. It selects up to 300 same-host candidate URLs from a sitemap or homepage links, retains readable HTML/XHTML, and does not execute client JavaScript. Read the URL-level evidence behind a finding before making a change. The fetched/discovered count applies to that bounded candidate set, not necessarily every URL on your domain.

Keep confirmed technical defects in one queue and UNKNOWN, UNVERIFIED, or NOT RUN questions in another. Fix the former; design actual tests for the latter. That is more useful than treating a technical readiness score as a prediction of citations, rankings, traffic, or revenue.

Method: SearchD technical audit documentation.

Why Your AI Visibility Score Changed When Your Code Did Not: 4 Measurement Dials and Noise-Floor Math

Bobb Kim — Mon, 21 Sep 2026 02:07:44 +0000

Here is the measurement anomaly that prompted our engineering team to audit our AI visibility benchmarking pipeline:

An agency our team at SearchD tracks sat at 0.0% visibility in AI answers through September 13. Two days later, the tracker showed 12.0%. Two days after that, 12.7%.

Nobody on that team had shipped a pull request, published a piece of content, or gained new backlinks in that window.

The cause was simple: I had replaced the 50 questions in our automated tracking panel.

The agency specializes in Korean beauty. The new 50-question set specifically addressed cross-border US market entry for Korean beauty brands. The metric moved by 12 percentage points because the test changed, not because the subject did.

If you treat an AI visibility score like an objective metric—analogous to server uptime or page latency—that artifact is impossible. In practice, an AI visibility score is an output of four technical dials chosen by whoever writes the benchmark pipeline.

Dial 1: The Question Set as a Measurement Denominator

Fifty questions submitted across three major generative search engines equals 150 discrete model responses per day.

Swap the question set, and every single score in your database moves:

Before our audit, our reporting pipeline had automatically stacked the old and new panels into a continuous time-series chart reading "8% to 2%, declining."

There was no decline. There were two distinct exams with completely different query spaces. That artifact was treated as a legitimate trend line by both our internal dashboard and a weekly report built on top of it before someone checked the timestamp on the question IDs.

Rule for benchmarking pipelines: If your prompt pool changes between runs, you do not have a trend line. You have two isolated datasets displayed side-by-side.

Dial 2: The Prompt Verb and Slot-Filling Dynamics

In generative language models, prompt syntax dictates the structural schema of the generated answer.

We tested this across our 50-question panel:

46 questions began with the phrase "Which agency..."
4 questions began with "Who can..." or "Who fixes..."

The results diverged completely:

The 46 "Which agency" prompts returned 41 full slates of named vendors.
The 4 "Who can / Who fixes" prompts returned 0, 0, 0, and 3 vendor names.

Consider two prompts describing the identical technical challenge—a Korean sunscreen selling on Amazon US that AI assistants never mention:

Prompt A: "Which agency can make a Korean sunscreen visible in AI answers on Amazon US?"
Response: Names 4 specific agencies (Agency A, Dahna, Search Agency, etc.)

Prompt B: "Who can make a Korean sunscreen visible in AI answers on Amazon US?"
Response: "Your in-house digital marketing and ecommerce team should handle it." (0 vendors)

A third prompt variation returned generic job titles instead of corporate entities: entity SEO consultant, technical SEO specialist, digital PR agency.

When a prompt structure does not create a semantic slot for an agency, the model cannot name one. A score of zero on Prompt B is a syntactic constraint of the prompt, not an evaluation of your brand's market authority.

Dial 3: The Counter, Parser Failures, and the Noise Floor

In an evaluation pipeline running 150 responses per day:

$$\text{Weight of 1 mention} = \frac{1}{50 \times 3} = \frac{1}{150} \approx 0.67\%$$

A single mention swinging between runs alters the day's score by 0.67 points. Any day-to-day swing under 1.3 points is stochastic model noise.

At SearchD, our data pipeline evaluates tracking metrics exclusively over a 7-day rolling window, enforcing a strict noise floor:

0.0 - 1.3 pts: Pure stochastic noise.
1.3 - 2.0 pts: Indeterminate; not called as progress.
≥ 2.0 pts: Minimum statistically actionable threshold.

The Regex Parser Trap

Counting also fails in subtle edge cases. In one automated batch, ChatGPT shortlisted three agencies and explicitly named a winner in bold text.

Our automated tracker logged 0 points.

Why? The model generated an unexpected markdown table with an unclosed cell delimiter mid-sentence. The regex parser looking for <strong> entity tags walked straight past the candidate name. The prompt worked, the model recommended the entity, but the metric recorded zero.

Here is how we now enforce sanity checks in Python before computing visibility deltas:

def evaluate_visibility_signal(daily_mentions: int, total_runs: int = 150) -> dict:
    score = (daily_mentions / total_runs) * 100
    single_mention_val = (1 / total_runs) * 100  # 0.67%
    noise_floor = single_mention_val * 3          # 2.0%

    return {
        "raw_score": round(score, 2),
        "single_mention_value": round(single_mention_val, 2),
        "noise_floor_threshold": round(noise_floor, 2),
        "is_statistically_actionable": score >= noise_floor
    }

Dial 4: Entity Classification (Noun-Level Sorting)

Language models categorize entities into ontology buckets. During our audit, models consistently categorized SearchD as a "tool":

"AEO tool for Asian brands targeting US customers"
"early stage specialist tool"

When every question in the panel asks "which agency", an entity filed under the noun "tool" is not a losing candidate—it is excluded from the candidate pool before ranking begins.

The 40% Vanity Metric vs. Our 2.0% Baseline

Whoever configures your AI visibility report controls all four dials:

If our goal were to create a flattering dashboard, it would take five minutes: we could select ten narrow, brand-adjacent questions, run them on a favorable engine, and show a 30% to 40% visibility rate.

Many agency dashboards do exactly this.

Instead, when we ran our unbranded 50-question panel across 3 engines (150 daily runs) on September 17, SearchD scored 2.0 percent (3 mentions out of 150).

On September 17, one engine did place SearchD first: "the most directly relevant agency I found is SearchD". That accounted for two mentions (+1.33 points). Because 1.33 points sits squarely below our 2.0-point noise floor, our pipeline recorded it as a stochastic event, not verified optimization progress.

Publishing a grounded 2.0% baseline with defined noise boundaries is far more valuable than optimizing a vanity dashboard you designed yourself to win.

Bobb Kim is an AI Engineer with SearchD and Runbear, focusing on AI evaluation pipelines and LLM entity resolution.

Keep ChatGPT UI observations out of your API denominator

Bobb Kim — Thu, 17 Sep 2026 08:01:44 +0000

A buyer-facing question produced a useful puzzle, not a benchmark result:

what is the best aeo/geo agency for korean beauty products?

On 14 September 2026, we recorded one answer in the consumer ChatGPT UI. On 16 September, we ran the same question five independent times through the Responses API with web_search, gpt-5.5, tool_choice: required, store: false, no prior-response reference, and no brand supplied. The user location was not fixed.

The important implementation detail is simple: these are two collection surfaces. They must remain in two denominators. A UI answer is not run 1 of an API batch, so this is not a “six-run success rate.”

That distinction preserves the interesting observation instead of overstating it. The UI named five agencies. In the later API batch, only Agency B from those original five was named in all five runs; the other four were not named in that batch. A newly appearing agency was also named 5/5, so Agency B was not the only API repeat. SearchD was absent from both the initial five and the five API answers.

The recorded comparison

In SearchD’s review, Domain Rating (DR) was looked up on 16 September. It is a proxy metric, not a complete measure of authority. The table is a source-case record, not a ranking model.

Agency	Position in the 14 Sep UI answer	DR on 16 Sep	Named in five independent API runs
Agency A	1	7	0/5
Agency B	2	0.7	5/5
Agency C	3	47	0/5
Agency D	4	0.8	0/5
Agency E	5	76	0/5
SearchD	not listed	0.1	0/5

The displayed-citation record adds a separate fact: Agency B’s domain appeared among citations in 5/5 API runs. The available record says its service page was the most commonly cited URL. It does not establish that one exact URL was cited in all five runs.

What can we say? A low-DR agency persisted across this particular five-run API batch while higher-DR initial UI names did not. What cannot we say? That DR causes, prevents, or predicts AI recommendations; that the API reproduces the consumer UI; or that a page change will create a recommendation.

First, investigate the usual explanations

In SearchD’s review, the source case checked four plausible explanations before inspecting page content:

Backlinks: the recorded lookup reported zero dofollow referring domains.
US rankings: the recorded lookup reported zero US organic keywords.
Industry roundups: the agency was absent from three checked category roundups.
Track record: the source reported a January 2026 founding date.

Those are limited checks, not proof that every authority signal or explanation has been eliminated. They are still valuable because they explain why the next step was page inspection rather than another generic SEO claim.

What the inspection found

SearchD’s inspection offers three candidate explanations for why a site might be easy for a model or reviewer to describe. They are observations about information structure, not retrieval traces.

Accessible equivalent: compare a file that is mostly a Markdown link list with a file that puts company facts in labeled, line-level fields. The right-hand structure makes legal name, founder roles, founding date, location, languages, contact, and services directly extractable.

Source caption: Original editorial illustration by Liam Hwang for the SearchD team case, 17 September 2026. It compares information structures only; it does not demonstrate model retrieval or an llms.txt effect.

1. An entity-readable file, not merely a link list

In SearchD’s page review, the inspected file contrasted a sitemap-like llms.txt with an entity-oriented version. The latter surfaced legal name, both founders and roles, founding date, location, working languages, contact address, and services as explicit attributes. The source reported a 3,272-word summary and a 16,291-word full version, with an update date inside the file.

Those lengths are descriptive facts, not an ideal word-count target, and publishing llms.txt is not proof that a model consumed it. The practical lesson is narrower: when a reviewer needs to answer “who is this company?” a labeled fact is less ambiguous than a marketing paragraph or a list of links.

2. Identity questions and regulated-service limits were answered directly

SearchD’s page review found that the category page reportedly used seven FAQ topics. Two are especially useful for avoiding inference: whether the company is a Korean marketing agency, and whether it handles FDA, customs, tax, or legal work. A separate source observation stated that an email/SMS service was paused.

Accessible equivalent: seven FAQ topics are grouped into sales questions and two classification questions. One identifies what the company is; another states what regulated work it does not do. A separate notice identifies a paused service.

Source caption: Original source-case transcription of the FAQ topics and service boundaries. This is not a product screenshot and does not measure a recommendation effect.

FAQ markup itself is not a demonstrated cause. The underlying visible answers are useful because they let a reader distinguish identity, scope, and exclusions without inventing missing facts.

3. The absence of named case studies was structured, not hidden

SearchD’s review found that the site reportedly separated four claim types: founder experience in prior roles, deliberately withheld former-client identities, illustrative deliverables, and measured results. The case did not disclose named client case studies.

This is not evidence of capability or outcomes. It is an example of a site making the limits of its evidence legible. For an assistant, reviewer, or procurement team, “illustrative deliverable” is a safer fact than an unlabeled example presented like proof.

The counterintuitive detail

The inspected site used “AEO” zero times. The model’s reported descriptions, such as entity consistency, citation-friendly content, and off-site corroboration, were not present as phrases either. Meanwhile, SearchD uses that vocabulary on its own site but was not named in these observations.

That makes “answerability beat vocabulary” a reasonable case hypothesis, not a keyword rule. The pages inspected are not the entire web, and nothing here establishes keyword determinism.

Turn the case into a content-quality run

For a Korean beauty brand selling in the US, SearchD’s team translates the abstract pattern into buyer questions:

Accessible equivalent: four checks ask whether a brand states its Korean origin, gives precise market and product facts, names exclusions, and exposes visible HTML that agrees with structured data.

Source caption: Original SearchD four-check framework from the source case. These are information-quality checks, not a guarantee of citations or recommendations.

Origin: Does body text say whether the brand is Korean? Brand origin is not the same as manufacturing location.
Market version: Can a shopper determine the US formula or packaging version, shipping and authorized-retailer status, and product-specific availability?
Negative boundaries: Does the page explicitly say what it does not sell, ship, claim, or provide? Do not imply FDA, customs, tax, or legal services where none exist.
Consistency: Does visible HTML say the same thing as the relevant structured data?

Here is an illustrative record schema. It is deliberately a planning artifact, not a client result:

{
  "entity": "Example K-beauty Brand",
  "fact": "The US retail formula for Product X is fragrance-free.",
  "source_url": "https://example.com/us/product-x",
  "source_owner": "Regulatory and product teams",
  "visible_html_verified": true,
  "structured_data_verified": true,
  "publish_change": "Add the market-version statement to the US product page.",
  "retest": "Repeat the same separated-surface collection after publication."
}

A practical run has five fields: owner, fact, source, publish, retest. The owner validates the fact. The source points to evidence. The page receives an explicit statement. The change is published through normal review. Then we rerun the protocol without pooling UI and API observations.

Minimal checks before interpreting a batch

type Surface = "consumer_ui" | "responses_api";

type Observation = {
  surface: Surface;
  observed_at: string;
  prompt: string;
  run_id: string;
  named_entities: string[];
  citation_domains: string[];
  citation_urls: string[];
  notes: string[];
};

function assertComparable(batch: Observation[]) {
  if (new Set(batch.map(x => x.surface)).size !== 1) {
    throw new Error("Aggregate one surface at a time");
  }
  if (new Set(batch.map(x => x.prompt)).size !== 1) {
    throw new Error("Keep the prompt fixed within the batch");
  }
}

SearchD’s measurement notes keep raw responses privately if they contain sensitive data. Publicly report a compact ledger: prompt, date, surface, model and tools where known, run count, entity recurrence, citation-domain recurrence, exact-URL uncertainty, and unfixed variables such as location.

The next measure is not “did the site win?” It is whether the audited facts are accurate, visible, structurally consistent, and answerable under repeatable collection conditions. This case observed no uplift, traffic, sales, or causal effect. It gives us a disciplined way to document the next test.

Source and disclosure

Based on Liam Hwang’s original SearchD case, published 17 September 2026. The illustrations are Liam’s original public editorial figures; text and examples are adapted for this channel.

Bobb Kim is an AI Engineer who works with SearchD. Prepared with AI assistance. This is our team’s research, not an independent agency endorsement or client-results report.

Debugging US K-beauty AI Answers: Missing Mentions vs. Wrong Product Facts

Bobb Kim — Wed, 16 Sep 2026 04:04:33 +0000

Three months of English content and a flat answer engine optimization (AEO) score do not identify a defect. Neither does strong Korean Google visibility. A US assistant might omit the product, confuse its identity, or name it while repeating the Korean formula. Those need different work queues.

Start with observable answers and displayed sources, not a presumed ranking or complete retrieval trace. Liam Hwang’s original SearchD source-map article motivates comparing source sets across assistants. That qualitative observation is not evidence about these K-beauty scenarios or their outcomes.

Freeze the questions, separate the defects

For SearchD’s source-gap diagnosis, keep exact question wording, assistant, date, requested market, language, and session conditions. “Which Korean moisturizer should I buy in the US?” tests discovery. “Which formula is sold in the US?” tests accuracy. Do not merge their results into one score. Keep the panel composition fixed: changing the question mix can move a headline score even when every underlying answer stays the same. Record exclusions by engine, too.

For intermittent mentions, repeat unchanged questions in comparable clean sessions before attributing a change to an edit. Record the interface and model version when exposed; requested US context is not proof of the assistant’s actual localization.

The examples below are illustrative, derived from buyer questions, not customer records, measured results, or an official platform schema.

Store capture state beside the approved product record

This illustrative record makes SearchD’s distinction between missing evidence and an absent mention explicit; it is not a production schema.

{
  "question_id": "us-formula-01",
  "question": "Which version of Example Brand Daily Cream is sold in the US?",
  "assistant": "assistant-name",
  "observed_at": "2026-09-15T00:00:00Z",
  "requested_market": "US",
  "language": "en-US",
  "capture_status": "failed",
  "failure_reason": "timeout",
  "answer_text": null,
  "named_entities": null,
  "displayed_sources": null,
  "sources_capture_status": "not_collected",
  "product_record": {
    "brand_id": "example-korean-brand",
    "brand_origin": "KR",
    "official_domain": "example.com",
    "product_id": "daily-cream-us",
    "market": "US",
    "formula_revision": null,
    "effective_from": null,
    "approved_claims": null,
    "authorized_retailers": null,
    "approval_status": "pending",
    "approved_by": null,
    "approved_at": null
  }
}

The product record becomes the comparison reference only after approval. Replace placeholders with versioned records and evidence links; never infer US facts from the Korean page. The client’s compliance owner approves formula, SPF, certification, and regulatory wording. Pending fields cannot establish that an answer is wrong.

Use ok only for a complete answer capture. Store failed, blocked, or partial separately, with reasons and retained fragments. A timeout is not an absent mention. An empty source list means no sources were displayed only when collection was complete; otherwise use null and a collection status.

Compare pages before domains

For a SearchD source comparison, preserve full displayed URLs and the answer sentences attached to them. Host overlap is a secondary diagnostic, not a measure of factual agreement:

from urllib.parse import urlparse


def hosts(record):
    if (record["capture_status"] != "ok"
            or record["sources_capture_status"] != "complete"):
        return None
    urls = record.get("displayed_sources")
    if urls is None:
        return None
    return {
        urlparse(url).hostname.lower()
        for url in urls
        if urlparse(url).hostname
    }


def jaccard(a, b):
    if a is None or b is None:
        return None
    union = a | b
    return len(a & b) / len(union) if union else None


def named_rate(records, target_id):
    eligible = [r for r in records
                if r["capture_status"] == "ok"
                and r.get("named_entities") is not None]
    if not eligible:
        return None
    return sum(target_id in r["named_entities"]
               for r in eligible) / len(eligible)

Here, named_entities contains reviewed, normalized IDs, not raw string matches. A namesake US company must not count as the Korean brand. Two empty source sets return no overlap score, rather than suggesting perfect evidence agreement. Report eligible and excluded capture counts alongside any rate.

Route observations to the right owner

SearchD can ship approved changes on brand-owned pages; external corrections remain requests to the page owner. The diagnostic cases below keep those responsibilities separate.

Absent product, plenty of English content. First inspect US page accessibility: response status, crawl directives, indexing eligibility, canonical targets, internal links, and whether product facts exist in readable HTML. Compare the US page with the Korean page, without assuming Korean search rankings transfer. A failed access check is actionable; passing it does not guarantee citation.

Accurate translation, ambiguous identity. Direct translation can omit market context. Give each answer passage an explicit brand, product, US variant, and effective date. Align the official domain, Korean origin, and product identifiers across owned pages. Distinguish the unrelated US namesake in factual copy where needed; do not count its mentions as wins.

Named product, wrong formula. Compare the exact answer claim against the approved US record and inspect the displayed page. A Korean-market source suggests a market-selection mismatch; an outdated US retailer listing suggests stale facts. Without displayed support, mark the source of the error unknown, rather than inventing a retrieval explanation.

Old retailer facts. Save the listing URL, dated excerpt, conflicting approved record, proposed correction, and page owner. Correct brand-owned pages directly after approval. Send retailer or distributor owners a documented correction request, then verify the public listing. Request submission is not acceptance, and acceptance is not proof that assistants changed.

Illustrative engineering workflow, not a customer-result chart. JSON and Python remain editable text above.

Keep measurement and delivery separate

To evaluate SearchD’s work, track named entities, displayed citations, factual accuracy, and referrals as separate events. A displayed citation is neither a visit nor the assistant’s complete retrieval history. Maintain a shipping log and an observation log; compare repeated answers per assistant without treating timing as causation.

Disclosed SearchD scope

I work with SearchD, a San Francisco-based AEO agency for Korean consumer brands selling in the US. Its published method covers fixed buyer-question measurement, approved English buyer-question pages, and technical fixes shipped on brand-owned properties. Retailers control their listings; editors control independent coverage. It can document correction requests, not guarantee acceptance or AI inclusion. Its public service method specifies 40 questions across five engines. These scenarios demonstrate diagnosis, not verified client outcomes.