The technical problem determined whether the product could exist. Pasting a contract into a general purpose AI chatbot does not solve this, and not because the model cannot read a contract. It is that nothing about the answer is fixed. Ask twice and you can get different clauses emphasised, different ground covered and a different depth of analysis. A subcontractor taking a finding into a negotiation with a head contractor needs the report to cover the same ground every time, whatever contract went in.

Our architecture removes that variability by not treating the analysis as a conversation. The model works against a versioned system prompt and populates a structured data set rather than returning prose to be interpreted. The assessment framework, the scoring basis and the report structure are fixed, and a baseline set of checks runs on every contract regardless of what the document contains. The shape and coverage of a ClauseIQ report do not vary. Only the contract does.

The report itself was the other engineering challenge. The departures schedule is the deliverable that goes back to the builder, so it renders as landscape pages embedded mid document, links back to the underlying analysis, and leaves a response column blank for the negotiation. We took the client’s working prototype and productionised it into server side execution driven dynamically by the analysis output.

The AI runs on the client’s own Anthropic Claude account, so the provider relationship and usage sit with ClauseIQ. The assessment framework is theirs to tune from the admin portal, with a test facility for validating changes against real contracts before they reach a paying customer.