YEPA

Turning lived experience into a readable mapping

A guided interview turns what someone did into a mapping of what they can do: the competencies people carry but can’t articulate.

yepa.solutions ↗yepa.expert ↗

Role: CTO & lead engineer
Scope: Product strategy · UX & UI · AI pipeline · Backend · Infrastructure
Built with: React 19, TypeScript, AppSync GraphQL, Python 3.12, AWS Lambda, DynamoDB, Step Functions, PyTorch, AWS CDK, OpenAI
Team: Only full-time engineer, alongside two pedagogy researchers, plus freelancers and students I briefed and reviewed
Timeline: Research from Feb 2024, product build from Aug 2025, CTO since Feb 2026
Outcome: An interview anyone can take, in 15 minutes to an hour instead of 90, producing a mapping in five to six minutes instead of five to six hours. Across three rounds of testing with 36 participants, every respondent agreed the interview left them enough time to think, and the people with no prior chatbot experience gave it the highest recommendation of anyone. It all feeds two products built from one codebase: yepa.solutions for individuals, and yepa.expert, invitation-only for researchers, with code-gated campaigns, anonymous respondents and group-level analysis.

The problem

Explicitation interviews worked. The technique gets someone to describe what they actually did, not what they think they should say, but it needed a trained expert in the room. One interview ran an hour to ninety minutes, and turning it into a formal mapping of someone's competences took another five to six hours of expert work afterwards. That put the method out of reach of the people who needed it most: career changers, job seekers, and the counsellors trying to help them at scale.

My role

I own the architecture, the infrastructure, the AI pipeline and the release process, and I still write code every day. The two colleagues I work with are pedagogy researchers, not engineers, so part of the job is turning what they need into something a system can do, and telling them when what they're asking for isn't what they mean. I dispatched work to freelancers and students, reviewed it, and made every final design and architecture call.

Read as

The essentials in two minutes

Impact

23 stacks · 2 regions

Infrastructure

136 Lambdas · 27 tables

Serverless backend

94%, +12 pts over the best LLM

Card classification

4.62 / 5, 100% agreement

“Enough time to think”

38.1, in the “good” band

Net Promoter Score

The system design

01
Guided interview
A chatbot runs the explicitation interview that used to need a trained expert, adapting its follow-up questions to what the person actually says.
- Three interview engines of increasing depth: five fixed questions, nine fixed questions, or a variable per-scheme loop
- Runs in French, English, German and Italian
- Respondents on the research side need no account at all
02
Meaningful elements
The transcript is cut into the fragments that carry a claim about what the person knows or did. Not sentences, units of meaning.
- Extraction is an LLM call with a schema, not a named-entity model; a fine-tuned NER reached F1 0.024 on this data and was abandoned
- Every generated claim keeps a pointer back to the source text
03
Classification
Each element is typed against the seven concepts of the MEPA pedagogical ontology by a model trained for exactly this.
- OpenAI text-embedding-3-large feeding a feedforward network trained on 14,000 balanced samples
- 94% accuracy on 350 expert-labelled samples, 12 points above the best tuned LLM baseline
- Ships as TorchScript in a container, so a classification never leaves the platform
04
The LX Map
The typed elements are assembled into a graph the person can read, edit and reason about: competences, knowledge, cognitive strategies, tools, rules, people, media.
- Five views over one graph: global canvas, by dimension, by learning situation, hierarchical, and key links between schemes
- Edges are typed too (uses, aims at, applies, observes)
05
The tools on top
The mapping is the substrate, not the product. Tools split by intention: understand it, or use it.
- Understand: explorer, cross-cutting analysis, pedagogical diagnostic, reports
- Use: job matches, learning paths, application help, comparison against a competency framework
- Every generated output prints the source cards underneath, and names the gaps it found rather than papering over them

Platform services

AppSync GraphQL
One typed schema for both products, with subscriptions for live collaboration
Lambda
136 functions in production. The workload is bursty, so nothing runs when nobody is interviewing
DynamoDB
27 tables modelled access-pattern first; the data is document-shaped, not relational
Step Functions
Orchestrates the interview state machine and the long-running analyses
Classifier container
The TorchScript model, kept off the general API so it can be retrained independently
CDK, 23 stacks over 2 regions
Zurich for data, us-east-1 for the certificate and edge
Deploy gate
Reads the infrastructure diff and refuses to continue if a change would replace a table or a user pool

Key decisions

A model of our own, not a prompt

instead of · Classifying with GPT-5 or Claude behind a good prompt

We tested them properly (three GPT-5 sizes and the Claude family, extended reasoning, optimised prompts) and they plateaued on a seven-concept ontology a trained human applies reliably. A specialised classifier reached 94%, twelve points clear. The published result is that the difficulty was conceptual nuance, not scale. The cost is that we now own a training pipeline and a labelled corpus instead of renting an API.

Serverless, because the load is unpredictable

instead of · A monolith on a server we pay for monthly

Usage is bursty by nature. An interview happens or it doesn't, and almost every task fits inside a Lambda runtime. Paying for an idle machine to serve a product with no traffic yet made no sense. The trade is cold starts and a harder local development story.

DynamoDB over a relational instance

instead of · Postgres or MySQL, which the team already knew

An LX Map is a document, not a set of joins: nested cards, typed edges, per-user shapes that differ. Pay-per-request matched the same bursty profile as the compute. The trade is that any query nobody designed for is expensive, so access patterns had to be decided up front.

Guardrails that are mechanical, not procedural

instead of · Care, review and a deployment checklist

With one full-time engineer and real users, a rule that depends on someone remembering it will eventually not be remembered. So the deploy gate reads the CloudFormation diff and stops if a change would replace a database table or a user pool, and golden templates prove that a shared-code refactor leaves production byte-identical.

Everything grounded in the theory, or it doesn't ship

instead of · Adding whatever an LLM makes easy

The platform's whole claim is that its output is pedagogically defensible, so a feature that produces plausible text with no basis in the MEPA framework would quietly destroy the thing being sold. Generated output always prints its source cards, and the application-help tool is explicitly built to draw on the mapping rather than invent. The point is not to be one more LLM company.

In action

The LX Map. The whole of someone's described experience as one graph, with the tools split by intention: understand it, or use it.

Cross-cutting analysis: the same card appearing in several people's mappings, shown with each mapping it came from.

You describe a real situation you lived through; an AI-led elicitation interview asks the follow-up questions a trained analyst would; the transcript is then processed into an editable graph where every card is typed by a pedagogical taxonomy of competencies, knowledge, cognitive strategies, tools and rules. The taxonomy isn’t invented: it follows the research literature the platform is built on.

Two products run from one codebase. yepa.solutions serves individuals (career changers, coaches, job seekers) with tools that match a mapping against job frameworks or a specific vacancy. yepa.expert is invitation-only for researchers: a campaign gets a code-gated public link, anonymous respondents answer through the same interview engine, and the researcher gets group-level analysis across all of them.

The card classifier is my own, and it exists because the obvious approach didn't work. Sorting a sentence into the seven concepts of the MEPA pedagogical ontology looks like a job for a general model, so we tried them properly: GPT-5 in three sizes and the Claude family, all with extended reasoning and tuned prompts, measured on 350 expert-labelled samples. They plateaued. A specialised classifier, OpenAI's text-embedding-3-large feeding a feedforward network trained on 14,000 balanced samples, reached 94%. That is twelve points above the best LLM baseline. It ships as TorchScript in a container and serves every classification the product makes.

The part I’m proudest of is unglamorous: a deploy gate that scans infrastructure diffs and refuses to continue if a change would replace a database table or a user pool, plus golden templates proving that shared-code refactors leave production byte-identical. With one engineer and real users, the guardrails have to be mechanical.

What I learned

The concept at the core holds; everything around it churns. The elicitation engine still rests on the concept it launched with, and we made that concept evolve deliberately rather than freezing it, while almost every tool, rule and screen around it changed. So the thing to build carefully is the middle, and the thing to build cheaply is the edge.
What an expert understands and what a user can use are two different specifications. The pedagogy has to stay rigorous underneath while the surface stays intuitive, and translating between those two is most of the actual work.
Large models are extraordinary and they are not the answer to everything. The interesting engineering question is no longer 'can an LLM do this' but 'is an LLM the right shape for this'. For a seven-class ontology with a labelled corpus behind it, it wasn't.
A labelled corpus is the part you cannot prompt into existence. It is slow, unglamorous, and it is the reason the specialised model was possible at all.
The thing that made the chatbot work wasn't the model. It was the absence of a person. Ninety per cent of respondents said it put them at ease, and what they described was the removal of social pressure: no judgement, no fear of holding someone up, thinking at the moment that suited them. That is a design property, not a capability.

What it doesn't do

The classifier is trained to match the experts' reading of the ontology. That is the right target and also the ceiling: in pedagogy even experts disagree on the hardest distinctions, so 94% measures agreement with experts, not objective truth.
Meaningful-element extraction is evaluated on a small corpus. Within that scope it is dependable: its results hold steady across individual conversations and across successive LX Map generations over time.
The acceptance study rests on 36 participants over three rounds. Enough to steer the design, too few to support general claims.
Coverage stops at four languages: the interview runs in French, English, German and Italian, and so does everything downstream of it.