Most vendor pages in this category open with a number: an accuracy rate, an uptime figure, a deployment timeline, a cost saved. We are not going to do that here. Not because the numbers are hard to write down, but because most of them are not knowable in the place a product page puts them - before there is a customer, a workflow, or a body of source material to measure against. This page is a list of claims we will not make, the reason for each, and what we will actually tell you when you ask.
Accuracy percentages
A single accuracy number, quoted without the corpus and the question set it was measured against, does not describe anything. Accuracy is a property of a specific workflow running against specific source material - a particular set of policies, or a particular claims history - evaluated against questions that a qualified person in that domain can actually check. Move to a different set of documents or a different kind of question and the number moves with it. So we do not publish one. When it matters, it gets measured with the customer, on their material, against their own review - not printed on a page for everyone.
Uptime figures
Uptime describes a deployment: a specific box, on a specific network, doing a specific job over a specific stretch of time. It is not a property of a product line, and quoting one before a deployment exists is quoting a number about nothing. If you deploy the system, uptime is measured for your installation, under the support terms you agree - not something we advertise in advance for all of them.
Deployment-time promises
You will not find “live in 24 hours” or any variant of it here. The actual work of standing up a deployment is scoping the workflow and getting the right source material approved and loaded - the manuals, schematics, or records that answers will be drawn from. That work is not padding around the real project; it is the real project, and how long it takes depends on how much material there is, how it is organized, and who needs to sign off on it. A fixed number would be a guess dressed up as a fact.
ROI and cost savings
Any claim about what a system saves an organization - hours, dollars, headcount - is a claim about that organization’s own processes before and after. We do not run those processes, so we are not in a position to measure the difference, and a number we did not measure is not one we will assert. If you want to know what a deployment would be worth to your operation, that is a calculation you run, on your numbers, with visibility into what actually changed.
Customer names and testimonials
We do not publish customer names, logos, or quotes. Absent permission and an actual deployment behind it, a testimonial is set dressing - words attached to a page to make a claim feel more credible without making it more true. If a customer wants to speak publicly about their own deployment, that is their decision to make and their story to tell, not ours to stage.
Autonomy
The system does not decide anything on its own. It surfaces an answer, with the source it drew from, to a person qualified to judge whether that answer is right. That person approves, corrects, or rejects it. We are not going to describe that arrangement as autonomous, self-directed, or anything else that implies the human step is optional - it is not optional, and describing it as such would misstate what the system is for.
A claim we cannot check is not a claim we get to make.
What a consultation is actually for
None of the above is an argument for taking our word for it instead. It is an argument for finding out the specific things listed above - for your workflow, your source material, your organization - rather than reading them off a page written before any of that existed. A consultation is where that happens.
Concretely, that conversation covers:
- Which workflow is in scope - the specific, bounded task the system would support, not a general claim about “AI for your industry.”
- Which source material would be approved and loaded - the manuals, schematics, or records the system would actually draw answers from, and who at your organization signs off on that list.
- Who reviews the output - the qualified person or team responsible for checking answers against the source before anyone acts on them, and how that review is recorded.
- What would count as this having worked - the concrete outcome you would look for, measured on your material, by your people, on your terms.
That is a longer conversation than a number on a page, and a less satisfying one to skim. It is also the only version of any of these claims that means anything. If you want the version that applies to your own workflow, that is what the consultation is for. In the meantime, our position on what a deployment should and should not be trusted to decide is laid out at responsible AI and AI safety.