How Clex is built
In-house language technology, care-specific corpora, and local processing for Scandinavian care documentation. Clex is built for a narrow job, with free text kept on the device.
Clex builds language technology for one narrow job: helping care staff write correct care notes in Scandinavian municipal record systems. Word prediction, read-aloud, and translation run on the device. When a pictogram-based sentence is requested, Clex sends only the pictogram identifiers and selected language to the Clex API. The technical promise is not “more AI”. It is a smaller data path for a more specific task.
In-house language technology, not generic text generation
The writing support is built on an in-house pipeline: data curation, tokenization, training, evaluation, compression, and deployment. Our engineers own the decisions that matter: which data, which register, which evaluation criteria, and which device constraints. A kommune adopting Clex is not asking a general-purpose text model to guess at care documentation. It is using tooling built for this job.
Corpora built for the register of Scandinavian care
A general-purpose model treats a care note as ordinary prose. We treat it as its own register: the abbreviations, the IBIC anchoring, the Ældrelov proportionality, the body-zone vocabulary, the clinical shorthand a night-shift substitute writes at 23:47. Our training data is curated, licensed, and deliberately built for Scandinavian care documentation, not a general web scrape with a domain adapter bolted on. The model we ship knows what a care note looks like before it has seen the first keystroke on a shift.
Edge-first, by design
Clex is designed to keep the care worker’s text where it was typed. Local features run on the device or in the browser. Sentence suggestions are requested through a minimal API flow that uses pictogram identifiers and language codes, not the user’s free text. Four properties work together: free text stays local, staff get immediate help while writing, the product remains useful offline, and the server-side data path stays narrow.
Compact models, carefully optimized
The model our team ships is small by the standards of a frontier-scale cloud LLM. On the narrow task of Scandinavian care-note completion, on the narrow task of Scandinavian care-note completion, it matches or exceeds those frontier-scale models - because narrow tasks reward specialization, and specialization is what gives an in-house team that owns its corpus an advantage no general-purpose vendor can match. The work that makes this true sits in the tokenization for Scandinavian healthcare vocabulary, in the fine-tuning recipes, in the evaluation harness that tests against real care-note fragments rather than generic benchmark suites, and in the quantization pipeline that fits a production-quality model into the memory budget of a five-year-old Android phone without sacrificing suggestion accuracy.
The case for edge deployment
The assumption that bigger is always better no longer holds for narrow domains. A specialized compact model - trained on the right corpus and register, and deployed where the data already lives - beats a general-purpose cloud model on speed, cost, sovereignty, and quality on the narrow tasks it was built for. We built Clex on the premise that municipal care documentation is exactly that kind of task, and that the next ten years of care-tech AI will play out on the device, not in the data centre.
Further reading
For the fifteen most common procurement, DPO, and IT-department questions, see the FAQ. To discuss training data, evaluation, local processing, or the minimal API flow in depth, contact Uffe Gorm Pal Hansen directly.