Most work starts the same way, on fixed terms: one week, one question your staff answer over and over, working on a live URL against your own documents. Not a prototype in a notebook — a thing you can use and judge.
I read your documents and tell you what's in them, what isn't, and what the system will refuse to answer. You get that in writing before anything is built.
One question answered properly: a working assistant on your own documents, deployed, with the source for every answer attached.
Before any of that, we work out what the problem currently costs you — hours a week, times a wage. If it doesn't obviously pay for itself, I'll tell you, and you shouldn't buy it. Software that saves four hours a month isn't worth either of our time.
If it works and you want more of it, the build that follows is scoped from what that week found and quoted fixed, with half this fee credited against it. If your documents can't support it, you'll know in the first two days — with a written account of exactly where the gaps are. That's worth having whether you build anything or not, and it's a great deal cheaper than finding out in month four.
Half the fee up front, half on delivery. If it doesn't end with something working on your own documents, the second half isn't invoiced — you keep the assessment either way. The engine refuses to publish answers it can't stand behind; it would be odd to bill for work that didn't.
Running systems need looking after. That's a monthly retainer, agreed up front — not a surprise invoice.