Why a buying question stays open: the reasons behind unknown

A buying question on this platform is a sentence such as "CRM for manufacturing with SSO". The search reads it into a category and a set of conditions, and answers with the products that document every condition. On 2026-09-13, 100 such questions were run against the database: 50 had at least one full answer, 38 were understood, had products in their category, and none of those products documented every condition. Those 38 are the subject of this piece. Each of them lists candidates with open research, and "open" is not one thing. We measured, for every open condition of every product in those categories, why it is open, and the answer decides what to build: a reader, a research task, a fetch, or nothing, because the page does not say it.

Seven reasons, in a fixed order

An open condition is an attribute of a product that the question needs and that carries no documented value. The measurement reads every product of the category, not only the thirty in the result list, and assigns each open condition the first reason that applies from the list below. The order matters: a product that the attribute does not apply to is not "never asked", and an attribute without a reader is not "never readable".

1,129 open conditions across the 38 questions, 700 product readings in 34 categories. The first five reasons describe our research and never the product: nobody asked, nothing was readable, no reader exists, or the attribute does not exist for that kind of product. Together they are 635 of 1,129 (56.2%). The last two describe a page we did read: 494 conditions (43.8%).

The two largest reasons are almost the same size and mean opposite things. "Read, word absent", 346 conditions, is a page we fetched, stored and read, on which a wide word trace for the attribute finds nothing. The trace is deliberately wide and is not a reader: it only says whether anything stands on the page that a reader could find. When it finds nothing, the page probably does not say it, and no better reader would change that. "Never asked", 345 conditions, is the other kind: no research task of the product ever asked for the attribute. Nothing was fetched for it, so nothing is known about the page.

The 148 conditions read with the word present are the ones a better reader might close, and they are the smallest of the three large groups. 224 conditions were asked for and never had a usable snapshot: the fetch failed, the host answered with an error, or the page redirected to another host. Each of these carries the note the pipeline wrote when it published the unknown, so the reason is read from the record and not guessed.

Which attributes stay open, and why

The reasons are not spread evenly over attributes. The eight attributes with the most open conditions account for 657 of 1,129, and the mix of reasons is different for each.

Two attributes at the top are almost entirely "never asked": public list price with 123 of 136 open conditions and PCI DSS with 115 of 130. Both come from the two questions with the largest categories, and in those categories the research tasks were written for other attributes. That is a gap in our task list, not in the vendors' pages, and it is closed by adding the attribute to the tasks of those products. API availability is the opposite: none of its 81 open conditions is "never asked"; 34 were read without the word, 23 with it, 24 were never readable. Here the tasks exist and the pages were read; what is missing is a value we can document.

One attribute has a reason of its own: "human approval required" is open 34 times, and 33 of them because no reader exists for it. Whether an AI agent requires a person to approve an action is stated in prose that no pattern reads yet, and the measurement says so instead of counting it among the pages we read.

Three notes that stand next to a reason

Three marks are counted alongside the reasons and replace none of them, because each says where a value might be found without saying that it is.

• Documented earlier: a documented value existed and was superseded or withdrawn; 48 open conditions.
• Sub-page without a task: link discovery found a page of the right kind, and no task reads it; 31 open conditions.
• Documented for the vendor: the organization carries the attribute, the product inherits nothing; 31 open conditions.

"Documented for the vendor" is the one that surprises readers. If the organization behind a product documents SOC 2 Type II, its products inherit nothing: a certification of a company is a statement about the company, and the product page has to say it for the product. The 31 conditions with this mark are open on the product and documented one level up, and the vendor page shows the value with its source.

The pipeline also leaves a note on every unknown it publishes, and 660 of the open conditions carry one: pattern found nothing 374, fetch not readable 166, redirect to another host 47, no assignment possible 40. The note "pattern found nothing" is the record behind "read, word absent" and part of "read, word present"; "fetch not readable" and "redirect to another host" are the record behind "never readable". 12 conditions are open because a person judged an earlier reading wrong and the value was withdrawn; those stay open until a new reading is judged, and no automated re-read restores them.

How close the nearest product is

For every question the measurement sorts the candidates by how many conditions are open and reports the nearest. For 35 of the 38 questions the nearest product is one condition away; for the remaining 3 it is two. And for 20 questions that nearest product has, for every open condition, either the word on a page we read or a sub-page of the right kind that no task reads yet. Those are the questions a single research task or a single reader can turn; the others need a page that says it first.

What changed two days later

The same 100 questions were run again on 2026-09-15: 56 answered, 36 only open, 6 partly understood, 2 at variant level. 6 questions moved from open to answered, and 4 from partly understood to understood. The measurement above is what pointed at the tasks to add; it is not a promise about the next run, and a question that is answered today can fall open again when a value is withdrawn.

What we publish for an open condition is the same on every page: the attribute reads unknown, the addresses checked are listed with their dates, and the API returns verification_state: "unknown" with a null value. The reason measured here is not printed on the product page, because it describes our pipeline and changes with every campaign run; it lives in the measurement file with its date.

What a buyer can do with an open condition

1. Read the addresses checked. An unknown on a product page names the pages we read and the date. If the page you know is among them, we read it and found no value we could document; if it is not, we never looked there.
2. Tell us the page. A vendor or a reader can name a page on the vendor's own domain. It becomes a research task and is fetched, stored, read and ranked like any other page; nobody can set a value, only name a page.
3. Use the vendor page for company-level facts. A certification or a data location documented for the organization stands on the vendor page with its source. It says nothing about the product, and that is why the product stays open.
4. Read the state, not the absence. Unknown means we searched and found no reliable evidence on that date. It is a question to put to the vendor, never an answer about the product.
5. Take the fields into your own tools. The JSON API and the MCP server return every attribute with its state, the addresses checked and the dates, so an open condition can be tracked until it closes.