What are the components?
Ingestion: PDFs, scanned schedules, addenda versions, portal formats, parsed, chunked, and versioned so addendum 3 does not silently coexist with addendum 1. Evaluation: prompts, criteria, and scoring logic versioned like code, because unversioned prompts drift. Evidence: every conclusion traced to a pack location, or the output is unusable; see the error-check protocol. Permissions: who may upload what, where data goes, what the buyer’s confidentiality terms permit, decided with the pack, not after it. Maintenance: model changes, pack-format changes, evaluation tuning, and the reviewer feedback loop that keeps the system honest.
What does it cost to run?
Illustrative model: labelled assumptions, not quotes. Recheck current API pricing before relying on any figure; model prices move quarterly.
| Cost line | Illustrative assumption | Annual figure |
|---|---|---|
| Build (one-off, amortised) | 200 engineering hours at $180 | $36,000 year one |
| API spend | 50 tenders a year, heavy packs, assumed unit economics | $3,000–$8,000 |
| Reviewer verification time | 2 hours per tender at $180, 50 tenders | $18,000 |
| Maintenance and tuning | Half a day a month of engineering | $10,800 |
Year-one illustrative total: roughly $68,000–$73,000 before the opportunity cost of the people involved, against a pilot that measures whether verification time actually falls. Run the 30-day pilot on a vendor tool first; the comparison number is the point of the exercise. Portability and exit (what happens to decisions and content if you leave any tool) is a wave-9 page; design for export from day one regardless.
What does this mean for the bid/no-bid call?
Nothing directly, and that is the warning. A firm that builds tooling instead of gating tenders has automated the wrong end. Gate first with the scorecard, measure verification burden with the protocol, and only then decide whether the build earns its headcount.