Retrieval and grounding
The machinery is largely solved; the corpus is the problem, and no amount of retrieval compensates for material that is wrong.
Grounding a model in a company's own material is the most requested capability here and the one whose difficulty is most consistently misplaced. The retrieval machinery is close to a solved problem. The corpus is not: it lives in four places, runs three versions deep, and some meaningful fraction of it is out of date in ways nobody has mapped.
The first question is what the corpus actually is and who maintains it. Retrieval over an unmaintained shared drive returns the contents of an unmaintained shared drive, now phrased fluently and delivered with no hedging, which is strictly worse than the drive itself because the fluency reads as authority.
Superseded material is the specific failure mode. A policy replaced in March and a copy of the version it replaced sitting in a subfolder are equally retrievable, and nothing in the model can prefer the current one unless the index carries that distinction explicitly. Recency of file modification is not that distinction, and it is what most systems substitute for it.
Answers carry citations, and a citation is a link to the passage, not a filename. Without one there is no way to check an answer, and an unverifiable answer from a system that never sounds uncertain is more dangerous than no answer at all — it will be believed at exactly the rate it is wrong.
Permissions are applied at query time against the person asking, not baked into the index once when it is built. A system able to quote a document to somebody who could not have opened it has created a data leak with a conversational interface, and it will do so without logging anything that looks like an incident.
Freshness is engineered, not assumed. When the underlying material changes the index changes with it, because index staleness is invisible from the outside: the system keeps answering confidently from content that was withdrawn a month ago, and nothing about the response indicates it.
Chunking and document structure carry more of the answer quality than the choice of model does. A table split across two chunks answers wrongly rather than not at all, headings that establish which product a section refers to are frequently discarded during ingestion, and a great deal of apparent model failure is structure that was destroyed before the model saw it.
The system is built to say when it does not know. A retrieval pipeline that always returns something will return the nearest available passage regardless of whether it bears on the question, and that failure is indistinguishable from success at a glance, which is what makes it expensive.
Where the corpus cannot be made trustworthy inside the engagement, the recommendation is to fix the corpus first, and we say so plainly. A documentation problem wearing a technology costume is still a documentation problem, and it gets more expensive once a system is answering from it.
What this does not cover.
- Indexing a corpus nobody maintains, on the premise that retrieval will compensate for its condition.
- Answers presented without a traceable citation to the passage behind them.
- Permissions applied once at indexing instead of at query time against the person asking.
Artificial Intelligence
Readiness assessment
A scoped engagement producing a written roadmap, structured so that it can conclude the organization should not build the thing it came to discuss.
Evaluation
Written cases and a defined notion of wrong, measured repeatedly, because upstream model changes alter behavior with no change to the code.
Document processing
High volume, narrow judgement, a known cost per error — the work that most reliably pays for itself.
Assistants and in-product features
The format businesses ask for first, which suits fewer problems than the alternatives nobody asks for.
Guardrails and failure behavior
Untrusted content treated as data rather than instruction, outputs validated before use, and nothing irreversible triggered without confirmation.
Cost and operations
Usage-based pricing makes the bill a function of success, which inverts the usual relationship between adoption and cost.