There are roughly 761,000 active apprentices in England right now. Every single one of them has to evidence their learning against a set of Knowledge, Skills, and Behaviours defined by their apprenticeship standard. This evidencing is central to End-Point Assessment - the final evaluation that determines whether an apprentice passes their programme. The tools available to help with this are, to put it charitably, not designed with the apprentice in mind.

I know this because I’m one of them, and I’ve spent more time than I’d like to admit staring at spreadsheets trying to figure out which KSBs my assignments actually cover. The process is manual, repetitive, and surprisingly easy to get wrong. You finish a piece of work, you know you’ve learned something meaningful, but mapping that back to 30 or 50 abstract KSB statements feels like guesswork. The feedback loop is slow - sometimes you don’t realise you have gaps until months before your EPA, when it’s too late to address them properly.

The tooling gap

The existing platforms in this space are all built for training providers. They’re compliance and administration tools sold B2B. They handle portfolio submission, assessor workflows, and reporting. What they don’t do is help the apprentice figure out which KSBs their work actually maps to. That’s left to the apprentice, their mentor, and usually a shared spreadsheet with colour-coded cells.

This is the gap EasyKSB was built to fill. Not another provider platform, but a tool that sits on the apprentice’s side of the table and does the hard part of KSB matching for them.

Choosing the right architecture

The core technical problem is a matching one: given a piece of evidence (an assignment, a project description, a reflective account), determine which KSB statements it covers and how strongly. This isn’t keyword matching. KSB statements are written in formal, abstract language. Apprentice evidence is written in natural, specific language. The overlap in vocabulary is often minimal even when the conceptual match is strong.

The solution is a two-stage pipeline. First, every KSB statement from the apprenticeship standard is embedded as a vector using a language model. When an apprentice uploads evidence, that text gets embedded too. Cosine similarity against the KSB vectors produces a ranked list of candidates - the KSBs that are semantically closest to the evidence. This stage is fast, cheap, and good at recall. It surfaces the right candidates but isn’t precise enough on its own.

The second stage sends the top candidates to an LLM for confirmation. The model receives the evidence text and each candidate KSB, then returns a confidence score and written reasoning explaining why the match does or doesn’t hold. This is the stage that turns a ranked list into something an apprentice can actually trust and learn from. The reasoning matters as much as the score - it helps apprentices understand what they’ve evidenced and, critically, what they haven’t.

Stack decisions

The backend runs on FastAPI with PostgreSQL and pgvector for vector storage and similarity search. Matching jobs run asynchronously through Celery and Redis, so users aren’t staring at a loading spinner while embeddings and LLM calls complete. The frontend is Next.js. File storage is on disk with hourly backups to S3, aswell as WALs for PITR. The whole thing runs on Docker Swarm behind Caddy.

Most of these choices were driven by pragmatism rather than preference. pgvector keeps the vector search inside Postgres rather than introducing a separate vector database - one fewer thing to operate. Celery handles the async workload without overcomplicating things at this scale. Docker Swarm gives enough orchestration to manage the services without the operational overhead of Kubernetes for a product that’s still finding its feet. Every piece of infrastructure earns its place or it doesn’t get added.

The coverage matrix

The feature that changed the product from “useful” to “necessary” was the coverage matrix. Individual match results are helpful, but the real value comes from seeing coverage across an entire portfolio. Which KSBs have strong evidence? Which have weak evidence? Which have nothing at all? This turns an abstract worry (“am I ready for EPA?”) into a concrete, actionable picture.

For training providers, this same view scaled to a cohort level becomes a powerful oversight tool. A programme lead can see at a glance which KSBs their learners are struggling to evidence, and adjust their teaching or assignment design accordingly. That’s the enterprise angle - same data, different lens.

Building for the people who use it

The temptation with any AI-powered product is to lead with the technology. But the apprentices using EasyKSB don’t care about vector embeddings or cosine similarity. They care about whether the tool saves them time, whether the suggestions are accurate, and whether they can trust it enough to base their EPA preparation on it. The technical decisions only matter insofar as they serve those outcomes.

Every architecture choice in EasyKSB traces back to a user need. Async processing exists because apprentices shouldn’t wait 30 seconds for a result. The two-stage pipeline exists because accuracy matters more than speed. The coverage matrix exists because knowing your gaps early is the entire point.

If you’re building a product and want to talk through architecture decisions, or if you need help getting from idea to production infrastructure, get in touch.