Evidence starts with the claim
We separate stable definitions, platform procedures, technical data models, regulatory rules, product behavior, and measurements from our own runs. Each type needs different evidence. A menu path should come from the platform that owns the interface. A field definition should be supported by that platform's published model. A legal rule should link to the law or regulator that issued it. A result from a MisMatchMaker scan must come from the recorded run and include its sample and limits.
Official platform documentation is the first choice for claims about how a partner portal, listing, or integration works. Regulators, standards bodies, and primary legal texts are used for rules and definitions. Original datasets are used for measured results. Secondary sources can add context when the primary record is incomplete, but they do not become proof of a platform mechanic that the platform itself has not documented.
The published source index lists the unique source pages used for retained factual claims. The relevant guide remains the place to read the exact supported wording and the limitation attached to that claim.
A repeatable evidence review
A page begins with a reader's task and a precise question, not with a target number of words or a list of search terms. Before drafting, we check whether an existing route already answers the same job. If it does, we improve that page or define a genuinely different question instead of creating a near-duplicate.
- 1. Write the exact statement. Break a paragraph into claims a reader could verify independently. “The portal changes this field” and “the change appears within six hours” are separate claims and need separate support.
- 2. Find the source that owns the fact. Use a platform's own help or developer documentation for its behavior, the law or regulator for a legal rule, and the retained run record for an internal measurement. A source that discusses a related topic is not automatically evidence for the proposed sentence.
- 3. Record scope before writing around it. Capture the source URL, publisher, access date, supported wording, and limits. Preserve the account, country, property, booking, field level, or time-window condition whenever it affects what the source establishes.
- 4. Choose wording no broader than the evidence. Separate what a source states from what we infer. If the distinction is useful, mark the inference as such and explain its basis. If support is missing, narrow the sentence, label an example as hypothetical, or leave the claim out.
- 5. Recheck the route a reader will land on. Before an indexable page is released, check its title, description, canonical, visible heading, structured data, internal links, and crawlable rendered content. The review checks that the page answers a distinct operator question without sending a reader to an unsupported result.
We publish the boundary with the fact
A source can support one narrow statement without supporting the broader conclusion a reader might draw from it. A partner API describes its own data contract; it does not establish every button an operator sees in an account. A documented change window for photos does not set the publication time for policies. An absent field in one schema is evidence about that schema, not proof that no platform can collect the fact in another way.
We make these distinctions visible near the claim. If a navigation path is not published in a public help article, we label it undocumented instead of guessing. If a platform's terms vary by account, country, property configuration, or booking, we say so and direct the reader to the relevant account record. If an automated request could not read a listing, that is reported as missing access evidence, not as evidence that the listing has no mismatch.
Guides are written for hotel operators. They explain the property-content job at hand and keep it distinct from rate parity, rate shopping, channel management, or legal advice. Where a topic depends on local law or a negotiated contract, the guide identifies that boundary instead of treating a general page as a substitute for either.
When a source does not answer the question
A blocked, outdated, or incomplete source is a research result. We do not fill an unavailable partner page from search-result snippets, old screenshots, or a plausible menu name. Where a platform does not publish a path, an operator guide says that the path is undocumented and gives a safe next step only when a supported one exists.
Absence claims have a narrow test. If a published schema or reference omits a named field, we can report that the field was not found in that source on the review date. We cannot use that absence alone to say the platform has no way to collect the information: a different product, account workflow, free-text field, or partner integration may not be represented in the document we reviewed.
If a page depends on evidence that is not retrievable, we defer it or change its scope until a reader can still get a useful and defensible answer. A complete set of blank citations would make a page longer without making it more trustworthy.
Measured results and illustrative examples stay separate
A measured result includes the population we actually observed, the time window, the selection method, the usable sample, and any channel coverage limits. A single city or one-day scan is described as that run; it is not promoted as a rate for all hotels or all markets. When a channel could not be read often enough to compare, the page withholds the comparison rather than filling the gap with an estimate.
Examples used to explain a report or calculation are labeled illustrative when they do not come from a measured customer result. We do not invent hotel outcomes, customer quotations, sample sizes, rankings, commission averages, or conversion lifts. Calculators use the values entered by the visitor and state what their arithmetic does and does not include.
The consistency-study hub publishes the sample rules, definitions, and limits for its city studies. The separate scanner methodology explains the supported fields and how evidence becomes a comparison.
Platform and product changes trigger a review
Portal interfaces, developer references, and platform help pages change. We record when a source was checked and revisit claims when a cited page changes, a reader reports a mismatch, our scanner's extraction or comparison behavior changes, or a study method is corrected. A source access date tells you when we last checked the cited page; it is not a promise that the platform will keep the same interface or rule.
A material change is added to the product and data changelog when it changes how a result should be read, what the product compares, or what an evidence page says. Older measurements are not silently rewritten to match a newer method. If historical data cannot be recomputed from retained source evidence, that limitation remains disclosed.
How to request a correction
If a page describes a platform feature incorrectly or cites a source that no longer supports its wording, tell us which page and sentence you mean. Include the official source URL, the country or account context if it affects the answer, and the date you checked it. That gives us a concrete claim to compare against the evidence.
Send corrections through the contact page. We review the cited material, narrow or update the wording when appropriate, and record material changes in the changelog. We do not promise a response time or accept an unsupported correction as evidence by itself.
Scanner claims are limited to its implemented scope
MisMatchMaker compares a defined set of factual content fields on supported public listing pages. It does not inspect a hotel's private extranet or internal source of truth, and it cannot confirm that an edit was accepted or published. The report keeps source status and original extracted values visible so unavailable evidence is not presented as agreement.
We describe product results according to the evidence the scanner actually receives and the comparisons it can make. Agreement between public pages is not proof that a property's approved value is correct. The methodology page sets out the exact field list, evidence states, score conditions, and exclusions so this standards page does not substitute for the product specification.