Anatomy of an exposed AI stack
The five checks we run to find out how exposed a stack actually is: weights, logs, jurisdiction, terms drift, and exit cost. A checklist you can run on your own.
Work notes
Method, in the open.
Work notes are how we think and build, written down. Architecture we reach for, checks we run, regulation turned into tickets. No client names, no numbers we have not verified. Client projects are written up separately, on cases.
Work notes
A reference architecture for sovereign ML
The stack we reach for when a system has to run on-prem for a decade: open-weight models, portable serving, and an exit path at every layer.
Getting models onto the factory floor
Our checklist for taking a model from a GPU workstation to constrained hardware: quantisation, latency budgets, and what breaks on the way.
Turning the EU AI Act into engineering tickets
Risk classification, data lineage, model documentation: how we translate regulation into backlog items a team can actually ship.
Our standard
Method,
Method,
not marketing.
A work note documents how we build, not who we built it for. It exists so an engineer can check our reasoning before a single call, and so a buyer can see the constraints we work under rather than a claim about results.
Every work note carries
- A stated problem: the constraint the note is about, named before the method.
- The method itself: what we do, in enough detail to be argued with.
- A date: so you can judge how current it is.
- A source for every figure, or no figure at all.
What a work note is not
Start the conversation
Bring us the constraint.
If a note above describes a problem you have, the next step is a conversation about your constraints, not a proposal. Start with a two-week ML Feasibility Sprint (fixed scope, från 95 000 kr).