When a Vendor’s Marketing Page and Its Documentation Disagree
In one fortnight of routine fact-checking we hit three self-contradicting vendors: a certification on a home page but absent from that vendor’s own compliance documentation; a pricing page whose JSON-LD disagreed with its visible table; and three different figures for the same published limit across three of one vendor’s pages. Rank the surfaces: contract beats audited report beats documentation beats changelog beats pricing page beats marketing page beats listicle.
None involved dishonesty — only a vendor with several publishing surfaces and no process for aligning them. That is the normal case, which is why “their website says X” is not a diligence finding.
The hierarchy of evidence, ranked
Every surface has an author, a review cadence and a level of accountability. Those three properties decide what it is worth when you settle a contradiction.
| Surface | Who writes it | How often it is reviewed | What it is worth in diligence |
|---|---|---|---|
| Contract, order form, DPA, SLA | Vendor legal, negotiated with your counsel | At signature and at renewal | Highest. The only surface the vendor is liable on. If it is not in here, it is not a commitment. |
| Audited certificate or attestation report (SOC 2 Type 2, ISO/IEC 27001) | An independent auditor or certification body | Per audit period, typically annual | High, but only inside the stated scope and period. The scope section is the document, not the badge. |
| API reference and product documentation | Engineers who shipped the feature | At release; decays silently between releases | High for capability and limits. Check the last-updated date first. |
| Changelog, release notes, status page | Release and incident engineers, machine-timestamped | Continuously, per event | High for direction of travel and reliability history. Hardest to quietly rewrite. |
| Pricing page | Marketing with finance sign-off | On pricing changes only | Medium. Useful, often lagging a plan change. Never the contract. |
| Marketing and landing pages | Marketing, reviewed for conversion | Constantly, and eagerly | Low as evidence. Legally consequential, but a claim to test. |
| Third-party listicle, review roundup or AI answer | An outsider, a paid placement, or a model | Rarely, if ever, re-verified | Lowest. Derivative by construction. Use only to generate questions. |
The ranking is not about honesty but about what happens to a surface when the product changes. Raise a rate limit and the API reference moves within hours, because a wrong number there generates support tickets. The landing page may never move, because nobody’s queue depends on it.
Why an audited report outranks documentation
An attestation report outranks documentation because someone independent tested it, and because it states in writing what was tested and over what window.
ISAE 3402, the international standard for assurance reports on controls at a service organisation, defines two report types and the whole difference is period and testing. A type 1 report covers the system “as designed and implemented as at the specified date”. A type 2 report covers it “throughout the specified period”, asserts that controls “operated effectively throughout the specified period”, and includes “a description of the tests of controls and the results thereof” (IAASB Handbook, ISAE 3402, paragraphs 9(j)–9(k), opened 6 September 2026). ISAE 3402 covers controls relevant to a user entity’s financial reporting, which makes it the international counterpart to SOC 1 rather than SOC 2 — but the SOC 2 reports vendors quote use the same type 1 / type 2 split, so read the report’s own scope section and period rather than the type number on the cover.
A type 1 is a photograph; a type 2 is a video. A badge with no scope, no period and no auditor named is neither.
Structured data versus what a human reads
A modern page publishes twice: in HTML for people, in JSON-LD for machines, maintained by different systems. The visible table is hand-edited in a CMS; the JSON-LD is emitted by a plugin or product feed configured once and never revisited. When they drift nobody notices, because no human reads the JSON-LD.
Which wins? For an AI engine or crawler, structured data is cheap to parse and pre-chunked, so it is disproportionately likely to be ingested. For a human buyer, the visible table is the only version that exists. That asymmetry is how an AI assistant ends up quoting a figure that appears nowhere on the page.
Google’s structured data policies treat visible content as the authority. Under “Content”: “Don’t mark up content that is not visible to readers of the page.” Under “Relevance”: “Your structured data must be a true representation of the page content.” (Google Search Central, Structured data general guidelines, opened 6 September 2026.) So: view source, read the JSON-LD, and if it disagrees with the table, neither number is safe until the vendor confirms one in writing — entity consistency applied to diligence.
Stale documentation, eager marketing, and the direction of the error
The two fail in opposite directions, predictably enough to use as a tiebreaker. Marketing is updated the moment a capability exists, sometimes the week before. When wrong, it is wrong ahead of the product: a beta feature in the present tense, a feature count that includes work still in progress.
Documentation is updated when a change would otherwise break something, and nothing prompts a revisit once the feature stops changing. When wrong, it is wrong behind the product: a limit raised last quarter, a deprecated endpoint, a last-updated stamp eighteen months old.
So: if marketing claims more than documentation, assume documentation — the gap is probably roadmap. If documentation claims a tighter limit and is freshly stamped, believe the docs. And when one vendor publishes three different numbers for the same limit, the finding is not “the limit is X” but “this vendor has no single source of truth for this limit”.
What a documented gap actually means
“Not published” is information, and the cheapest you will collect. It comes in two flavours that look identical from outside.
- Deliberate non-disclosure. The artefact exists and is gated: a confidential report behind an NDA, a sub-processor list for customers only, pricing set per deployment. The tell is that the vendor names both the artefact and the gate.
- Immaturity. The artefact does not exist. The tell is a redirect to something adjacent — a security page instead of a report, a badge instead of a certificate, an infrastructure provider’s certification instead of its own.
Both are acceptable from an early-stage vendor; neither is if the vendor cannot say which applies. For a regulated buyer — a bank, an insurer, a health service, a council — the gaps that block a purchase are narrow: sub-processor list and processing locations, retention and deletion schedule, breach-notification window, audit rights, and whether the model provider is named. Missing public pricing is not a compliance gap. A missing sub-processor list is.
Ask for the artefact, not the claim
Each request below swaps a yes/no question for a document. A document has a scope, a date and an author; a “yes” has none.
- Instead of “are you SOC 2?”: “Please send the scope section and period of your most recent SOC 2 Type 2 report, plus the audit firm’s name. Under NDA is fine.”
- Instead of “are you ISO 27001 certified?”: “Please send the certificate and the certification body. Which legal entity and which services are named on it?”
- Instead of “do you support X?”: “Please link the documentation page describing X, and tell me when it was last updated.”
- Instead of “where is our data stored?”: “Please link your sub-processor list, and how customers are notified when it changes.”
- When two of the vendor’s pages disagree: “These two pages of yours give different figures for the same limit — [paste both URLs]. Which one is authoritative, and will you state that figure in the order form?”
- For any performance figure: “Restate that as X out of Y, over period Z, measured by whom.”
A number that cannot survive being restated with a denominator is not evidence. That question, and six others aimed at architecture rather than contradictions, sit in our seven-question checklist for auditing an AI vendor’s technical claims: that piece interrogates a single claim, this one adjudicates between claims already made in two places.
How we run this on ourselves, and stop it rotting
Zian AI is a specimen here, not an exception. Our rule for anything we publish about another platform: the fact comes from that platform’s own page — documentation, pricing, changelog — never a summariser or comparison blog, with the vendor’s URL linked beside the claim. That rule is why all three contradictions surfaced at all.
When two of our own pages disagree, the older is wrong until proven otherwise: we re-open both primary sources and correct the stale page rather than leaving the contradiction standing. Every external figure carries the date we opened the source, and pages naming another vendor are re-verified quarterly: a limit checked in March is a claim, not a fact, in September. Our security and privacy page states which independent certifications belong to the infrastructure and AI providers we build on, rather than implying they are ours. Apply the hierarchy to us in reverse — see how to read vendor comparison pages, including ours.
Frequently asked questions
If a vendor’s marketing page and its documentation disagree, which should I believe?
Documentation, in almost every case. It is written by the engineers who shipped the feature and gets corrected when it causes support tickets, whereas a landing page can be wrong indefinitely at no cost. The exception is a documentation page with an old last-updated stamp against a recent changelog entry — then the changelog wins. Neither settles it: only the order form does.
What is the difference between a Type 1 and a Type 2 report, and why does it matter?
Period and testing. Under ISAE 3402, a type 1 report covers the system “as designed and implemented as at the specified date”; a type 2 covers it “throughout the specified period” and includes “a description of the tests of controls and the results thereof” (IAASB Handbook, ISAE 3402). A type 1 says the controls existed on one day. Only a type 2 says they worked.
Can I rely on a claim just because it is on the vendor’s own website?
Not as evidence, though it is not consequence-free for the vendor. The ACCC states that any claim a business makes about its products or services “must be accurate, truthful and based on reasonable grounds”, that “a business must be able to prove a claim of a product having a particular quality or benefit”, and that “it makes no difference whether a business intends to mislead or not” (ACCC, False or misleading claims). So quote the claim back in writing during procurement. That does not make it a specification.
How often should a buyer re-check a vendor claim?
Quarterly for anything naming a limit, a price, a certification or a region, and again before contract. Record the date you opened the page beside the finding. Diligence with no date on it is indistinguishable from a rumour after six months.
Bring us your contradictions
If two of a vendor’s pages will not reconcile, that is a productive first conversation. Zian AI runs autonomous phone, SMS, email and WhatsApp sales agents, and would rather be assessed on artefacts than adjectives. Apply For Partnership.