Regional Case Library Framework

Illustrative entries only. The examples on this page demonstrate a future case-record structure. They are not client work, measured outcomes or evidence that the named scenarios occurred. Labels marked ILLUSTRATIVE must not be cited as real events.

Why a case library matters

Enterprise teams learn as much from documented failure modes as from headline “wins.” A case library makes intervention, confounders and comparison limits visible—so readers can judge transferability to their market rather than copying tactics from a decontextualised anecdote.

AI Search Asia will publish real cases only when they meet the threshold at the bottom of this page. Until then, illustrative cards show the record shape we intend to use across Hong Kong, Singapore, Japan and Taiwan workstreams.

Proposed case record

ContextMarket, language, sector, journey family, observation window, interfaces tested

QuestionThe uncertainty investigated—not a promised outcome or implied client goal

BaselineRegistered prompts, coding summary, source map before intervention (if any)

EvidencePrompt register excerpts, source records, coding decisions, exclusions and reviewer notes

InterventionDocumented content, metadata or governance change—with owners and dates; “no intervention” is valid

OutcomeObserved change with comparison limits, confounders and interface changes noted

TransferabilityWhat generalises vs what was market- or interface-specific

Illustrative case cards

ILLUSTRATIVE · HONG KONG

Bilingual entity mismatch

A hypothetical regulated-services group audits inconsistent English and Chinese entity descriptions across corporate, subsidiary and microsite properties. Intended lesson: resolve identity and statutory disclosures before measuring citation counts; language-switching prompts surfaced different domains for the same query family.

ILLUSTRATIVE · JAPAN

Distributor mistaken for manufacturer

A hypothetical industrial buyer journey tests role clarity across Japanese and English sources for the same equipment category. Intended lesson: validate entity relationships and role labels before interpreting recommendations as manufacturer endorsements.

ILLUSTRATIVE · SINGAPORE

Global claim, weak regional proof

A hypothetical regional-HQ procurement review traces “ASEAN support” statements to operating evidence. Intended lesson: code applicability separately from source authority; a strong .com citation may still fail the buyer’s contracting question.

ILLUSTRATIVE · TAIWAN

Specification summary without datasheet support

A hypothetical technical buyer compares process capabilities where marketing pages generalise parameters stated narrowly in PDF evidence. Intended lesson: prioritise specification libraries and version IDs in governance, not FAQ edits alone.

How illustrative cases differ from published cases

Illustrative entries are labelled throughout, use hypothetical organisations and include no observation timestamps or verifiable prompts. Published cases will link to registered prompt IDs or redacted public-source equivalents, name the collection window and disclose permissions.

Publication threshold

A real case will require at least one of: documented permission from the participating organisation, or a fully public-source basis reproducible by third parties. It must include reviewable evidence, dates, limitations, answer-system scope and an unambiguous label (client, anonymised public-source, or desk observation). Anonymous cases must still preserve enough methodological detail to be useful—otherwise they remain internal.

Propose a public-source case or methodological replication via the research desk.