Each one takes a problem a company would recognise, works it end to end, and reports what happened, including what didn’t work.
We can’t share real client work, so we built cases we can. They are deliberately simplified versions of problems most companies meet, and they run on either synthetic or publicly sourced data with a known answer key, so that results can be checked. Each entry below is a summary; the full case study with the data, the method and the misses, is linked at the end of each.
The work we take on goes well beyond what these cases show. Our technical co-founder is a professor of machine learning with a range of published work.
Month-end at Jalavakoski Konepaja in Tampere arrives as raw text exports from five SAP transactions. The reports have fixed-width columns, German number formats and totals rows distinguishable from line items only by their indentation. One person has read them competently for two decades, and retires this year.
We set a language model to parse the reports, then watched what it did. When the same report type came back looking the same way several times running, a second system wrote an ordinary Python parser for that type and took the model out of the loop. The model stayed on for anything the parsers hadn’t seen before. 184 of 240 reports, 76.7%, finished on the generated code at an estimated two fifths of the all-model cost. Across the whole run, field accuracy was 99.95% across 172,196 fields.
The same method runs on PDF invoices at Pyökkipaja in Lahti, supplier by supplier. The ceiling there is the supplier base itself: eight of 26 suppliers send enough for the system to learn their layout, and the rest send too rarely. 117 of 198 invoices, 59.1%, finished on parsers. The nine parsers cost roughly what they saved in year one; from year two the stream runs at about a seventh of the all-model cost.
We ran the same method on 150 real contracts filed with the SEC, with expert annotations published alongside them as the answer key. Eight matchers survived to the holdout and answered 173 of 176 questions, 98.3%. Four of twelve predictions about which categories would automate were right, and about 15 of the 80 disagreements between our pipeline and that key were arguably the key itself.
Read the ERP case
Read the invoice case
Read the contracts case
At Leena’s retirement party, the finance manager is quietly doing the arithmetic. Leena has been copy-pasting twenty SAP reports into spreadsheets every month for twenty years, and she will be missed for the pulla she baked and, now, for knowing what all those columns mean.
Those reports arrive as plain text exports.
The company can rebuild the system, which is a seven-figure project, or it can put a language model on the reports, which works immediately but costs money on every document. This case takes a third route.
A language model reads each report and turns it into a structured record. But after eight consistent examples of the same report type, a second system writes a simple piece of code that can read that format on its own. That code goes live only after it matches the model’s output on every earlier document of that type, and if a later document does not come out right, the document goes back to the model.
By the end of the year, about seventy-seven per cent of the documents had finished on that code. The run cost around eight and a half dollars, against nearly twenty-two for putting every document through a model. That saving grows with volume, because once the code exists for a format, a routine document costs nothing. Most companies will not be dealing with only twenty SAP reports.
Although the real comparison, of course, would have been replacing the system with a new one that in time becomes the next legacy system. Everything here is invented. The method works on real exports, but how much of your stream ends up on code instead of on the model depends on what your own reports look like.
If you’d like to see what we could solve for you, write to us at hapax.fi.
The monthly board pack at Paju Consumer Products, a Nordic personal-care company, is usually correct and rarely carries the cause. The reason behind a 12% rise in material cost sits three drill-downs below the line item, in a table nobody opens before the meeting, so the obvious explanation goes into the commentary instead.
We gave three independent agent runs access to the ledger behind the board pack, each blinded to the others and to the answer key, and asked each to explain the flagged numbers or confirm that nothing was wrong.
They produced thirty findings with no false positives among those worth acting on. All four planted stories were found by every run, though two of the sharpest pieces of evidence in the data went unclaimed by any of them.
At Paju Consumer Products, Timo in controlling is writing the commentary the night before the board meeting.
Material costs are up twelve per cent and gross margin is down three points, both numbers are right, and neither one tells him whether the cause is commodity inflation or something in the product mix.
The cause sits in the product-level detail that nobody opens before the meeting, so the obvious explanation goes into the commentary and the board moves on.
We built two years of monthly financials for a fictional Nordic consumer-goods company, and we hid four scenarios in the data.
In one, a promotional programme shifts volume into a higher-cost line. In another, a single customer’s receivables grew from about two million to nearly four and a half million euros behind a sale-and-leaseback. A third showed revenue growth in the Baltics that was bought with escalating discounts. And the fourth was a trap: a January revenue drop that is just seasonality.
Automated arithmetic raised about three hundred and thirty flags in twelve months, and all were correct. But a flag only says something moved, not why. Three independent AI analyses each went through the data on their own, blind to each other and to the answers, and had to explain what was behind those flags with evidence from the data.
All three found all four scenarios. Every run traced the cost rise to the product mix, citing flat unit costs.
Each one named the customer behind the growing receivables and traced the sale-and-leaseback that was keeping the earnings comfortable.
The Baltic growth came back in every run as bought with escalating discounts, with margin falling. And the January drop was identified as seasonality.
Across thirty findings, no false alarms worth acting on, and no cited figure was wrong.
The company’s financials are entirely invented, but the method transfers to a real month-end. Run the arithmetic, then the blind analyses, then check what comes back, and the board gets the cause behind every flag, and the evidence for it.
If you’d like to see what we could solve for you, write to us at hapax.fi.
Saarnitukku’s purchase ledger runs to 50,000 rows at a Vantaa wholesaler turning over about €90 million a year. An e-invoice integration posts four in five; six people in accounts payable post the rest. Nobody reads it end to end.
We screened it three ways. Seven deterministic rule tests ran the audit classics: duplicates, round sums, threshold games, weekend postings. An Isolation Forest flagged statistical outliers. And three independent, blinded agent runs triaged the 39 groups the first two layers raised, calling each group genuine or benign, with evidence.
The rules hit 75% precision on the planted anomalies, and the Isolation Forest caught none of them. The agents got 37, 35 and 38 of the 39 right, but the slow price drift the case was built around was found by no layer at all. A follow-up drift report caught three freshly planted drifts on new data, though it still can’t see vendors who bill too rarely to build a baseline.
At Saarnitukku in Vantaa, Tiina in accounts payable is posting a steel supplier’s July invoice whose memo notes, in Finnish, that freight is now included in the goods price. That explains the higher total, and she moves on, because there are two hundred vendors in this ledger and each invoice arrives on its own.
Saarnitukku turns over about ninety million euros a year. That purchase ledger runs to roughly fifty thousand rows, most of them posted by an e-invoice integration, with Tiina and five others in accounts payable handling the rest. Nobody reads it end to end. Raising flags on a ledger this size is easy, but what is scarce is someone qualified to say whether each flag is a real issue or just an unusual transaction. We generated the ledger and hid eighty-seven irregularities in it across eight categories, alongside eighteen clean transactions designed to look suspicious. The correct answers were sealed in a key that nothing in the screening could see.
Seven automated rule checks raised sixty-four flags. Forty-eight were genuine issues. A statistical anomaly detector also scored every transaction and flagged the two hundred most unusual, but not one of them was a genuine issue. The flags from both layers were sorted into thirty-nine groups, and three independent AI analyses had to call every group either a real problem or a false alarm. They got thirty-seven, thirty-five and thirty-eight correct of the thirty-nine. Nobody caught the slow vendor price drift that the whole case was built around. One supplier folded freight charges into its goods and invoices and raised prices on top, reaching nineteen per cent above its first-half baseline by December. The drift moved slowly enough that no screening layer flagged it. A follow-up drift report was built to catch exactly this. It compares each vendor to its own history over time, and on a fresh year of data it flagged all five price movements. Four in the top five of about two hundred vendors. Everything here is invented, but the screening method transfers to a real purchase ledger.
If you’d like to see what we can solve for you, write to us at hapax.fi.
Sixteen tender documents sit on the desk at Visakoivu, a 180-person maintenance and installation firm in Jyväskylä, with 510 requirements between them. Someone has to answer every one without promising anything the firm cannot deliver.
We answered them twice. First, fourteen simulated individuals used a chatbot, producing 64 attempts with varying levels of completeness and accuracy. Then a structured workflow ran once per tender, checking each requirement against the firm’s verified capability data and declining both tenders the firm cannot win.
The workflow found 507 of 510 requirements, 99.4%, answering every requirement on 11 of the 14 tenders it bid on. It refused both tenders the firm cannot win, and let no fabricated claim through where twenty-two of the 64 chatbot attempts carried at least one.
At Visakoivu in Jyväskylä, Antti writes the tender responses, and the current batch has had him in the annexes since Monday. In the enclosure clause of one draft contract, between two forms that are properly required in the main document, a third sits with no clause number of its own. That tender is one of sixteen on the desk, about five hundred requirements between them. Some buried disqualifying clauses in the annexes, or mentioned mandatory forms only in passing. Two are tenders the firm genuinely cannot win.
We tested two ways of answering the same tenders. In the first, fourteen simulated people worked with a general chatbot, each with their own habits and level of attention. Across all sixteen tenders they produced sixty-four attempts, and twenty-two of those carried a fabricated claim, meaning the chatbot invented a qualification or a commitment the firm cannot back up. Their scores on individual tenders ranged from about sixty-four to about ninety-three per cent of requirements answered. In the second, one structured workflow ran once per tender. It extracted every requirement from the document and drafted each answer with a citation to the firm’s verified facts. Three automated checks ran on every draft before it could go out.
The workflow declined both tenders the firm cannot win. On the fourteen it bid, it answered every requirement on eleven and at or above ninety-five per cent on thirteen. No fabricated claim survived in any of the sixteen runs, against twenty-two in sixty-four individual attempts. The extraction step found five hundred and seven of the five hundred and ten requirements. The three it missed were mandatory forms mentioned once inside an annex, and the human attempts scored zero of twelve on the same class of requirement. The tenders are invented, and the simulated people are a model of how attention affects the result, not observed bidders.
If you’d like to see what we could solve for you, write to us at hapax.fi.
Kataja Analytics sells a dashboards-and-reporting platform from Helsinki, about 500 mid-market accounts. Hedbrunn Systems AB, a 31-seat Swedish account at €12,426 a year, never showed a usage dip. What changed was the tone of four support tickets over nine months, the last closing with “no need to treat this as urgent.”
A standard usage model reaches 0.87 AUC on that book. We added a second layer: an agent that reads each account’s support ticket history in order and scores the health of the relationship. The combination reaches 0.89 AUC and lifts recall in a top-100 review list from 59.4% to 66.2%.
The ticket layer surfaces €1.14M of churned annual revenue the usage model alone does not see. Thirty accounts churn for reasons outside the product, with no signal built in for either layer to find.
At Kataja Analytics in Helsinki, Mika in customer success is working through his monthly review of five hundred accounts, sorted by usage.
Hedbrunn Systems is in the quiet middle of the list, and its fourth support ticket in nine months has just closed with 'no need to treat this as urgent'. That list comes from a model built to predict which accounts are about to cancel. It watches how much each account uses the product. When logins drop, the model flags the account. It did not catch Hedbrunn Systems, a thirty-one-seat Swedish account at about twelve and a half thousand euros a year. Hedbrunn’s usage never moved. What changed was the tone of four support tickets over nine months. The last one closed with 'no need to treat this as urgent'.
Nobody had time to read nine months of ticket history for five hundred accounts. A language model reads each account’s tickets in chronological order, blind to usage data and to who actually left, and scores the state of the relationship. A small model then combines that ticket reading with the usage score. In the top-one-hundred review list, the combination catches about sixty-six per cent of the genuine cancellers, up from about fifty-nine per cent on usage alone. That is nine more genuine cancellers for the same amount of work. Cancellers that only the ticket reading puts in the top hundred add up to just over a million euros in annual revenue. The ones that only the usage model catches add up to about seven hundred thousand. Thirty accounts cancelled for reasons outside the product entirely, like an acquisition, a budget cut, or a key person leaving. Nothing in the data predicted them. The ticket reading also flags accounts that complain loudly but renew anyway, and the combined model corrects most of those. Everything here is invented. The five hundred accounts and nearly four thousand tickets were generated to a design with a known answer. What transfers is the approach. Reading the tickets adds signal that usage data alone misses.
If you’d like to see what we could solve for you, write to us at hapax.fi.
Haapaharju Oy rents construction equipment out of Oulu, about 120 staff, with a 30-clause policy handbook governing deposits, damage charges, late returns, cancellation windows and discount authority.
We built a pipeline that reads each incoming customer email, classifies it, retrieves the relevant policy, drafts a reply with clause citations, and checks the draft for policy compliance, consistency with any prior promises, and completeness before sending. Safety and data-request emails are escalated on classification alone, with no draft.
122 of 150 emails were auto-sent with zero gate violations, and all seven safety and data-request emails were escalated correctly. The consistency gate never fired because no draft contradicted a planted prior promise; that safeguard remains unexercised on this corpus.
At Haapaharju in Oulu, Päivi in customer service is working through the Tuesday inbox. Three emails down, a return request reads like a two-minute job, but the customer has not said whether the equipment was collected or dropped off, and until someone asks, any reply is a guess. That inbox receives about a hundred and fifty customer emails over three weeks, and a thirty-clause policy handbook governs what staff may promise. We built a pipeline to handle the routine ones automatically. It classifies each email first. Safety emails and requests for personal data go straight to a person with no draft at all. For the rest, a model drafts a reply citing the handbook clause behind each commitment, refusal or discount. Three rules then check every draft before it can be sent. One checks the draft against the handbook. One checks that every question in the email has been answered. And one compares the draft with what the company has already promised that customer in an earlier message. One hundred and twenty-two of the one hundred and fifty emails went out automatically, with no rule violation. All seven safety and data-request emails were escalated correctly. Six emails that were asking for more information were misclassified as routine and sent without review, but none of the six contained anything harmful. The firm, its handbook and all the emails are invented. The pipeline transfers to a real inbox.
If you’d like to see what we could solve for you, write to us at hapax.fi.
The evidence offered for corporate training is normally an attendance list and a satisfaction score, neither of which says whether anyone in the room can do anything differently.
At Kuusiharju, a 200-person technical trade company, we simulated forty learners sitting a two-day AI programme, with each person’s true learning planted in advance. Three instruments measured the outcome: a pre/post task-based assessment, the industry’s standard feedback sheet, and a naive evaluation that gives the same test twice and blends in self-reported improvement.
The pre/post assessment recovered the cohort effect to within 0.01 of the planted value and caught six of the seven people whose confidence rose while their competence did not. The feedback sheet correlated with actual learning at r = 0.10.
At Kuusiharju, Kaisa in HR is reading through forty feedback forms from the two-day AI course. The scores average four point two out of five, and that number is all she has when someone asks whether the programme worked. That form and an attendance list are what most training programmes leave behind. Neither measures what anyone can actually do afterwards. This case tests the measurement instrument, not the training. We simulated forty learners and set each person’s true improvement in advance, in an answer key that the instruments score against only at the end. The point is to find out whether it works before we use it on real people.
The cohort includes genuine improvers, people who learnt nothing, and seven people whose confidence rose while their actual skill did not change. Those confident non-learners are the group a feedback form cannot tell apart from people who genuinely improved.
We ran two instruments on the same forty learners. One was the before-and-after assessment we built, which uses practical tasks drawn from the course material. The other was the standard industry feedback form.
The assessment recovered the overall learning to within nought point nought one of the true value. It caught six of the seven confident non-learners. Three people built to forget most of what they learned looked fine on the day, but by eight weeks they had kept only about a fifth of their gain.
The feedback form correlated with what people actually learned to r equals nought point one oh, which is close to no relationship at all. The cohort is entirely simulated. What transfers is the instrument itself.
If you’d like to see what we could solve for you, write to us at hapax.fi.
A hiring team at Kaikuvaara Oy in Oulu has 240 applications for one signal-processing role, more than it can read carefully against the twelve requirements. The ATS keyword filter put a keyword stuffer at rank 1 and a hidden gem at rank 144.
We built a structured workflow that reads every application in full and returns an evidence dossier with verbatim citations against each requirement, without ranking the candidates or making a hiring recommendation. The point is to give the hiring team complete, auditable evidence so they can make the call themselves.
The workflow caught 14 of 15 planted credential inflations and identified 19 of 22 keyword stuffers, at 96.71% evidence recall.
At Kaikuvaara in Oulu, Hanna has two hundred and forty applications for one signal-processing role and only one afternoon to get through them. One of the candidates wrote automation and analysis scripts for a particle-physics detector, but the word 'Python' is nowhere in the application. The ATS filter ranked that candidate a hundred and forty-fourth. At number one it put a candidate who matched all twelve requirement keywords with almost nothing real behind them. Reading two hundred and forty applications against twelve requirements takes more time than the hiring team has, so we built a workflow to do it. Recruitment is classified as high-risk under the EU AI Act, which means the workflow produces no ranking and no verdict. It reads each application in full against the twelve requirements and returns a summary of the evidence it found, with verbatim quotes from the CV and cover letter. The recruiter decides. The same applications were screened four ways and checked against the sealed answer key. The workflow found about ninety-seven per cent of the required evidence. It caught fourteen of fifteen candidates whose applications contradicted their own claimed qualifications, things like a degree date that does not match. It flagged nineteen of twenty-two candidates who had packed their application with the right keywords but had no real evidence behind them. The keyword filter has no way to question a claim at all. Eighteen candidates genuinely met the requirements but described their experience in different words. The workflow matched twelve of them to the right requirements. In a separate test, twelve simulated recruiters each screened a subset of the applications twice, once on their own and once with the evidence summary beside the application. The two least strict went from spotting none of the faked claims in the subset to spotting all four. The company, the applicants and every qualification are invented. What the workflow does, reading each application against the requirements and returning evidence with citations, transfers.
If you’d like to see what we could solve for you, write to us at hapax.fi.
A data team at Tuomimetsä Oy, a 1,100-person retailer, answers about 70 requests a week. Most of the difficulty isn’t the SQL but the company’s own rules: which stores count as comparable, when the fiscal year starts, how web sales are dated. Those rules live in people’s heads.
We wrote sixty of those requests, locked the correct answers away, and tested what happens when you give an AI assistant the company’s rules in a single document or in ten packaged handbooks, versus giving it nothing but the database.
Without the rules, accuracy was 49.7%; with a single written document, 99.3%. The format of the rules made no measurable difference, and a cheaper model with the written rules outperformed the stronger model without them.
It is Tuesday at Tuomimetsä and a request arrives. Like-for-like growth by region for Q3 last year, please. The analyst knows what the company means by that. The rules are in her head and in a few pinned notes, and nowhere else. Now imagine the company points an AI assistant at the same database. On the like-for-like question, it reads the fiscal calendar, the current regions and the refit closures correctly. Nobody told it which stores are comparable, though. It guessed, and two old tables listing thirty-seven stores agreed. In four of five runs it dropped a store called Tampere Lamminpää, and West came back at two per cent instead of four point eight. Asking twice would give the same answer. With the rules written down in one document, it got the right answer in all five. That question is one of sixty, all built for an invented retailer, Tuomimetsä Oy, with the right answer locked away in advance. Without written rules the assistant scored forty-nine point seven per cent, but with the rules in one document ninety-nine point three, and in ten handbooks ninety-eight point three. The format made no measurable difference. One more finding. A smaller, cheaper model with those handbooks scored seventy-nine per cent, twenty-nine points above the main model without rules. We wrote twelve predictions before the runs and six were wrong. We expected written rules to reach sixty-five to eighty-five per cent, and they reached ninety-eight to ninety-nine. Your company has rules that determine whether a number is right. Write them down, and start with a single document.
If you’d like to see what we could solve for you, write to us at hapax.fi.
Each case starts with a design document that records what will be measured and what counts as a pass before anything is built. Deterministic code generates the data and a held-out answer key; a language model writes only the prose, from briefs that already contain the signals. Where the case tests a belief of ours, the prediction goes on paper before the run. The figures on each case page come from a marking script that reads the key, and results that come out badly are published as they ran. Ten cases use data we engineered; the eleventh runs on real contracts with an expert key published by others. The code, datasets and answer keys are at github.com/hapaxoy/hapax-case-studies, one folder per case.
The companies, people, places of work and contact details in these cases are fictional, with one exception: the contracts case runs on real public filings. Company and personal names were checked for clashes with real ones, including searches of the Finnish trade register and the open web, and contact details are obviously fictitious. If a name has slipped through and matches a real company or person, we apologise and will change it on request.