Writing from practice

Field Notes.

Observations from practice. The decisions that worked, the ones that didn't, and what the data should have said in both cases. Written for practitioners who are serious about the craft.

Practice Enablement

How to measure training when nobody wants to measure training

The frameworks exist. The methodology is not the problem. The problem is that measuring outcomes requires being accountable to them — and that is a different conversation entirely.

Practice Enablement

The forgetting curve is not your enemy

Ebbinghaus showed us that retention decays predictably. What he did not show us is that the decay is front-loaded — and that the design decision that defeats it is not repetition. It is the quality of the first encoding.

On-prem AI is not a cost decision. It's a sovereignty decision.

Every cloud versus on-premises AI debate I have watched starts in the wrong place. It starts with cost. The actual forcing functions — the ones that make the architecture non-negotiable — are legal, jurisdictional, and contractual.

The €40M problem: why the most expensive engineering failures are invisible until they're not

12,000 deployed units, six disconnected telemetry systems, and a reserve that exists because nobody designed the intelligence layer. This is what an architectural gap looks like when you translate it into a number.

The Architecture Decision Record as the most underrated design artefact

A document that records what you decided is useful. A document that engages the strongest objection to that decision — and answers it — is evidence of how you actually think.

When a model merge beats a fine-tune — and how to know which problem you have

Fine-tuning is the default answer when you need a model to do more things. It is not always the right answer. If the capabilities you need already exist in separate models, merging their weights is faster, cheaper, and more reversible.

HITL is not a checkbox — it's a write-path lock

The difference between process compliance and structural compliance is the difference between a policy that says a human must review AI decisions, and a system that physically cannot proceed without one.

Zero-trust is not a network configuration — it's an architectural philosophy

BeyondCorp, VPC-SC, CMEK, Workload Identity, and an append-only audit ledger are not five security features. They are one idea, expressed at five different layers of a GCP architecture.

Practice Enablement

Bloom's Taxonomy is a production checklist, not an academic framework

I thought I was applying it. A senior colleague sat in on a session and showed me I had imposed a ceiling on my participants — without knowing it. The distinction between the levels is not theoretical. It is the difference between a practitioner who knows and one who can act.

Practice Enablement

Motivation is not your job. Removing demotivation is.

Every trainer I know has tried to energise a disengaged room. Almost none of them asked what made the room disengaged in the first place. Those are not the same problem — and they do not have the same solution.

Designing multi-agent systems that don't become multi-agent messes

"Agent swarm" is an architectural smell if you haven't first defined what each agent owns, where its authority ends, and what the system does when it fails. Complexity is not a feature. It is a risk surface.

The token limit is not the bottleneck. Your memory architecture is.

Bigger context windows are a distraction. The real problem in long-horizon agent deployments is not how much the model can hold — it is what gets evicted, what gets reinjected, and what the system does when it can no longer see its own history.

Practice Enablement

The problem with learning objectives nobody talks about

Everyone writes them. Nobody holds them accountable. The reason is hiding in plain sight — in the verbs. A learning objective written with the wrong verb is not a lower-ambition objective. It is a structurally different claim about what training is for.

Practice Enablement

Real use cases are not a nice-to-have. They are the entire point.

Most training programmes treat use cases as illustration. The programmes that actually produce practitioners treat them as architecture. The difference is not stylistic — it determines whether the learning transfers to production.

RAG is not a feature. It's a constraint decision.

Everyone talks about RAG as something you add to a system. Nobody talks about the four architectural trade-offs you lock in the moment you choose it — usually without realising that is what you are doing.

Fine-tuning is not the answer to a bad retrieval system

When a RAG system gives wrong answers, the instinct is to reach for the model. Almost every time, the problem is upstream — in how the documents were chunked, how the query was routed, or what the retrieval layer was actually returning.

Practice Enablement

Why most technical training fails before it starts

The room isn't where it goes wrong. The room is just where you find out. The structural failure is earlier — in a design process that asks what to cover, rather than what practitioners need to be able to do when they leave.

Practice Enablement

What happens in the brain during technical training

The brain is not a hard drive. After training over a thousand participants, I can tell you exactly what it is doing instead — and why most training programmes design straight past it.

The model is the last thing you should worry about

The AI conversation is obsessed with which model to use. In most applied ML projects, the model choice is one of the least consequential decisions you make — and it is almost always made too early.

You don't have a data problem. You have a question problem.

Most ML projects fail before a single model is trained. Not because the data was bad or the algorithm was wrong — because nobody stopped to check whether they were solving the right problem.

No notes in this category yet. Check back soon, or read everything under All.

Stay informed

New Field Notes
by email.

To receive new Field Notes directly, send an email to the address below.

Write to info@datadomine.com

Subject line: Field Notes