A lending-software vendor

The vendor sells software for loan origination and management to banks and lenders. Two customer constraints shape everything: data has to stay inside the customer’s own environment, and customisation has to be done by configuration rather than by code. That rules out the easy answer of calling a large hosted model, and it makes small models worth a serious look rather than a slogan.

I began by writing up the working case from the strategy meeting, separating what was agreed from what was only discussed, and flagging the inconsistencies between the two. That document is unglamorous and it is the most useful thing I produced, because it stopped three different understandings of the plan from travelling onward as one.

I proposed a layered design: small adapters on a small base model, so one trained base can serve many customer-specific behaviours without a model per customer.

Then a three-track approach whose first track is the one people skip. Build the measuring instrument before choosing a model: a test set drawn from the vendor’s own work, and a human-agreement ceiling, so there is a number that says how well two experienced people agree on the same case. Without that ceiling, a model score has nothing to be compared against, and every later argument about which model to buy is unresolvable.

I explained the architecture and the training data it needs in a 31-slide deck, and wrote myself a 14-lesson course on small language models first, as my own technical baseline. I would rather build the baseline than borrow a vendor’s.

No outcome was measured. The work is advisory and ongoing, no model has been chosen, and there is nothing in production to report.