How QueryBurst Researches and Models AI Search

QueryBurst does not have privileged access to the internal architecture of ChatGPT, Google AI Mode, or other proprietary AI systems.

Neither does anyone outside those companies.

Our research starts from what can actually be observed: network behaviour, visible queries and sources, retrieved content, system outputs, repeated experiments, and changes in behaviour under controlled conditions.

From there, we develop plausible explanations for what may be happening inside the parts we cannot see.

But a plausible explanation is not enough.

When QueryBurst develops a hypothesis about how an AI-search system may be behaving, we try to build it.

We implement the mechanism, run it against real examples, compare the outputs with the system we are trying to understand, and refine the model until it reproduces the observed behaviour closely enough to be useful.

Sometimes the hypothesis survives.

Sometimes it does not.

When it does not, we change it.

That distinction — between what we can observe, what we infer, and what we currently model — is fundamental to how QueryBurst approaches AI-search research.

We start with observable behaviour

Some parts of AI-search systems can be observed directly.

Depending on the system and test, this may include:

• search queries or fan-outs
• network requests and response payloads
• retrieved URLs
• source and citation behaviour
• page transformations
• frontend traces
• differences between account, context, model or session states
• repeated changes caused by controlled modifications to an input

These observations are evidence.

They are not automatically explanations.

If a frontend trace contains a relevance score, for example, we can establish that the score exists by the point at which it appears in that trace.

That does not necessarily tell us where it was generated, what representation it was scored against, what earlier ranking stages occurred, or whether other backend steps were omitted entirely.

QueryBurst therefore separates what was observed from what we think may explain it.

Observation becomes useful when it generates a testable hypothesis

The interesting part of research is usually not discovering that some internal-looking field, query, score or object exists.

It is asking what could have produced it.

A hypothesis might be that:

• an AI system forms an answer-shaped prior before retrieval
• previous conversation state influences later search fan-outs
• retrieved passages are scored against a transformed representation of the user's question
• a system is attempting to locate an authoritative site when confidence in a domain is weak
• only a subset of retrieved evidence survives into grounding
• a particular page transformation is designed to remove non-semantic noise before retrieval

Those explanations may be right.

They may also be wrong.

QueryBurst does not treat a plausible mechanism as established merely because it sounds technically reasonable.

We try to make it fail.

We build the hypothesis and compare the outputs

QueryBurst contains working implementations of many of the systems involved in modern search and retrieval: lexical retrieval, semantic retrieval, hybrid methods, reranking, chunking, query expansion, evidence selection, entity extraction, retrieval over structured and unstructured content, and several proprietary retrieval approaches developed during our own work.

That means a hypothesis does not have to remain a paragraph in an article.

We can turn it into a working system.

The usual process is:

observe → hypothesize → implement → compare → refine

We build a plausible version of the mechanism, run it against the same or equivalent inputs, and compare the resulting behaviour with the external system.

If the outputs are materially different, we change the model.

If a different explanation fits better, we replace it.

If several mechanisms can explain the same observation, we do not claim that one has been proven simply because our implementation works.

The objective is not to recreate proprietary source code.

The objective is to build an operational model that explains the observable behaviour well enough to investigate it.

A working model is not proof of architectural identity

This distinction matters.

If QueryBurst can reproduce a behaviour seen in ChatGPT, that does not prove ChatGPT uses the same implementation.

Different architectures can produce similar outputs.

A semantic retriever, a hybrid retriever and a reranking system may all surface similar passages for the same query.

A model instructed to generate search queries in a particular way may reproduce the behaviour of a proprietary system without sharing its internal prompt or control logic.

QueryBurst therefore treats a successful reproduction as evidence that a mechanism is plausible and useful, not proof that it is architecturally identical to the target system.

That is why our current models are allowed to change.

They are supposed to.

Sometimes the model is behavioural rather than architectural

Not every useful hypothesis needs to claim a hidden algorithm.

In some cases, the most appropriate model is simply one that reproduces an observed behaviour.

For example, QueryBurst has modelled search fan-out behaviour by instructing the system to generate site: searches in circumstances where ChatGPT was observed doing so.

When the system appeared uncertain of the exact official domain, the model was allowed to add terms such as official or make a best-effort domain guess.

That does not mean we claim ChatGPT contains those exact instructions.

It means those instructions reproduced behaviour we had observed closely enough to let us study what happened downstream.

This distinction is important:

QueryBurst models behaviour where behaviour is observable, and proposes mechanisms only where the evidence supports proposing one.

Controlled testing matters more than a single interesting output

Many QueryBurst research projects begin with a simple observation.

The next step is usually to construct conditions under which the explanation should either continue to hold or break.

Our research into how ChatGPT receives webpage content, for example, did not stop at looking at one retrieved page.

We changed page content, moved information into different parts of the document, tested visible and hidden elements, altered markup, and compared what survived retrieval.

Likewise, when investigating retrieval and evidence selection, we have repeatedly compared:

• pages that were retrieved against pages that were not
• passages selected against passages rejected
• clean-session behaviour against contextual behaviour
• model outputs before and after introducing new evidence
• simulated retrieval against external-system results

A result that survives repeated attempts to break it is more useful than one interesting screenshot.

It still remains scoped to the system, model, date and conditions under which it was tested.

We do not assume “magic”

When QueryBurst encounters an impressive or unfamiliar AI-search behaviour, our first assumption is not that the system has discovered some entirely new mechanism.

It may have. Architectural advances happen.

But more often, apparently novel behaviour is built from familiar components: retrieval, ranking, filtering, transformation, caching, query expansion, reranking, structured data, model instructions, or combinations of those things.

So our starting question is usually:

What known mechanisms could plausibly produce this behaviour?

Then we test them.

That mindset is one reason experience in search and retrieval matters. If you already understand the underlying components, something that looks opaque from the outside often becomes a tractable engineering problem.

Reverse engineering also means discovering when your own explanation is wrong

One of the most useful outcomes of research is finding out that the model you built does not explain the real system.

Our work reverse engineering Exa's Highlights system is a good example.

We developed an initial explanation for how the system appeared to work based on their published demo, and implemented a version of it. That version successfully reproduced what the demo showed.

Before publishing the conclusion, we compared that model against Exa's actual API.

The comparison revealed that the demo was misleading. Exa's API did not produce the kind of sub-sentence, clause-level extraction the demo appeared to show. The demo ran against their own documentation page, where section boundaries happened to look like intelligent clause-level highlights. On real prose — reviews, guides, educational content — the API returned section-level blobs.

So we changed direction. Instead of trying to match what the demo showed, we built what the demo claimed to do: adaptive routing that understands the difference between headings that are answers and headings that point to answers, with genuine clause-level and triple-level extraction across the full page.

The result outperformed the original system on unstructured content. The Exa CEO subsequently started following the research on LinkedIn, and a competing CEO reached out for consulting.

That is not a failure of the research process. That is the research process working — the comparison step caught a misrepresentation, and the refinement step produced something better than the original target.

QueryBurst distinguishes observation, inference and operational model

To avoid collapsing different levels of certainty into one claim, we use several distinct concepts.

Observation Something directly visible in an external system under stated test conditions.

Replicated observation A behaviour repeated across multiple runs, environments, models or independent tests.

Inference A conclusion suggested by the observations but not directly visible.

Hypothesis A proposed mechanism capable of explaining those observations and generating further tests.

Operational model A hypothesis implemented inside QueryBurst so that its consequences can be inspected and tested.

Demonstrated mechanism A causal mechanism established directly rather than merely inferred from compatible behaviour.

Revised or superseded A previous explanation changed because later evidence provided a better account.

Unknown Something the available evidence does not allow us to establish.

Not every QueryBurst claim belongs at the same level.

We consider stating the level of evidence part of the research, not an optional disclaimer.

What validates an operational model?

QueryBurst does not consider a model useful merely because it runs.

A useful model should:

• reproduce the behaviour it was designed to explain
• remain comparable across more than one cherry-picked example
• survive reasonable counterexamples
• make predictions that can be tested
• help distinguish between competing explanations
• produce useful differences when an input is changed
• remain open to replacement when new evidence appears

The closer the model gets to the observed system, the more useful it becomes for investigation.

But behavioural similarity should not be confused with proof that the hidden implementation is identical.

Answer Engine is built on this same methodology

QueryBurst Answer Engine applies the same research philosophy operationally.

Users model the customers and research journeys they want to investigate.

QueryBurst then models the process that produces each answer: the model's prior position, evolving conversation state, fan-out and discovery, retrieval, evidence selection, grounding and final response.

Those stages are inspectable inside the Answer Engine run.

They are not presented as privileged access to ChatGPT's proprietary internals.

They are QueryBurst's current operational model of the process, informed by observed behaviour and continually refined as the systems we study change.

That distinction is deliberate.

Prompt tracking records the endpoint.

QueryBurst builds a testable model of the process leading to it.

What QueryBurst does not claim

QueryBurst does not claim that:

• its retrieval stack is identical to ChatGPT's
• a frontend network trace exposes every hidden backend stage
• a successful reproduction proves architectural equivalence
• a single experiment proves a universal AI-search mechanism
• all AI systems use the same retrieval process
• behaviour observed today will remain unchanged indefinitely
• every hidden mechanism can currently be inferred from external evidence

Where we do not know, we would rather say unknown than manufacture certainty.

Experience helps generate better hypotheses. It does not prove them.

QueryBurst founder David McSweeney has worked in search, programming, technical SEO, content and web systems for close to three decades.

That experience is useful when looking at an unfamiliar retrieval system because many apparently novel AI-search behaviours have direct parallels in information retrieval, search ranking, document processing and web infrastructure.

It helps us generate plausible hypotheses quickly.

It does not exempt those hypotheses from testing.

QueryBurst research has been cited, quoted and discussed widely across the search and AI-search industry, but external attention is not what makes a result valid.

The test is whether the evidence supports the claim.

Our position

AI-search systems contain important components that remain hidden.

That does not mean the only options are blind speculation or watching the final answer.

We can observe behaviour.

We can form hypotheses.

We can implement them.

We can compare their outputs with real systems.

We can try to break them.

And when a better explanation emerges, we can change the model.

That is the basis on which QueryBurst researches AI search.

We do not publish mechanisms because they sound plausible. We build them, test them, compare them against observed systems, and revise them when they fail.