Methodology

Confidence starts at the base value of the best source behind a claim. A weak source next to a strong one never drags the strong one down.

Independent corroboration adds 6 at 2 sources, 9 at 3 sources, 10 at 4 sources. Beyond that it adds nothing: ten copies of one press release are not ten pieces of evidence.

Age subtracts 8 points per year since the observation. The result is clamped between 5 and 99. There is no 100: measured is not proven.

We fetch a source, keep a snapshot of what actually arrived, read candidate values out of it, and only then decide whether to publish. A value never goes straight from a page onto this site.

An HTTP 200 is not a page we read. A response with fewer than 800 characters of text, or one whose text says the site had an error, counts as not measured. We have seen all three: a status of 200 with a body of a few dozen characters, a rendered page reading “something went wrong”, and a 403 that locked us out. None of them is a statement about the vendor.

Four rules decide what happens to a value we read:

• Nothing recorded yet: we publish it, including “searched and found nothing”.
• We had nothing and now found something: we publish it.
• We had something and now find nothing: we keep what we had. A single failed fetch is not counter-evidence, and it must never turn a documented fact back into not measured.
• A different value from a different source: we publish it only if that source is strictly better. Otherwise we stop and record a conflict, and nothing changes on this site until a person decides. The same source saying something new is an update, not a conflict.

When one page describes several products, we only read the section that belongs to the product, and that section has to prove itself by producing a value we already know. If it cannot, we read nothing from it rather than risk giving one product another product's specifications.

An address that redirects to another host is read only if that page names the subject. When a vendor has been acquired, its old address often lands on the acquirer's site, and what the acquirer says about itself (its industries, its certifications) is not documented for the company it bought. Where an earlier statement came from such a page, it is replaced by not measured. A redirect within the same domain, or to a page that does name the subject, is read as before.

A product page has to name the product's generation, not just its name. Vendors keep one address on the newest generation: the address of an older Pixel phone lands on a category page that advertises the current series, the address of an older iPad mini on the current iPad mini, and a specification sheet under apple.com/ipad-mini/specs/ describes whichever model is current. Where the name is on the page but the generation is not next to it, we read nothing from that page and replace what came from it with not measured. This applies to the product's own start page and its data sheet, not to a vendor's shared pages: a trust center or an app directory names no model, and does not have to.

A phrase that appears identically on the pages of 3 or more different products at the same host is site navigation, not a statement about the product. Such a match is not published as a label; where an earlier label came from that navigation, it is replaced by not measured. This rule applies to labels (industries, audiences) only: a certification named in a vendor's footer holds for each of its products.

The same holds for one product and its vendor. An industry list in the header of a vendor's home page also stands on the page of each of its products, and a vendor with several products does not tell us which one that industry belongs to. Where such a phrase stands identically on the vendor's home page, is written in title case (fewer than 30 per cent of its words start lowercase, which is how a menu differs from a sentence) and appears nowhere else on the product's own page, it is not published as a label. A vendor with a single product is left alone: there its home page is the product's page.

The rule is measured, twice, and the two samples answer different questions. On 2026-09-02 we drew 30 of 113 cases where a label stood word for word on the vendor's home page (seed 0.49, daten/messungen/2026-09-02-elternnavigation.json) and judged each by hand: 22 were the vendor's navigation and 8 belonged to the product, so a rule over mere word identity would be right 73% of the time. The two extra conditions above raise that: of the 18 cases in that sample the rule as built would have caught, 16 were navigation and 2 were not (89%). That threshold was chosen on those judgements, so it was measured again on cases it had not seen: on 2026-09-02 we drew 30 of the 43 cases the rule had actually removed (61 in total, minus the ones the threshold was chosen on; seed 0.52, daten/messungen/2026-09-02-elternnavigation-2.json). 30 of 30 were the vendor's navigation and 0 belonged to the product - 100%. A judgement here describes our extraction, never a vendor.

A correction is not a failed fetch. Rule three above keeps a documented fact when a later fetch finds nothing. It does not keep it when the reason for finding nothing is that the extractor was wrong: a pattern we retired, or a match we recognised as site navigation, replaces the earlier statement with not measured at the same source, and the earlier statement stays in the history.

Integrations are never published from a name alone. A product name found on a vendor's integrations page becomes a candidate with its excerpt, and an editor approves or rejects it; only the approval writes the edge, with the page as its source. We measured the automatic way and found a login list, a third-party marketplace and an access request among eleven hits. Two helpers make the review faster without deciding anything: an excerpt without any integration wording, or one that is a list of 3 or more other product names, is marked as suspicious, never rejected by the marking. And a rule approves a candidate only where the excerpt literally says “integrates with” or “connector for” within 80 characters of the product name; the quote is stored as the reason. Everything else waits for a person, and every decision carries who made it and why.

Both helpers are measured. A sample of 100 open candidates (edge candidates (kanten_kandidat) in state open, ORDER BY random() after setseed, seed 0.47), drawn on 2026-09-02 and judged by hand against the excerpt (daten/messungen/2026-09-02-kanten-2.json): of 88 candidates the marking called suspicious, 59 were no integration and 29 were one, so the marking is right 67% of the time; of the 12 it left unmarked, 9 were an integration (75%). The most common non-integration in that sample was a wrong target: a vendor we recorded as a service (Microsoft, Google, Amazon) where the page names one of its products (Dynamics, Workspace, S3). Of the 54 candidates whose target is such a derived service product, 36 were no integration (67%); of the 46 others, 26 (56%). Such a target is now marked as suspicious too: “target is a derived service product (an organisation recorded as a service); the page more likely names one of its products”. The marking was measured on this sample before it was added, and it marks; a person still decides. Where the target is such a derived product and the excerpt names a product of the same vendor that the graph holds (Dynamics rather than Microsoft), the candidate carries that product as a proposed target; the approval takes the proposal only when a person chooses it. In this sample 8 candidates carried a proposal, 8 of them naming the product the page meant (100%). The literal rule has approved 2 candidates so far, 2 of them an integration; only 2 decided judgements; at least 5 are needed for a figure. A wording joins the rule only after it has been measured the same way; in this sample “integrates with” stood next to the name 1 time (1 an integration), “integration with” stood next to the name 3 times (1 an integration), “works with” stood next to the name 2 times (1 an integration), “plugin for” stood next to the name 1 time (0 an integration); none reached the 5 decided judgements a figure needs. Overall, 38 of the 100 decided candidates were an integration (38%): a name on an integrations page is a lead, not a fact, and that is why a person decides. Earlier samples: 2026-09-02, seed 0.44, 100 candidates, the marking right 62% of the time, 41% an integration (daten/messungen/2026-09-02-kanten.json).

A link is not a name, and it publishes. Where a vendor gives each integration its own page under the integrations page (deputy.com/integrations/dropbox), the link is a statement about that one target, with an address of its own as the source. That rule writes the edge without a person, and it is the way most of our integration edges came in. It was measured over every integrations page we hold before it was switched on (daten/messungen/2026-09-03-kanten-links.json, 2026-09-03): 222 pages fetched, 129 candidates, all judged by hand. Raw, 50 of 129 were an integration (39%) – no better than the text. Two barriers change that: the page must belong to exactly one subject, and it must name that subject. With both, 50 of 50 were right (100%). The figure that carries the barriers is the other one: of the 79 they removed, 0 were an integration. They are not too tight.

A vendor we track without a separate product entry is the subject of its own integrations page. Where a company has no product in our graph, there is no product the page could belong to, and the edge starts at the company. Measured over every such page before it was switched on (daten/messungen/2026-09-04-kanten-organisation.json, 2026-09-04): 154 vendor pages carried an integrations link, 154 were fetched, 70 candidates came out. After the same two barriers, 16 remained, and every one of them was judged by hand: 16 of 16 were an integration (100%). The 54 the barriers removed are not wrong findings but findings under the wrong subject: 47 of them already stand as an edge at the same address, under the product.

Ownership is read on the company's own site. A sentence like “part of Tucows” or “a Salesforce company” on a company's own front page is a statement it makes about itself, at rank one, with an address and a retrieval date. The wording is found, but the name is not captured: what stands behind it is resolved against the organizations we already hold, longest match first, and a name we do not hold yields nothing. Measured over 1064 company front pages (daten/messungen/2026-09-04-kantenarten.json, 2026-09-04): 9 candidates, all judged by hand, 6 of them an ownership statement (67%). Two barriers take the rest: the subject of the sentence must be the company and not its products, and the captured span must not name something more specific than the organization – the privacy notice “as part of Google Analytics” is about a product. With both, 6 of 6 (100%), and what they removed was 0 correct statements of 3. Wikidata records the same relation for many more companies and we do not use it: there is no source kind for a community database in our hierarchy, and rank five would label the finding vendor stated, which would be untrue about where it came from.

A documented alternative is one the vendor named itself. Where a product's own front page says “alternative to Gmail” or carries “Fastly vs. Akamai”, the vendor positions itself against a named competitor, and that is the one source for this edge that is not circular: our category neighbours come from the same articles the categories do, and they stay marked as our inference. The wording is found, the name is resolved against the products we hold (longest match first, in the product's own spelling, 4 characters or more, never a name two products share), and a name we do not hold yields nothing. The edge is labelled vendor stated on purpose: the page is the vendor's own, but “X is an alternative to Y” is its positioning, not a fact we checked against a document. Measured over 1211 product front pages before the rule wrote anything (daten/messungen/2026-09-06-alternativen.json, 2026-09-06): 22 candidates on 15 pages, all judged by hand, 20 of them a stated alternative (91%). One barrier takes the rest: a span that names something more specific than the match (“Microsoft IE” resolving to Microsoft, “Google Nexus 7” to the Nexus line) yields nothing. With it, 20 of 20 (100%), and what it removed was 0 correct statements of 2. Unlike on integrations pages, a target recorded as a service (Dropbox, Cloudflare, Splunk) was the product meant in 5 of 5 such cases. Company front pages of vendors with exactly one product were measured too and are not read: 3 candidates on 212 pages. This is a statement about the data, not a reason to lower the bar of five documented alternatives an alternatives page needs.

We measure how often an extractor's finding is what the source says. A sample of 100 published statements is drawn at random (claims with state verified or corroborated and ersetzt_am IS NULL, ORDER BY random() after setseed, seed 0.5), each excerpt is read against the stored snapshot, and each gets one of three judgements: correct, wrong, or not decidable. Wrong statements are replaced by not measured at the same source, never overwritten. The figures below are read from daten/messungen/2026-09-02-praezision-lauf6.json, drawn on 2026-09-02; an extractor with fewer than 5 decided judgements shows its counts and no figure, because two judgements are an anecdote.

A figure shown here is not always a figure we use. An extractor's own precision caps the confidence of its statements only from at least 10 decided judgements; below that we cap with the overall figure instead, and the statement's evidence drawer says so in those words. The last column names it per extractor, so that a figure on this page is never read as a figure at work.

Overall: 71 correct, 29 wrong, 0 not decidable, precision 71% over 100 decided judgements. Precision describes our extractors, never a vendor.

Earlier measurements: 2026-09-02 run 1: 74% over 100; 2026-09-02 run 2: 72% over 100; 2026-09-02 run 3: 65% over 100; 2026-09-02 run 4: 73% over 100; 2026-09-02 run 5: 71% over 100.

Measured separately, per reader

A sample drawn over one attribute measures that attribute's reader and no other. Where a reader reads at that attribute and nowhere else, such a sample IS a random sample of exactly its statements, and then it sets that reader's cap. It never changes the overall figure above.

10 of them do not appear in the table above at all: the random sample of 100 did not draw them.

And how far does that reach? 131 extractors produce the 3,951 published facts. 25 of them have a precision measured by hand for that extractor alone, and those carry 2,152 facts, or 54% of the total. The other 106 carry 1,799 and are capped with the overall figure instead. We name the gap because a table of what we measured says nothing about what we did not.

What this figure does NOT cover

The measurement above is about the research pipeline, not about the connectors. It draws its sample from published statements, and when it was drawn on 2026-09-02 not one of them came from a connector. The statements the connectors have written since are not covered by it, and a precision figure standing next to them without saying so would invite exactly the wrong reading.

5 of the 7 connectors have a measurement of their own; 2 do not. Both facts are below, read from daten/messungen/2026-09-06-konnektoren.json.

Five of the seven connectors now have a measured precision (GLEIF 0.931 on 30, ENERGY STAR 15 of 15, SEC EDGAR 30 of 30, npm 6 of 7, NVD 19 of 19 in the matching); two do not, and both say why: CISA KEV does not reach the server (HTTP 403), Azure has four observations. The npm measurement found an error class (the code host as a product) and closed it. A cap derived from a figure we do not have would itself be an invention, so konfidenz.gedeckelt still does not cap a connector statement; its uncertainty sits in the matching, and that has its own gate in zuordnung_kandidat.

Some of what you read here was not extracted from a web page at all. It comes from an official machine-readable source: a register a supervisor maintains, a certification database, a package registry, a vendor's own published price list. Those sources do not have to be interpreted, and they are re-read on a schedule.

We store the source document itself, with a content hash. That is why we can answer “did it really say that” a year later without asking someone else's server again.

A register that disagrees with another register does not overwrite it. Two sources of the same tier can both be right and still say different things: one names the headquarters of the group, the other the business address on a filing. When that happens we keep what we had, record the disagreement, and a person decides. Nothing is silently replaced by whichever source we happened to read last.

This is a different question from the confidence next to a value. Confidence asks how sure we are of the value; this asks how good the evidence is - whether we can still prove it in a year, and whether anyone else confirmed it. Independent sources lift the agreement component along the curve below, and it flattens on purpose: ten citations of the same press release are not ten sources.

0 sources: 0% · 1 source: 0% · 2 sources: 60% · 3 sources: 85% · 4 sources: 100%

Facts age at different speeds, and the speed follows the subject. A price from last month is old; a founding year from last year is not.

The score below is not the only gate. Each type of page also has to earn its own existence, and the conditions are counts, not points: you can check them yourself on the page.

The reason is stated plainly: a comparison page that can compare two attributes is a page mass-produced without added value, and that is what search engines call scaled content abuse. We would rather the page existed and stayed out of the index.

Together those add up to 40000 pages the architecture can address. That is a ceiling, not a plan: what is actually indexed is whatever passes, and today that is a far smaller number.

A condition we could not count leaves the page in a third state: not assessable. It is neither met nor failed. Such a page stays out of the index, because the safe direction is to publish nothing we could not check, and the page plan counts it apart from pages that actually fail a condition. A hole in our own counting is reported as a hole, never as a verdict about the page.

“Memory”, “RAM” and “unified memory” are the same question. Pounds and kilograms are the same weight. And a screen diagonal of 99999 inches is not an unusual product, it is a misread number.

All three live in one place, as data, so that a new attribute brings its words, its unit and its limits with it.

The ranges catch the impossible, not the unusual. A value we throw away is more expensive than a value that surprises us.

3 of the 7 components are not measured today (search demand, own data, uniqueness). They drop out of the score entirely rather than counting as zero or as full; the paragraph below says why.

A page below 55 carries noindex and is absent from the sitemap. We would rather publish fewer pages that are worth reading.

A component we cannot measure drops out of both the numerator and the denominator. Counting it as zero would punish a page for a gap in our own tooling; counting it as full would be an invention. This is the same rule as Not yet verified above, applied to ourselves.

Substance. A page about a product, vendor or category is indexed only if at least one statement describes the subject (verified, corroborated, vendor stated or customer reported). A page that only says what we could not find is honest, but it is not a page anyone should be sent to. A pricing page needs at least one price observation.

Data completeness counts core attributes only. An attribute we searched for and did not find counts 0.5 of a found one: more than a gap, less than a finding. Labels such as “names manufacturing as a market” count neither here nor in evidence density.

Comparison pages take the minimum of both sides for every component and need substance on both. Vendor and category pages take the average over their products. Overview pages and this page are indexed by editorial decision, not by the gate: the law requires the methodology to be immediately accessible. An overview that promises an inventory, such as the pricing and the security overview, is indexed only while it lists at least one page, and it lists only pages the gate lets through.

When the gate decides. The gate runs over every page in one daily batch. Opening a page reads the stored decision and never changes it; only a page that has no decision yet is assessed on its first visit. The robots tag of a page and the sitemap read the same stored decision.

Every change is a stored event: a claim replaced, a price observed, an integration documented, a product added, a source page whose text changed. Each event is classified into one of these kinds:

A finding is not a change. When we first document a certification that was not measured before, the event says so: it is a finding of ours, not necessarily a new certification. A change to a state that describes our research (not measured, estimated) is a research update and never a change to the product. A changed page hash carries no judgement; it only says the text differs from our last read.

Next to a vendor or a product you may see a small square mark. It is not a logo we assert to be official. It is an icon that the vendor publishes on its own site, fetched by us, stored by us and served from this domain. The address it came from, the page it was linked from and the date we fetched it are recorded with every mark, exactly as with every number on this site. We look in this order and take the first that works:

1. Touch icon: the apple-touch-icon linked from the page, usually a 180 px square
2. Web app manifest icon: an icon listed in the site's web app manifest, usually 192 or 512 px
3. Windows tile: the msapplication-TileImage named in the page head
4. Site icon: a <link rel="icon"> from the page head, often only 32 px
5. Structured-data logo: the logo the site names in its own JSON-LD (schema.org Organization or Brand)
6. Fallback favicon: /favicon.ico at the root of the site, tried last

A product shows its own mark when its own page publishes one that differs from its vendor's (a product hosted on its own domain, say); otherwise it shows the vendor's, and the title of the image says which. Two rules keep a mark from being someone else's: on the vendor's own domain we keep a product icon only if it is at least as large as the vendor's mark (a smaller one is the same brand in worse quality), and a page that redirects to another domain without naming the product or vendor yields no mark at all, because the icon there belongs to whoever runs that domain. An image wider or taller than 1.5 to 1 is a wordmark and not a mark; we do not use it, because in a small square it is unreadable. SVG is never fetched: it can carry script, and we serve these bytes from our own origin.

Where we find none, we record the page, the day and the reason, the entry says so in its header ("No mark on file. We looked at ... and could not read the page"), the API carries it as mark_attempt, and we look again after 30 days. The reason describes our attempt on that day, never the vendor.

Three consequences follow, and each of them is a decision:

• Your browser never contacts the vendor. We do not hot-link. Our content security policy allows images from this origin only, and the privacy page quotes it word for word.
• We use the mark to identify the vendor whose entry you are reading, and for nothing else. Marks and names are the trademarks of their owners; showing them here implies no endorsement, affiliation or paid relationship. A vendor who wants its mark removed only has to say so, and we remove it.
• Where we have no mark, we draw one. The coloured square with initials is ours; it says nothing about the vendor except the first letters of its name. We never generate, redraw or approximate a logo: that would be the picture version of an invented number.

Verified does not mean recommended. Badges are computed from documented evidence and cannot be bought.

The data badge needs 3 verified or corroborated core attributes; the price badge needs an observation at an official pricing page within 30 days.

A paying vendor may see more; it never stands higher. A vendor subscription decides which analytics a vendor sees (basic: 3 figures, premium: 6 figures, intelligence: 7 figures). No ranking, no page score and no badge reads it. Vendor submissions name a page on the vendor's own domain; we read it with the same rules as any source, and a value is published only if the page documents it. Corrections are welcome and go the same way.

Page views and search terms are counted as daily sums without any visitor identity: no IP address, no user agent, no referrer, no per-visit timestamp.

What can be paid for: advertising (marked “Sponsored”, never inside a ranked list or a comparison row), sponsored research with disclosure, premium profile features, lead generation with the buyer's explicit consent, intelligence products, data licences (Open: 1000 requests a day, Licensed: 50000 requests a day, Bulk licence: 200000 requests a day). What can never be paid for: rankings, scores, reviews, badges, the removal of accurate information. Affiliate links are disclosed on the page that carries them and on no other page; the disclosure says whose commission it is. Aggregated buyer intent is shown only from 5 consenting accounts per cell upwards.

Rights are explicit: a right not in this table exists for nobody.

The index orders vendors, so it is a ranking. It counts documented change events in the last 90 days with these weights, read from the same file the index uses; a vendor needs at least 2 events to be listed. It measures how much we documented changing, not business performance.

A review says whether the product was in our hands: who, when and with what. Without that record it carries the sentence “Not hands-on tested. This piece rests on documented specifications and sources named below.” and rests on documented specifications. Phrases that claim experience (“we tested”, “in our testing”, “in our tests”, “hands-on”, “hands on”, “we measured”, “our benchmark”, “in our lab”, “we used it”, “after using”, “we tried”, “our review unit”, “we ran”, “in daily use”, “our experience” ) are refused by the editor unless that record exists. Change notes in the news section are generated from stored events and say so.

“Ask” is deterministic. It maps the words of a question to a category, a budget, an audience, an industry and required attributes, shows that mapping, names what it could not map, and answers with the same documented data as the search. A product with an unmeasured filter is listed under “cannot say”, never dropped. No language model writes the answer.

In a workspace, the fit score against your own requirements uses exactly the finder rules above. The decision matrix weights each stakeholder's zero-to-ten score by the vote weight the workspace set; a missing vote is left out of numerator and denominator, never counted as zero, and a product is ranked only when every stakeholder has voted. Both are shown with their contributions, never as a bare number.

An estimate from documented signals only. Each signal adds or removes a point; the sum maps to a level. An unmeasured signal is left out and never counted as effort; without any measured signal there is no level. The ROI calculator next to it holds no benchmark: every figure is the user's own assumption run through a stated formula.

The maturity and readiness assessments are the user's own account of their organisation, weighted per question as shown. Each answer maps to a step on the scale; unanswered questions leave numerator and denominator. The result is labelled as an estimate and measures nothing about any vendor.

Agents are rated individually and per workflow, never as a blanket score for a vendor. A vendor page shows the range over its assessed agents and says that it is a range.

The level is derived from documented capabilities (executes_actions, multi_step_workflows, human_approval_required) and is always the lowest level consistent with the evidence. An unmeasured capability never raises the level. An agent about which we know nothing gets no level, not L0: L0 would be a statement about the agent where one about us is due. A level stated by a documented source takes precedence over our derivation. The level is our estimate and is labelled as such; nobody can buy it.

A price is an observation on a day, not a fact that gets replaced. Older observations stay, because they are the history that any statement about a deal rests on.

Prices come from one pattern per vendor page, written by a person after reading that page, never from a rule that runs on every page. Each observation carries currency, period, plan name and the condition the page states (“billed annually”, “first year”, “2-year plan”); a monthly figure billed annually and the same plan billed monthly are two lines, not a fluctuation. A price without a period is not a price, and a page whose amounts are rendered by JavaScript after the HTML we fetch gives us none. Of the 161 official pricing pages we have read so far (daten/preismuster.json, read 2026-09-02 to 2026-09-15), 73 carry a pattern with 231 price lines, 174 of them with a stated condition; 88 gave no usable price: 29 quote or sales contact only, 25 page prices a different product, 13 fee or usage table instead of a plan price, 9 amount without a readable plan name or condition, 6 no amount in the page text (rendered by JavaScript), 6 amount without a period. Those pages stay listed with their reason so that nobody reads the absence of a price as a statement about the vendor.

We state an average only when there are at least 4 observations and they span at least 30% of the window. Ten readings over three days say something about three days, not about ninety, and that is what we write instead of a number.

Where a deal can be assessed, the baseline is the first of these windows with enough history: 90, 30, 365 days. The wording is always the measurement and its grounding, for example “23% below the average of prices observed in the last 90 days, USD 1,579 (137 observations)” — the number, what it is measured against, and how much it rests on. The 137 here is only an illustration; a figure that matched one of our parameters would drift into looking like one.

Two things we never do. We never state a discount against a starting price — a “from” figure is not a price anyone pays, so a saving against it is a saving against nothing. And we never invent urgency: no countdowns, no “ends soon”, no “only a few left”. A deadline appears here only when the vendor states one and we have recorded it. That is not a promise, it is a word list the code checks itself against before it publishes a sentence.

The finder orders products, so it is a ranking. The weights below are the ones it actually uses: this page reads the same file, and a test forbids writing any of these numbers into the page by hand.

Three rules decide what a criterion does to a product:

• A criterion we could not measure is removed from both the numerator and the denominator. It never counts against a product. Instead the coverage figure drops, and that figure is shown next to every score.
• A value that is our own estimate counts at 0.5 of its weight, and the share resting on estimates is published with the result.
• A product is ranked only when at least 50% of the weighted criteria could be measured and every mandatory criterion could be checked. Otherwise it is listed separately with what is missing - never dropped, because a gap in our research is not a fault of the product.

Only a documented failure of a mandatory criterion rules a product out. An unreachable document never does, and neither does one of our own estimates.