One concept, many words: Inside the TextUnited Concepts editor

Most terminology projects die the same death. Someone opens a spreadsheet, starts adding every word that looks technical, and a year later there's a four-thousand-row file that nobody trusts, nobody maintains, and nobody opens during translation.

The failure isn't effort. It's orientation.

A termbase is not a vocabulary list. It's a map of the ideas your organization can't afford to name inconsistently, and then the labels you've agreed to attach to each of those ideas, in each language you publish in. That distinction sounds academic until you try to build one. Lead with words and you'll never notice that three of your entries are one idea with a naming problem. Lead with concepts and it's obvious on day one.

The TextUnited Concepts editor is built around that orientation. Not as a philosophy statement in the documentation, but in the shape of the data model itself.

What a concept looks like when it's finished

Start with a fully built entry, because it settles the argument faster than any amount of theory.

Concept #232322. AeroCord.

Note what that name is not. It isn't power cord. It isn't Netzkabel or kabel sieciowy, the three terms this concept actually carries, in English (US), Swiss German and Polish. The concept has its own identity and its own stable number, and none of its labels get to be the thing itself. That's the ISO principle of concept orientation implemented literally: the unit of knowledge exists independently of any word for it, including the English one.

It matters more than it sounds. In every termbase built around a "source term," English quietly becomes the concept, and every other language is demoted to a translation of a word rather than a name for an idea. Give the concept its own identity and Polish stops being downstream of English. It's just another label on the same thing.

Around that identity sits everything needed to make the idea unambiguous:

Domain, Electric & Electronics. Class, Object/component. Two different axes: where in the business this lives, and what kind of thing it is.

Definition, a US power cord typically uses the North American plug type according to the NEMA standard with a mains voltage of 120 volts. One definition, held once at concept level, naming the category and the features that separate this from its neighbours. Not repeated per language, not stranded on whichever term someone happened to open first.

Description, the practical guidance a definition shouldn't carry: pay attention to both ends of the cable, the wall plug and the device connector.

Note, produced at Ohio plant. Tag, deliverable. Operational facts that aren't part of the meaning but matter to the people using it.

An image, a photograph of the actual cable, NEMA plug at one end, device connector at the other.

That last field deserves its own paragraph, because terminology theory never thought to ask for it. Concept boundaries in industrial content are frequently physical, and a physical boundary is easier to show than to describe. You can write three careful definitions distinguishing a box, a unit and a switch box, and a translator may still hesitate; three photographs end the hesitation instantly. For enclosures, connectors, fittings and assemblies, the picture is often the most precise boundary marker available, and by far the fastest to consume at the moment someone actually needs it.

Then the terms themselves: power cord, Netzkabel, kabel sieciowy, each with a modification time, a named author and a status, all three currently Accepted, which turns out to mean something quite specific. More on that below. And above them, the piece that turns a collection of entries into a structure.

Relations: the concept doesn't live alone

Relations 1, PARTS, part of → fuente de alimentación.

AeroCord isn't a free-floating entry. It's recorded as part of another concept, and that other concept is a link you can follow. Relations are grouped by kind, added through + Add relation, and they connect concepts to concepts, never terms to terms, which is the distinction that keeps the model from collapsing back into a word list.

This is the step most termbases skip, and it's the one that changes what the termbase is. A flat set of well-defined entries is a reference. A set of entries that knows how it fits together is a knowledge structure, and it behaves differently:

It catches what definitions miss. Two concepts can each be perfectly well defined and still overlap, or leave a gap between them. You only see that when they sit in a structure next to each other. Partitive relations like part of are especially good at this: assemblies expose missing components, and missing components are the entries nobody thought to create.

It gives the confusable pairs somewhere to live. The most valuable relation in industrial terminology isn't hierarchical at all, it's don't confuse this with that. When a subject-matter expert finally settles the difference between three similar enclosures, they've produced two things: definitions, and a confusability cluster. Recording only the definitions throws away half the finding, and the half most likely to save someone at 4pm on a deadline.

It makes navigation follow meaning. Following part of from a cable to the power supply it belongs to is a different act from searching for a string and hoping. The graph is how you explore a domain you don't already know.

It disambiguates where strings can't. This termbase contains two separate concepts whose English label is power supply, one carrying Netzteil and fuente de alimentación, the other carrying Speisung. AeroCord is recorded as part of the first, specifically. A cross-reference pointing at the word "power supply" would be ambiguous between two ideas; a relation pointing at a concept is not. That's the difference between a link and a fact.

It supports inheritance and validation. Domain and Class can sensibly default down a hierarchy, which takes real work out of classification. And structure enables cheap error-detection: an object whose broader concept is a process is almost certainly a mistake, and that's the kind of thing a machine can flag without anyone writing a rule.

One design decision worth calling out: relations are typed, not generic "see also" links. A partitive relation and a hierarchical one mean different things, imply different cardinality, and support different reasoning. Typing them is what makes any of the four benefits above possible, and it's what lets the structure survive a TBX export intact rather than degrading into undifferentiated cross-references.

One word, many concepts

Now the case for why all of this is necessary. Search the termbase for power.

• English (UK), power, powerful, empowerment, sound power level
• English (US), extraction power, IEC power connector, power box, power connection, power cord, power input, power supply, power supply filter, power switch box, power unit
• German (Swiss), Absaugleistung, Kaltgerätestecker, Leistungsaufnahme, Netzfilter, Netzkabel, Netzteil, P-Box, Powerbox, Powerschaltbox, Schallleistungspegel, Speisung, Stromanschluss
• German (Germany), kraftvollen, Vertretungsbefugnis
• Danish styrke · Dutch voedingskast · Japanese 電源接続 · Odia aangoo · Polish kabel sieciowy · Spanish fuente de alimentación

One English string, and underneath it: an acoustic emission measurement (sound power level → Schallleistungspegel), a suction capacity (extraction power → Absaugleistung), electrical draw (power input → Leistungsaufnahme), a physical cable (Netzkabel, kabel sieciowy), the legal authority to represent someone (Vertretungsbefugnis), and abstract strength (power → styrke, aangoo). These are not translations of each other. They're unrelated ideas that collide in one word, and a word-oriented glossary would file them as neighbours and let a translator pick wrong.

Note too that IEC power connector maps to Kaltgerätestecker, which contains nothing resembling "power." Match on strings and you'd never pair them. Match on concepts and it's the only correct answer.

Select a concept and every one of its terms lights up simultaneously in the tree, in their respective language branches. The tree isn't a list of words grouped by language; it's the same set of concepts, rendered from each language's point of view.

Definition first, terms last

The clearest statement of what this tool believes is the order of fields in the Create New Concept dialog.

Definition comes first, "enter the core definition of this concept", alongside Domain, Class, Description, Note and Tags. Terms come last, at the bottom, added one row at a time with a language, the term text and a status. You are structurally asked to say what the idea is before you say what it's called.

That ordering is the whole discipline, enforced by layout. It's very hard to build a word list in a form that makes you define the concept before you can name it.

The filters are a duplicate check, not a lookup

The left panel looks like a browser. Used properly, it's a gate.

Language, Domain, Class, Status, Tags, Import, plus Creation date and Modification date ranges. That's useful for finding things. It's more useful as the uniqueness check that should precede every new entry: before a candidate concept gets created, someone searches for it across all languages and all statuses, because the duplicate you're about to add is very often already there under a label you didn't think of.

The date ranges are the governance tooling. "Everything created in the 2016 import." "Everything untouched since the last product generation." "Everything added since the ISO audit." A review cadence is only realistic if you can slice the termbase by age.

And the domain folders in the tree are where classification becomes visible. Electric & Electronics holds three concepts. No specific domain holds thirty-eight. That ratio is a work list, and it's the sort of thing that stays invisible until the structure makes it visible.

The Quick Concept Editor: where coverage becomes visible

The concept view is where you work on one idea properly. The Quick Concept Editor is where you see the termbase as a whole, a view that only makes sense if concepts are the underlying object.

Rows are concepts, eighteen of them here. Columns are languages, twelve in this account, with the grid scrolling horizontally when the set gets wide. Every cell either holds a term or shows + Add, and cells that already hold one show + Add as well, because a concept can legitimately carry several labels in the same language.

The first thing you notice is colour, because the status ladder is rendered in it. Blue for accepted, green for enforced, red for rejected, across the entire termbase at a glance. No opening of entries, no report.

What that colour reveals, in this account, is a lot of red and very little green. Two terms are enforced, sound power level and Schallleistungspegel, plus the Danish styrke. Everything else is either rejected or waiting. That's a whole vocabulary of enclosures, connectors and cables with no verdict attached, and since enforcement is what binds the translation engine, it means almost none of this terminology is currently constraining anything.

Look also at the row holding styrke. The Danish term is green; the English power and the Odia aangoo on the same row are red. Status is a property of a label in a language, not of the concept. A term can be enforced in Danish while the English label for the same idea has been rejected, which is exactly right, because the decision "is this the correct word here" is a per-language decision. The concept holds the meaning; each language decides its own labels.

Four more things fall out of the layout.

The finished concept is visibly different. Row one is AeroCord: Domain reading Electric & Electronics, three blue terms in English, Swiss German and Polish. Every other row shows , in the Domain column. One curated entry against seventeen unclassified ones, and you can see which is which from across the room. That's the work list.

Coverage gaps stop being invisible. "Which languages is this idea missing?" becomes a row you can read rather than a report you have to run. Swiss German covers most of the cluster; Japanese covers exactly one concept, 電源接続 for power connection; Danish, Dutch, Odia, Polish and Spanish have one apiece. Those aren't translation backlogs, they're decisions nobody has made yet, and every one will get made ad hoc by whoever next translates a manual under deadline.

Homographs separate cleanly. power supply appears on two different rows in English (US). One carries Netzteil and fuente de alimentación; the other carries Speisung. That isn't a duplicate, it's one English label covering two distinct ideas, the physical unit and the feed, correctly held as two concepts. A word list would have shown you two identical rows and left you guessing which was which.

Confusable neighbours line up next to each other. Look down the Swiss German column: power box → Powerbox, power unit → P-Box, power switch box → Powerschaltbox. Three near-identical labels for three supposedly different things, and power box also carries Dutch voedingskast, which is a cabinet, not a box. Nobody can tell from the labels whether these are three concepts with a boundary problem or one concept wearing three coats.

That cluster is exactly what definitions, images and relations exist for. Whatever the difference between a power box, a power unit and a power switch box turns out to be, it's a difference you can photograph, and once resolved, the fact that the three are neighbours worth checking against each other is something you record once rather than rediscover every time someone new opens the termbase. The grid doesn't resolve this. It makes it impossible to ignore, and tells you which three entries to open first.

Orphan concepts surface. One row holds Powerbank in German (Austria) and powerbank in Swedish; another holds powered and driven. Both English columns empty. Concepts without a source-language anchor are hard to govern, hard to search for and easy to duplicate, because the next person looking for that idea will search in English, find nothing, and create it again.

The Domain column, with a dropdown on every row, is where the unclassified bulk gets fixed: row checkboxes plus per-row dropdowns make classification a batch operation rather than seventeen round trips through the concept view. The same applies to bulk status changes and post-import cleanup. And inline + Add means the grid isn't read-only, when a reviewer working down a language column knows the equivalent, they add it where they're standing.

Getting terminology in, and out again

Almost nobody starts from zero. There's a spreadsheet a technical writer has been maintaining, a TBX from the LSP you're moving away from, a glossary a client sent as a condition of the contract. So the first real question about any termbase tool is what it accepts.

Import takes CSV, TBX and TBXM. TBX matters because it's the ISO exchange standard for terminology, it's how termbases move between systems without being flattened into two columns and a prayer. CSV matters because it's what your subject-matter experts actually have. The import runs as a stepped flow rather than a blind dump, so you see what you're committing before you commit it.

Two things are worth saying plainly about imports.

First, an import is where technical debt enters the termbase. Entries from 2016 with no definitions. Thirty-eight concepts with no domain assigned. Orphan concepts with no source-language anchor. That's what an inherited termbase looks like, and no import wizard fixes it for you. What the platform can do is make the debt visible and cheap to work through: the Import filter isolates exactly what arrived in a given batch, and the Quick Concept Editor lets you classify, restatus and fill it in bulk. Import, isolate, clean, approve, a realistic onboarding path, and a great deal better than importing 4,000 rows and hoping.

Second, an import is a proposal, not an endorsement. Everything that lands should land as a candidate.

Export is the part we'd rather you notice. Same formats going out as coming in, CSV or TBX, with filters for Domains and Languages, and an empty selection meaning "all."

This is a deliberate position, not a checkbox. Your terminology is your intellectual property. It encodes decisions your engineers, your legal team and your subject-matter experts made about how your products are named, and it's often the single most valuable linguistic asset a manufacturer owns. It should never be hostage to a vendor relationship. If you leave TextUnited tomorrow, you leave with a standards-compliant TBX containing everything you put in, and everything you built while you were here.

The filters make export useful day to day, not just on the way out:

• By language, hand a new Polish supplier the Polish column and its English source, and nothing else.
• By domain, send the regulated product line's terminology to the notified body without shipping your entire termbase.
• Preferred terms only, export a single agreed label per concept per language instead of every synonym, variant and rejected proposal. That's the shape a machine translation glossary needs, the shape a QA check needs, and the shape an authoring checker needs. Your full termbase records the debate; a preferred-terms export ships the verdict.

Inside TextUnited you don't need the export for this, the termbase is already wired into translation, and the API and MCP server put it in front of whatever else you're orchestrating. The export is for everywhere else: the agency you work with, the CMS vendor, the notified body, the system you might move to one day.

What a term entry carries

The concept carries the meaning. The term carries everything specific to one label in one language:

Language. EN-US and EN-UK are separate, and so are German (Germany), German (Austria) and German (Swiss). For industrial clients shipping into DACH, that granularity isn't pedantry, Netzkabel being recorded as the Swiss term is a fact worth keeping distinct from whatever Germany decides to use.

Status. Rejected, Accepted or Enforced, the field that decides whether the termbase is trustworthy, and the colour you see in the grid. More on it below.

Abbreviation. The short form that appears in UI strings, drawings and parts lists, recorded against the term it abbreviates rather than floating as its own mystery entry.

Notes. Scope and caveats specific to this label in this language, the concept's core definition lives one level up.

Sample. Real usage in context. A definition says what a concept is; a sample proves the term behaves the way you claimed. It's also a sharp test of distinctness: if the samples for two concepts are interchangeable, you don't have two concepts.

Tags. Cross-cutting classification the domain tree can't express: product line, regulatory scope, customer, review batch.

The audit trail. Author, created, modified, and separately, who approved it. AeroCord's terms show named authors and modification times measured in minutes, against a concept created in October 2016. An old entry, actively curated. That's what a maintained termbase looks like.

Status is the whole point

A term being present in the database is not the same as a term being cleared for use, and being cleared for use is not the same as being binding. The status ladder makes both distinctions explicit:

Rejected, considered and turned down. Visible, so nobody proposes it again next year.

Accepted, validated. A subject-matter expert has confirmed the concept is distinct, necessary and correctly defined, and this label is right for this language. Correct, usable, and still waiting.

Enforced, binding across the whole account. Every project, every user, every automated job.

That middle rung is doing more work than it looks. Most termbases have one gate, which forces a bad choice: either approval is cheap and the database fills with things nobody has verified, or approval is expensive and nothing ever gets approved. Two gates separate the two questions that were always separate anyway, is this correct? and should this be compulsory everywhere? The first is a linguistic and technical judgement, and it belongs to the person who knows the subject. The second is an organizational commitment with account-wide reach, and it belongs to whoever owns that.

Look at AeroCord in that light. Definition, class, image, relation, three languages, all three terms Accepted, a well-built concept, validated, and deliberately not yet imposed on every project in the account. That's not an unfinished entry. That's the ladder working.

Without status of some kind, a termbase rots back into a word dump: writers and translators start treating everything they find as binding, including half-formed proposals and entries a subject-matter expert killed years ago. With it, the pipeline can stay open and low-friction, because candidates are visibly candidates, and the Quick Concept Editor renders all three rungs in colour, so the state of the whole termbase is legible without opening a single entry.

It's also what makes preferred terms only a meaningful export rather than an arbitrary subset. A termbase that exports its whole contents regardless of status is telling you what it contains; one that exports the verdict is telling you what you've actually agreed.

Terminology has a shelf life, too. Products get renamed, meanings drift, a term that was right three product generations ago quietly goes stale. That's what the modification-date filter is for, and it's why the editor records when and by whom rather than just what.

Enforced means enforced

Here's the part that changes what the status field actually is.

In TextUnited, enforced terminology is enforced during automated translation. It isn't a reference the engine consults if it feels like it, and it isn't a report someone runs afterwards to count how often the wrong word slipped through. Once a term reaches Enforced, the machine is constrained to use it, on that job and every job after it, across the account.

The product doesn't hide this behind a euphemism. The top of the ladder isn't called "final" or "published" or "approved." It's called Enforced: a word that names its own consequence, so the person setting it knows they're changing what comes out of the pipeline rather than tidying a database.

Which means the top rung is not administrative metadata. It's a switch between recorded and in force, and promoting a term to it is a production action with immediate downstream effect. That's exactly why it sits above Accepted rather than beside it, and why it's a named, dated, separately recorded event.

It also explains why the concept model isn't an aesthetic preference. Enforcement is only safe if the match happens at the level of meaning.

Consider what a string-level glossary would do with the termbase above. Tell it to enforce Netzkabel wherever it sees "power," and it will cheerfully wreck the acoustics content, the extraction specifications and every general use of the word. The concepts under power demand different answers, Schallleistungspegel in one context, Leistungsaufnahme in another, Kaltgerätestecker in a third, and no substitution at all in a fourth. Only a concept-oriented termbase can carry that instruction, because only a concept-oriented termbase knows which idea is on the table. Word-oriented enforcement isn't merely weaker; at this level of ambiguity it's actively dangerous.

This is what the supervised model looks like in practice, and where terminology work pays for itself. A subject-matter expert makes a judgement once, this concept, this label, in this language, and that judgement then constrains machine output at volume, indefinitely, without them being in the room. The termbase is the mechanism by which human expertise scales past human throughput. Everything else in the Concepts editor exists to make sure the judgements being enforced are the right ones.

The terminology assistant

The assistant opens alongside the concept you're working on, and the detail that matters is the context card at the top: you are viewing, this concept, these languages.

It isn't a general chatbot bolted onto the page. It's scoped to your termbase and to the concept in front of you. It searches your concepts, checks translation coverage across your language set, suggests terminology, and flags where consistency is slipping.

Its starter actions map onto the parts of the work that are slow, mechanical, and therefore skipped:

Explain the concept. Everyone inherits a termbase eventually, entries created years ago by someone who left, with no definition and no note explaining the decision. A first-pass reading grounded in how the term is actually used across your content is a research accelerator, and post-import triage is where you'll reach for it most.

Suggest synonyms. The uniqueness test run in reverse. Ask for the plausible alternative labels for a concept, then search each one. Anything that comes back with an existing entry is a merge candidate, the fix for two labels pointing at one idea is a second term under the same concept, never a second concept.

Write a clear definition. Definitions are where termbases are won or lost, and people skip them because writing a good one is hard. A usable definition names the broader category the concept belongs to, then the feature that separates it from its siblings, a [broader thing] that [distinguishing feature]. No circularity, no "or" holding two concepts together in one sentence, scoped to how your industry uses the term rather than the fullest abstract sense. It drafts straight into the shape the concept-level definition field is asking for, which turns the human task from write a definition into the much faster check this definition.

Give usage examples. Drafts for the Sample field, drawn from your own content rather than invented.

What the assistant does not do is decide. It drafts, researches and surfaces gaps. A subject-matter expert still confirms the concept is distinct, necessary and correctly defined; a named owner still sets the status that binds the engine. That isn't a limitation we're apologising for, it's the same supervised model we apply across the platform. The machine handles volume and first drafts. The human holds the authority, and the audit trail is where that authority is recorded.

The same termbase, from outside the app

The Concepts functionality isn't confined to the terminology manager. It's exposed through the TextUnited MCP server, which means any MCP-capable assistant or agent can reach the same concepts, the same languages and the same statuses that the web app shows.

That matters because terminology questions rarely arise in the terminology tool. They arise while someone is drafting a manual, reviewing a supplier's copy, writing release notes, or building a pipeline at two in the morning. Making the termbase reachable from wherever that work happens removes the step people actually skip, switching applications to check.

In practice the obvious things become one question instead of a detour: is there an enforced term for this concept in Polish? Which languages is this idea missing? Does this phrase already exist under another label? What is this concept part of? And the termbase can participate in agentic workflows directly, a pipeline can check coverage before a job runs rather than discovering the gap in a QA report afterwards.

The governance boundary holds. Search, retrieve, compare, propose, yes. Deciding what the engine is bound by remains a human act with a name attached, for the reason the previous section gives. The MCP server widens who can ask the termbase questions. It doesn't widen who can change what it enforces.

Three doors, one termbase: the web app for curation, the API for integration, the MCP server for assistants and agents.

What this looks like as a workflow

1. Import or propose, bring in an existing CSV or TBX, or let anyone nominate a concept where confusion showed up. Either way it lands as a candidate, tagged to its import batch.
2. Research, search across all languages and statuses to confirm the concept doesn't already exist under another label. Use the assistant to gather usage and draft the definition.
3. Structure, assign domain and class, write the definition, attach an image if the boundary is physical, and record how the concept relates to its neighbours.
4. Accept, a subject-matter expert confirms the concept is distinct, necessary and correctly defined, and that this label is right for this language. The technical gate.
5. Enforce, the owner promotes it, and their name is recorded against it. This is the moment the term goes from correct to compulsory, account-wide.
6. Publish, enforced terminology binds automated translation from that point on, and reaches writers, partners and connected tools through the API, the MCP server, or a preferred-terms export.
7. Review, a scheduled pass. Filter by modification date to find what's ageing; open the Quick Concept Editor to find what's missing.

Start with the idea

The test of a termbase isn't how many rows it has. It's whether the right word comes out the other end, whether a translator working at 4pm against a deadline trusts what they find in it, and whether the engine running overnight is bound by it.

That trust comes from curation: a tight set of concepts that are genuinely unique, cleanly bounded against their neighbours, expensive to get wrong, settled enough to define, and recurring often enough to justify the upkeep. Everything else is noise, and noise is what makes people stop checking.

Concept #232322 is what the finished state looks like. It has a name of its own, a domain, a class, a definition, a photograph, a place in a structure, and three accepted labels in three languages, one promotion away from binding every job in the account. Nobody needs "computer" in the termbase. They need the concepts their industry argues about, built to that standard: defined once, agreed by the people who know, related to their neighbours, enforced automatically once someone decides they should be, and portable enough that they remain yours.

Start with the idea. The words follow, and once you've enforced them, they keep following.

The Concepts editor, Quick Concept Editor and Terminology Assistant are part of the TextUnited terminology manager. Concepts are available in the web app, through the TextUnited API, and through the TextUnited MCP server for use with MCP-capable assistants and agents. Terminology imports and exports support CSV and TBX.