How should architects test AI renderer documentation?
Find dated instructions for supported inputs, host versions, controls, output limits, credit costs, data handling and failure recovery. Then follow one workflow using only those instructions. Score gaps as operating risk. A renderer that depends on sales copy, old videos or private support cannot become a dependable studio standard.
This morning's search returned a 19-tool comparison that advertises an unusually sensible method: check products against their own documentation. Beside it sat several familiar top-ten lists and a six-tool comparison from Chaos, which also sells Veras. The first problem is obvious. Product pages are abundant. Manuals are not.
A glossy page can say that a tool accepts sketches, models and text. A studio needs to know the accepted formats, dimensions, host versions, upload limits and what survives the trip back. Those are different genres of information. Procurement keeps pretending the first can substitute for the second.
Why does documentation belong in the score?
Architecture offices buy continuity. A convincing output matters, but the tool must also survive a Revit update, a new operator and a client revision six weeks later. Documentation is the bridge between one skilled enthusiast and a repeatable office method.
That makes it a product surface, not clerical garnish. If a feature exists only in a launch video, the practice cannot cite its limits or train another person reliably. If pricing says “credits” without a table for each operation, the office cannot forecast cost. If release notes omit breaking changes, an update becomes a small ambush.
ArchiGen's plugin compatibility check covers the host-version problem. The broader procurement lesson is harsher: undocumented behavior is borrowed time.
Can a buyer find the operating facts?
Start with six questions and allow ten minutes for each. Do not contact sales yet. A mature product should make ordinary operating facts public enough for a prospective customer to inspect.
| Question | Acceptable evidence | Warning sign |
|---|---|---|
| What enters? | Formats, dimensions, host versions and examples | “Any model or sketch” |
| What changes? | Named controls with stated effects and limits | Only before-and-after galleries |
| What leaves? | Resolution, file type, metadata and editable outputs | “High resolution” |
| What costs? | Operation-level credit table and plan date | One unexplained credit balance |
| What is stored? | Retention, deletion and training terms | Privacy link with no product path |
| What broke? | Dated release notes and known issues | Launch posts presented as support |
The wording matters. “Supports SketchUp” is a sales claim. A support matrix naming SketchUp releases, operating systems, installer version and known conflicts is operating evidence. “Fast” is a mood. A queue policy, timeout rule and retry procedure can be planned around.
Our output-format test asks what files sit behind the beauty image. Documentation should answer that before a subscription does.
Follow one task with the sales tab closed
Pick a common task, such as taking a clay exterior from the host application through one controlled material change and a final export. Give a colleague who did not choose the tool access to its public help material. Watch where the trail ends.
Record every undocumented decision: which input route to choose, what the geometry slider changes, whether a rerun consumes credits, how to recall a seed, where an export lands and how to reverse an update. Search time counts. A support ticket counts more.
This is not a usability test in disguise. An interface can be pleasant while its operating model remains obscure. Nor is the exercise about punishing a young product for a modest help center. A small manual can be excellent when it states the supported path, marks experiments clearly and dates every claim.
Do the same exercise after the trial operator leaves the room. The workflow bus-factor check asks whether another person can recover the process. Documentation is where that transfer either becomes routine or turns into archaeology.
Version numbers beat evergreen adjectives
AI render products change engines and controls quickly. Chaos currently markets Veras as powered by Nano Banana 2. That is a vendor claim about the current product. It does not make every older Veras review current, and it does not tell a buyer which earlier settings behave differently under the newer engine.
A useful manual separates product version, host-plugin version and underlying model when those layers can change independently. Release notes should say which control moved, what default changed and whether old projects reopen with the same behavior. “Improved quality” is not enough. Improved which task, under which mode, with what migration consequence?
The same discipline applies to comparison articles. The Syntina page surfaced today says its 19 tools were checked against their own documents. Good. A reader should still inspect when each row was checked and whether a source describes the same version now on sale. ArchiGen's comparison expiry-date rule exists because a table without dates slowly becomes fiction.
Support cannot be the missing manual
Responsive support is valuable. It should handle exceptional trouble, not explain the ordinary product one customer at a time. When installation, credit use or export behavior requires a private reply, each office receives a slightly different manual that nobody else can verify.
Ask whether resolved questions become public articles. Check if known incidents have status pages or dated notices. Look for a route to report a documentation error. A company that treats corrections as product work is easier to standardize than one whose help center always describes last season's interface.
Community videos can fill gaps, especially for ComfyUI and fast-moving plugins. Label the substitution. A creator's screen recording may teach technique brilliantly while saying nothing about vendor support, security or future compatibility. The office should know which part of its standard rests on official documentation and which part rests on community craft.
How much should documentation affect procurement?
Give documentation 20 percent of the operational score, then use it as a gate for claims that affect cost, confidentiality or recoverability. A spectacular renderer can survive a middling manual during exploration. It should not become the only route to a deadline-critical deliverable while basic recovery remains oral tradition.
Score discoverability, specificity, versioning, completeness and correction. Keep the raw notes. If the vendor improves the manual during the trial, that is useful evidence about support culture. If sales answers every gap but none of those answers appear in writing, the gap remains.
Do not reward bulk. Fifty thin SEO pages are less useful than five maintained guides with exact boundaries. The goal is a trustworthy operating path.
ArchiGen's take: the manual is part of the renderer
The current crop of comparisons is good at naming candidates. It is less good at asking whether those candidates can explain themselves. That omission favors the best-marketed tool and the most persistent operator.
Run the image trial. Then close the gallery, hand the manual to somebody else and ask for the same controlled result. If the product disappears when its champion goes to lunch, the office did not buy a workflow.
A render button can impress in seconds. A manual has to be useful on Monday.
Evidence note: the 23 October 2026 sweep surfaced Syntina's 19-tool comparison, which says it checks tools against vendor documentation, Chaos's six-tool comparison and the current Chaos Veras page. Product statements remain attributed vendor or publisher claims. ArchiGen did not test these products for this article; the documentation exercise is an editorial procurement method.