TVET Planning Doesn’t Need More AI. It Needs Structure.

A conversation with Timo Wohlin-Elkovsky, on why the obvious AI answer is quietly making procurement worse, and what to do instead.

Editor’s note: TVET Journal’s founder, Timo, is building TVET.AI, a tool referenced at the end of this piece. We’re publishing this as a disclosed founder perspective, not as independent coverage. Read it as one practitioner’s argument, and judge it on its merits.

You’ve spent fifteen years around technical training equipment, in dozens of countries. What does that vantage point show you that most people in this sector miss?

That the equipment is almost never the hard part. Anyone can produce a shopping list of lathes, PLC trainers and welding bays. What’s hard, what almost nobody does well, is connecting that list back to a defensible reason. Why this equipment, for this skills gap, at this institution, against this policy objective.

When you’ve sat on both sides of enough of these projects, you stop seeing labs and start seeing a broken chain of reasoning. A ministry writes a strategy. A donor funds a project. A consultant writes a feasibility study. Someone, eventually, buys equipment. And by the time the equipment arrives, almost no one can trace a clean line from the original need to the thing that got purchased. The links are there in theory. In practice they’re rebuilt from scratch, by hand, every single time.

Walk us through where that actually breaks. Be concrete.

Picture a consultant who’s just won a TVET modernization project. Their first task is a gap analysis. So they sit down with a 300-page feasibility study, a national skills strategy, a labour market report, and a Terms of Reference, and they start reading. Highlighting. Cross-referencing. Building a spreadsheet of gaps from memory and intuition.

This takes weeks. It’s largely unstructured. And here’s the part that should bother everyone: three other projects in three other countries have already done a near-identical exercise, and none of that work is reusable, because it lives in someone’s Word document and someone else’s head.

Then the gap analysis becomes a list of priorities, the priorities become a list of labs, the labs become an equipment budget, and at each handoff, a little more of the why leaks out. By the time you reach a two-million-euro equipment line, the honest answer to “why this, and not that?” is often “because the consultant has built one like it before.” That’s not a scandal. It’s just the state of the art. And it’s a planning cycle that routinely runs twelve to twenty-four months.

The reflexive answer right now is “use AI.” You’re skeptical of that. Why?

Because the reflexive version of “use AI” means opening ChatGPT, pasting in a tender document, and asking it to write the analysis. And for a sector where every recommendation eventually has to survive a procurement audit, that’s not a shortcut, it’s a liability.

I want to be careful here, because I’m building an AI tool, so this sounds self-serving. But it’s the opposite. The most important thing I’ve concluded is that general-purpose AI is the wrong tool for this job, and the rush to use it that way is going to burn people.

The question that kills a procurement isn’t “is this a good answer?” It’s “can you show me, line by line, where this answer came from?”

Spell that out. People are already pasting tender documents into chatbots and getting useful-looking answers. What’s actually wrong with it?

Three things, and they all show up at the worst possible moment, in front of an auditor.

First, traceability. A general chatbot gives you a fluent paragraph. It does not give you a defensible link from each recommendation back to the specific page, clause and piece of evidence that justifies it. In donor-funded procurement, that link is the deliverable. An answer you can’t trace is an answer you can’t defend, and an answer you can’t defend gets struck.

Second, consistency. Ask the same model the same question twice and you get two differently-worded answers. That’s fine for drafting an email. It’s disqualifying when you need the same gap, scored the same way, to mean the same thing across a 40-institution programme.

Third, confident error. These models will produce a clean, plausible, completely invented justification without flagging it, and it reads exactly as convincing as a real one. In a context where a wrong recommendation can mis-spend millions of public money, “usually right and always confident” is a dangerous combination.

So the irony is this: the more impressive general AI looks, the more it tempts people into exactly the workflow that procurement can’t accept. It makes the output faster and the defensibility worse.

So what’s the alternative? What does “structure” actually mean here?

It means doing the boring thing properly. Instead of asking a model to “analyse this document,” you force every step through a fixed structure: a defined vocabulary of gap types, modernization categories, equipment groups; a fixed sequence of stages; and this is the key part; a rule that nothing can appear in the output unless it’s linked to the evidence that produced it.

You stop treating the document as a prompt and start treating it as a source you have to cite. The output isn’t a fluent essay; it’s a structured, traceable object. Every gap points to the page it came from. Every priority shows how it was scored. Every equipment recommendation maps back to the gap it’s meant to close. It’s less impressive to read and infinitely more defensible to procure against.

That’s the whole insight, really. The value isn’t the AI. The AI is plumbing. The value is the structure the AI is forced to operate inside, because that structure is what survives an audit, and surviving the audit is the actual job.

That sounds like a lot of unglamorous work. Why build it now, and why you?

Honestly? Because I got tired of waiting for someone else to build it, and because fifteen years of watching the same chain break in the same places means I happen to know exactly where the structure has to go. The hard part here was never going to be the software, it’s encoding the domain knowledge, the vocabulary of how this sector actually plans and procures. That’s the part you can’t shortcut, and it’s the part I’ve spent a career accumulating without realising I was doing it.

So we’re building it. The first thing it does is the narrow, painful task I described at the start: you give it the Terms of Reference and the supporting documents, and it gives you back a structured, evidence-linked gap analysis, the thing that currently takes a consultant weeks and isn’t reusable afterwards. That’s the foundation. The longer arc is to carry that same traceable thread all the way to a procurement-ready specification. But it starts with the gap analysis, because that’s where the chain breaks first.

It’s early, and I’d rather be honest about that than oversell it. It’s not a finished platform. It’s a working idea that needs real projects and real documents to sharpen against.

So what are you actually asking readers to do?

Not to buy anything. I’m looking for a small number of design partners; consultants, agencies, ministries doing this kind of planning work, who feel the pain I’ve described and want to shape the tool while it’s still being built. The first people in get the most influence over what it becomes.

If that’s you, you can see what we’re building and request early access at tvet.ai. And if you think I’ve got the diagnosis wrong, I’d genuinely rather hear that, write to me. The whole point of doing this in public, is to find any flaws in my own thinking.

Share this:

Leave a Comment