In your control
The vocabulary is yours, and you can change your mind.
Plenty of systems let you name your categories once. This one gives them a version history, an impact preview before every change, an undo, and a warning when they go stale — because a vocabulary you cannot change safely is one you will stop maintaining.
In short
An ontology is just the nouns and verbs your content uses — the kinds of thing it talks about, and the ways they relate. Your team decides what that list is. Every change shows its impact before you make it, and nothing is ever deleted, so you can always undo it.
The problem
Every vocabulary decision is made too early.
You choose entity types before you have seen what your corpus contains, and then you are stuck with them — because changing them means re-extracting everything or destroying what you have.
The consequence is predictable: teams either freeze a vocabulary they have outgrown, or they never curate one at all and live with whatever the extractor invented. Both outcomes look the same from the outside — answers that quietly get worse as the corpus grows, and nobody able to say why.
The fix is not a better first guess. It is making the change cheap enough that being wrong initially does not matter.
Lifecycle
Live, fork, curate, preview, apply, revert.
Six states, and you can always get back to the previous one.
v1 is live, and never stops learning
Every newly discovered entity type and relationship predicate is registered into the live version as documents arrive. It is read-only to humans deliberately — it is not your curated vocabulary, it is the honest record of what your content contains.read-only · auto-evolving · always available
Fork a draft
A custom version starts as a copy of live and stays editable until you apply it. Nothing you do in the draft touches the graph, so there is no half-applied state to reason about and no reason to be cautious while exploring.one draft at a time, on purpose
Curate it
Five operations, described below. All of them are local to the draft.add · edit · merge · deprecate · remove
Preview the impact
Per term, how many entities and how many assertions would drop out of the active view if you applied this draft. The dialog is an impact report, not a confirmation prompt — you are told the cost before you pay it.entities and assertions, counted per term
Apply
An asynchronous sweep behind a lock recomputes conformance for every entity and every assertion in the workspace. Rows the new schema does not admit are marked out of schema and filtered from the active view.filtered, never deleted or retyped
Revert, or switch back to live
Because nothing was destroyed, going back is a matter of applying a different version and letting the sweep run again. The extractor never re-runs, so reverting costs time rather than money.the whole point of filtering rather than deleting
Draft operations
Six things you can do, none of which touch the graph.
Everything here is local to the draft until you apply it.
forward-looking
Add a term
Introduce an entity type or predicate you want the extractor to start looking for. Takes effect for documents ingested after the draft is applied.
keeps the old name as an alias
Edit a term
Rename it. The old name is kept as an alias rather than discarded, so the entities already extracted under the previous name still resolve.
no entity rewritten
Merge two terms
Fold one into another when you decide they were always the same thing. No entity is rewritten — the fold is recorded in the vocabulary, and conformance does the rest.
stops new extraction only
Deprecate a term
Stop offering it to the extractor without touching anything already extracted under it. The right move when a term was useful once and is now just noise.
reversible
Remove a term
The next apply filters its rows out of the active view. Reversible, because the rows are still there.
no consequences
Discard the draft
The exit. A draft you have decided against does not need to be applied to be gotten rid of.
Normalisation
What you type is not quite what is stored.
The editor shows you the canonical form as you type it, because conformance is an exact string match against the graph and a surprise here is expensive.
Entity types are lowercased and underscored. Predicates are additionally lemmatised, so tense and number stop mattering — which is what stops your vocabulary accumulating four spellings of one relationship.
entity types
"Record Label" → record_label
"Learning Objective" → learning_objective
"API" → api
predicates (also lemmatised)
"Was A Member Of" → member_of
"reduces" → reduce
"Is Prerequisite For" → prerequisite_forDrift
The feature that tells you your vocabulary has gone stale.
Your frozen version stopped learning. The live version did not. Drift is the difference — and it is the reason curating is safe rather than a one-way door.
Without it, curating a vocabulary is an act of faith: you freeze something reasonable and find out eighteen months later that half your content is being typed into terms you deprecated. With it, the staleness is a number on a page, and folding the new discoveries in is a new draft rather than an archaeology project.
FAQ
Frequently asked
Mostly about the constraints, which are the interesting part.
Curate a vocabulary without betting the corpus on it.
The graph tier includes the full ontology workbench: drafts, impact previews, reversible applies and drift.
- no card required
- first workspace is free
- one POST to ingest