Learning in public: why I build glossaries and an AI learning path

*This site looks the way it does for a simple reason: I’ve been doing terminology work for years — but not from an e‑learning perspective and not from an information‑architecture perspective.

Most of the glossaries began as professional terminology lists: versioned, structured, and maintained in my Notion knowledge hub. They worked well for technical writing, but they didn’t help people who were trying to enter a topic. So I reframed them, and that reframing is what you see here: nine glossaries, an AI learning path, a knowledge vault, and a feedback page that explicitly asks what isn’t working yet.

It starts with a list that isn’t enough anymore

Many of my projects begin with a list that is technically correct but not usable outside its original context. One example was a machine safety and systems engineering term list: 358 entries, mixed languages, overlapping meanings, and distinctions that only make sense if you already know the field. “Emergency stop” and “Emergency switching off” look interchangeable until you work with machinery. “Validation” and “Verification” look like synonyms until you write safety documentation.

Before I wrote anything, I sorted. Which terms belong together? Which distinctions matter for safety, for documentation, or for the EU AI Act? Which relationships need to stay intact, even if the glossary becomes more accessible?

That work became three glossaries:

• Machine safety and safeguarding
• Functional safety and systems engineering
• Safety documentation, compliance and security

Each term now has a standalone definition, an example, a “Term facts” box with broader, narrower and related terms, and cross‑links into the other glossaries. The knowledge wasn’t mine — it was already in standards and in expert practice. My contribution was the structure: making the terms findable, readable and connected.

This is the part of terminology work I enjoy most. Information becomes useful when someone can find the right piece, understand it, and see how it fits into what they already know.

How one glossary became nine

The other glossaries grew the same way. Whenever I worked on a topic, I noticed I was building a private vocabulary. Eventually I asked myself why I was keeping it private.

So the site now includes glossaries on information architecture and ontology, DITA 1.3, AI regulation in the EU, the USA, Canada and China, the Digital Product Passport and the EU omnibus packages, and MedTech and pharma regulation. All of them are accessible from the glossary hub.

Working on them taught me things I didn’t expect. Regulatory terminology has a timestamp whether you write it down or not. A definition that was correct last spring may not be correct today. So every entry carries a “reviewed” date, and I try to be explicit about what is final and what is still a proposal or draft. That’s not a technical feature — it’s respect for readers who make decisions based on what they read.

I also learned how much structure matters. Term relations follow SKOS: broader, narrower, related — not “kind of similar.” When a broader term lists a narrower one, the narrower one points back. These rules feel strict until you connect nine glossaries. Then they are the only thing that keeps the network stable.

Why an AI learning path?

The first glossary, the AI glossary, started as a list of the terms I kept explaining to colleagues: tokens, context windows, retrieval‑augmented generation, hallucinations, model families and the brands behind them.

While writing, I realized that a glossary clarifies terminology, but it doesn’t help people figure out where to begin. And that’s exactly what many professionals I work with — technical writers, technical marketers, project managers and developers — struggle with. AI enters their daily work long before any structured learning can catch up.

So the 70 terms became six stations, from “Foundations: how AI works” to “Quality, risk and governance.” Around them I sketched the AI learning path: four role tracks, three levels, twelve modules. Each term explains why it matters for each role, because a technical writer and a developer need different things from the same concept.

The learning path today is a set of initial concepts. The structure is there, the terms are there, and a draft e‑learning course is taking shape behind the scenes. The course buttons still say “Courses are currently being developed,” and they lead to the feedback page. That’s intentional. I prefer an honest work in progress over a polished promise.

Studying digital learning

The learning path is also where my next step comes in. I’m enrolled at the Digital Learning Institute in Ireland in a program that combines the Professional Diploma in Digital Learning and the Certificate in AI for Learning.

It feels like a continuation rather than a change. As a technical writer, I’ve always been in the business of helping people learn: how to use a product, how to do a task safely, how to understand a concept well enough to act on it. Instructions for use are learning materials. So are glossaries. Now I want the craft behind it: how people learn, how to design for it, how to evaluate whether it worked, and how AI can support that without replacing the thinking.

I call myself an EdTech professional in the making, and I mean the “in the making” part. I’m at the beginning of this, and I expect the learning path to change as I learn more. It’s a first draft, and first drafts exist so they can get better.

Confession: I’m a vibe coder

There’s something else I want to be open about. I’m not a software developer. This website, its editor, the glossary pages, the knowledge vault with its graph view, the questionnaires for user interviews — I built all of it by vibe coding. I describe what I want in plain language, work with AI tools to turn it into code, look at the result, and describe what should change. Then I do it again.

My training as a TV line producer helps more than I expected. You direct a team toward one output: a film or a magazine‑style format. It’s instructional design for video or audio. Vibe coding is instructional design for getting this website to do what I need it to do. And my DLI program trains me to use EdTech and AI to produce microlearning and learning paths. I’ve been doing instructional design for decades — I just didn’t call it that.

It’s not magic, and it isn’t effortless. I still have to know what I want and why. I have to notice when something is wrong. I have to ask the right follow‑up question: why does this page show a draft? Why does this link point nowhere? What happens to someone’s email address after 24 months? Every one of those questions taught me something about the web, about data, about accessibility or about privacy that I didn’t know before.

What surprised me most is how close this is to my actual profession. Vibe coding is, in large part, a documentation task. You write clear requirements. You describe structure. You name things consistently. You define what “done” looks like. The skills of a technical writer and an information architect transfer well to working with AI — which is also why I care so much about the AI learning path. If it works for me, maybe a version of it can work for others in my field too.

Show, don’t tell

Storytellers know the rule: show, don’t tell. I try to apply it to my work.

I could write that I care about structured content, semantic systems and accessible learning. Or I could put the glossaries online, link the terms, publish the learning path as a work in progress, and let you look for yourself. The second option feels more honest. It’s also more vulnerable, because anyone can see what isn’t finished yet.

But that’s the point. When work stays in a folder on my laptop, it can’t be tested by anyone but me. When it’s online, it becomes digitally tangible. You can click through it, notice a missing term, disagree with a definition, or tell me that a module is too basic or too advanced for your role. That kind of feedback is worth far more than private polishing.

It’s also why the site has a feedback page. You can leave anonymous quick feedback or sign up for a longer interview if you’re a technical writer, technical marketer, technical project manager or developer. The interview asks about the glossaries you use, the terms you find unclear, and what you’d want from an AI course. I read every answer and use them to decide what to build next.

Empowering others and myself

When I look at the glossaries, the vault, the learning path and the studies together, I see one thread.

I want to empower people — not in a grand way, but in the everyday sense: the technician who finds the right safety term, the technical writer who finally understands what “retrieval‑augmented generation” means for their documentation, the project manager who can hold their own in a conversation about the EU AI Act.

And I want to empower myself, too. Every glossary made me understand a field more deeply. Every page I vibe‑coded made me more confident with technology I used to think was out of reach. Every course module gives me a better vocabulary for something I’ve been doing intuitively for years.

It all starts with organizing information and making it useful. Everything else — the learning paths, the courses, the connections between fields — grows from there.

What’s next

Over the coming months, I’ll keep working on the learning path as I progress through my studies at the Digital Learning Institute. I’d like to test the first modules with real learners, refine the glossaries based on your feedback, and share what I learn along the way, including the parts that don’t work as planned.

If you’d like to help, here are a few simple ways:

1. Browse a glossary in your field and tell me which term is missing or unclear.
2. Look at the AI learning path and let me know whether the modules match your role.
3. Leave feedback or sign up for an interview on the feedback page.

Thank you.