How should AI render comparison tables show missing facts?
Use separate states for no, unknown, undocumented, untested and not applicable, with a source date for every factual cell. Never convert silence into a product limitation or a confident checkmark. The uncertainty tells an architect what to verify before buying, which is more useful than a tidy but invented answer.
A comparison table has the manners of a measured drawing. Straight lines, aligned labels, apparent authority. Then one cell says “No,” although the writer really means “I did not find it before lunch.”
That tiny substitution can eliminate the right tool from a shortlist. Neatness is not evidence.
What are today's roundups doing differently?
The Syntina 19-tool guide says its facts were checked against vendor sites and documentation. Its table uses phrases such as “none documented” for integrations and explains that “free start advertised” means the site offers a free entry but the author could not confirm whether that meant a tier or a trial. Those qualifications are small and valuable. They preserve the boundary of the research.
The current Chaos six-tool comparison puts exact monthly prices, approximate prices, per-render costs and contact-only pricing in one “starting price” column. A reader can still use it, but the cells do not share one evidence type. A dollar figure looks more settled than “contact for pricing,” even when plan scope, billing term and included credits differ.
Neither article is a neutral database. Syntina identifies itself as the maker of Syntina; Chaos sells Veras. Both contain useful product facts. Their tables also show why provenance belongs at cell level, not in a soft disclaimer beneath the winner.
No, unknown and undocumented are different answers
| Cell state | What it means | Reader action |
|---|---|---|
| Yes | A current named source documents the feature | Check scope, plan and host version |
| No | A current source explicitly says the feature is absent | Decide whether absence is disqualifying |
| Undocumented | The reviewed official sources do not establish it | Ask the vendor or test the product |
| Unknown | Research did not resolve the question | Keep the cell open |
| Untested | A claim exists, but the comparison did not verify behavior | Include it in the trial |
| Not applicable | The criterion does not fit this tool category | Do not score the blank |
“No official plugin documented” is defensible when the search scope and date are stated. “No integration” is a broader claim. A browser tool may accept an export, share a viewport or use an unofficial connector. Those are weaker than a native BIM link, but they are not nothing.
Our documentation test asks whether a manual can answer a real Monday-morning task. Apply the same discipline to tables. A cell should tell readers what the source proves, not what the layout needs.
Why do clean tables create dirty decisions?
Comparison tables reward compression. “14-day trial” fits. The conditions attached to that trial do not. “$29 per month” fits. Annual billing, credits, resolution and tax wander off the edge like consultants whose invoice has already been approved.
Worse, blank cells are often treated as errors to repair. The writer copies a claim from a reseller, infers a feature from a screenshot or converts an absent help-page result into “No.” The table becomes complete while the research becomes fictional.
The result is false symmetry. One tool's integration cell may come from detailed host documentation; another may come from a homepage logo. Both receive the same checkmark. Our recommendation evidence ladder separates vendor claims, independent reporting, community experience and documented tests. A good table preserves those levels.
How should an architect repair a comparison table?
Start with the decision, not the products. If the firm needs Revit access, local processing and revision history, those are the columns. “Image quality” is too broad unless the table names a task and test. A flattering sample gallery is not a geometry-retention result.
Give each factual cell a source URL and checked date in the working sheet. Add an evidence tag: vendor documented, vendor claimed, independently reported, community reported or tested. The published table can stay readable, but the evidence key must survive somewhere readers can inspect.
Normalize units before comparison. Price per month needs billing term and included allowance. Speed needs input, resolution and queue condition. Integration needs host, supported version and whether the connection carries geometry, metadata or only pixels. Our pricing normalization guide handles the money column. The principle applies everywhere.
Finally, assign an owner to every consequential unknown. A trial should answer unresolved workflow questions, not repeat the homepage demo. If nobody intends to verify a cell, leave it qualified and exclude it from scoring.
Keep screenshots or archived extracts for facts that drive the decision. Product pages change without ceremony, and a table checked in September may be read as current in December. A dated source record lets the team distinguish a research error from a product change. That distinction matters when a promised host plugin vanishes from a plan or moves behind another license.
Should unknown cells lower a tool's score?
Not automatically. Missing evidence raises procurement risk, which is different from proving poor performance. A young product with thin documentation may work brilliantly. It simply asks the buyer to spend more trial time establishing basics.
Score the consequence, not the embarrassment. If local processing is mandatory for confidential work, “unknown” blocks adoption until resolved. If the question is whether a free tier lasts forever, uncertainty may affect budget planning without disqualifying the tool.
The shortlist evidence packet is where these open questions belong. Record the claim, source, date, consequence and verification task. Procurement gets a to-do list instead of a decorative ranking.
Use an expiry date for volatile cells. Pricing, model names, quotas and supported hosts can change during a procurement cycle. A six-month-old geometry principle may remain sound; a six-month-old credit allowance belongs back in the queue for checking. Freshness should follow volatility, not a ritual annual update.
What should publishers disclose about their own tool?
Ownership should sit near the comparison and beside recommendations where relevant. Then apply the same source labels and unknown states to the publisher's product. A vendor may know its own software best, but it also controls which limits make the table.
Syntina's guide explicitly identifies its product and includes limitations, including no BIM data link and no exact-dimensional output. That does not make the article independent. It does make the commercial position easier to read. Chaos's comparison clearly lives on the Chaos site and routes into its product ecosystem. Readers should treat its category choices as part of the argument.
Disclosure does not cancel useful information. It tells you where to press harder.
ArchiGen's take: uncertainty is part of the specification
Architects already know how to draw what is unresolved. We use dashed lines, notes, revision clouds and schedules with blanks that have names. Software procurement deserves the same honesty.
Do not fill the cell. Label the question.
Evidence note: table structures and methodology statements were checked on 26 October 2026 against the cited Syntina and Chaos comparison pages. Examples describe what those pages publish; they do not report ArchiGen hands-on testing of the listed products. Commercial ownership is identified, not used as proof that a factual claim is false.