Vocabulary is the first constraint
Every sector has terms that mean something specific and something different elsewhere. General models handle common language well and specialist terminology unevenly.
We collect your actual vocabulary from your own records — product names, abbreviations, internal shorthand — and supply it explicitly. It is cheap and it improves accuracy more than most model changes.
The cases your experts argue about
Ask three of your specialists to classify the same fifty cases. Wherever they disagree is the ceiling for any system, and that number is worth knowing before you commission anything.
It is also frequently the most valuable output of the exercise, regardless of whether software follows.
Where the regulatory boundary sits
- Healthcare: anything informing clinical decisions is a regulated device question — administration is not
- Legal: extraction and comparison yes, advice and acceptability no
- Financial services: the recommendation stays a regulated activity; the assembly does not
- Employment: surfacing yes, automated rejection carries disproportionate risk
We map that boundary during scoping and write it into the specification rather than discovering it at review.
What we ask before starting
- What would a wrong answer cost, concretely?
- Who checks the output, and can they check it quickly?
- What material exists to work from — documented, or in people's heads?
- Which decisions must remain human for regulatory reasons?
- Who would be accountable if this got something wrong?
Sector experience is not the same as sector knowledge
We have built in logistics, finance, legal, healthcare administration, property, manufacturing, education and recruitment. That gives us pattern recognition, not domain expertise.
The domain expertise is yours, and the projects that work are the ones where your experts are genuinely available during scoping and evaluation.