Technical software, calculation programmes and advanced data analysis.

The situation. A company designs made-to-order components whose sizing requires regulatory checks. For more than twenty years the work has gone through an in-house calculation programme, on a development platform that is no longer supported, with proprietary file formats that were never documented. The programme works, but nobody can change it with reasonable safety. And the specifications do not exist: the rules live inside the code and in the experience of a single designer.

What was done. The requirements were not collected; they were reconstructed. The work reads three sources in parallel — the source code, the archive of projects actually delivered, and the technical office's indications — and collides them with one another: every rule extracted from the code is checked against the data and taken back to the expert, every indication from the expert is checked against the code. No statement is accepted on trust, neither the expert's nor the code's; what cannot be verified is declared as such instead of remaining implicit.

What changed. The company stopped depending on knowledge that existed in only one place. What had been tacit became a document that can be discussed, and together with the map of the system came the list of inconsistencies that nobody could still see, including divergences between what the manual prescribes and what the programme actually runs.

The situation. An organisation receives requests by email, in free form, written by different people. Each case requires precise data, some of it verifiable only by crossing several pieces of information, and produces official documents on fixed templates. Qualified time is spent on carrying data: rereading, asking for the missing item, waiting, recopying the same fields into several documents, chasing whoever must complete their part. The bottleneck is not the decision: it is the carrying.

What was done. An assistant watches the inbox. It reads the message, extracts the data, checks them against the organisation's conditions and replies in plain language explaining which item is missing and in what form it is needed, instead of sending back an empty form. Above it works a manager that knows the life cycle of the case: how many times the same item has already been asked for, whether whoever must complete their part has replied within the stated days, whether the applicant already has an open case. After a declared number of fruitless exchanges the case is frozen, instead of feeding an endless exchange.

What changed. When the case is complete, the official documents come out already filled on the organisation's templates, with the fields populated from validated data. Qualified time returns to the judgement of merit, which is the only part that really required an experienced person.

The situation. When a company sends crews to customers, the weekly programme is born from dozens of constraints that get in one another's way: addresses scattered over a wide territory, time windows imposed by customers, commercial priorities and legal deadlines, durations that change with the type of job, crews that are not interchangeable. Made by hand the plan always comes out feasible but never efficient, and there is no benchmark to notice the difference.

What was done. The problem is formulated as a routing problem with time windows and solved with an optimisation solver. A first level distributes jobs across the days, balancing crew capacity and placing the heaviest jobs first. A second solves each day as a multi-vehicle route, with real travel times taken from a road service and time windows treated as constraints that cannot be broken.

What changed. The manager receives a plan ready to use: routes on a map, a daily calendar per unit, kilometres, driving hours and crew saturation. And the same plan is regenerated in a few seconds when a constraint changes, which is the part needed at once, when someone drops out.

The situation. Recognising catalogue items from a photo is expensive if every site must first collect and classify photographs by hand, and the catalogue changes every day. That is what makes activation times prohibitive for traditional solutions in this kind of service.

What was done. The alternative approach is to describe the catalogue instead of showing it. The day's items are loaded in declarative form — name, category, extended description, ingredients, quantities — and a general-purpose multimodal model recognises from those descriptions, not from an archive of labelled images. The system also handles composed items, with portion coefficients, so that the values stay correct when half-portions of different products sit in the same choice.

What changed. Activating a new site means loading its catalogue. Dedicated hardware is not needed: the person's smartphone is used, with no kiosk and no readers. And the cost scales with traffic, instead of being the fixed cost of a presence that has to be kept even when ten people pass.

The situation. Whoever is accountable for the mandatory training of tens or hundreds of people keeps the status on spreadsheets that age with every hire and every change of role. The risk is not theoretical: it is noticing an overdue expiry during an inspection, with what that implies for occupational safety.

What was done. The problem is not calculating a date. It is holding together people records, course history and periodicity rules that differ by role and by activity, and calculating for every person and every obligation one of four states: valid, due within the threshold, expired, never taken. From there come the training matrix readable at a glance, the reminders in a formal register and the periodic report.

What changed. When the matrix exists, the work becomes scheduling the courses instead of reconstructing the status. Personal data stay on the organisation's server: no sending to external services, obtained as an architecture constraint and not as a statement of intent.