CLUE Builds an Event Ontology Without Experts in Three Steps: Embeddings, Clusters, Names

Preprint arXiv:2610.12580, published on 12 October 2026 in the cs.CL category, describes CLUE, a framework that takes over three tasks that normally fall to experts: identifying event types in a dataset, naming them, and annotating examples. It rests on three technical decisions: a joint embedding representation of the event, clustering with a contrastive loss, and a separate stage for naming and refining types. The authors claim that experiments confirm the method's effectiveness, and they have released the code.

What problem does CLUE solve?

An event ontology defines which events in the data count as distinct types: "company merger," "lawsuit," "cyberattack," "leadership change." Without one, event extraction, knowledge graph construction, and news stream monitoring do not work.

The process today looks like this. Domain experts write an annotation guide and invent the types and their names, and then annotators apply the schema to the data. This is expensive. It is slow. And the result depends on the views of the specific people involved: a different team of experts will produce a different schema. For a new domain, say medical reports or incident logs, everything has to start over.

How the method works

CLUE is split into three parts, each responsible for its own stage.

• Joint embedding. An event is described in two ways: through its trigger verb (what exactly is happening) and through the semantics of the whole context. These two views are merged into a single vector representation.
• Type induction. The vectors are clustered, and training is guided by a contrastive loss: similar events are pulled toward each other, and different ones are pushed apart. The clusters become candidate types.
• Naming and refinement. Each cluster receives a name, after which the types are adjusted. The abstract does not say how the names are chosen.

The logic of the combination is clear. A single verb often hides different events: "closed" can refer to a deal, a store, or a vulnerability. Semantics alone, without the anchor of a verb, tends to blur the boundaries. Combining the two kinds of signal should produce cleaner clusters than either one on its own. This is our interpretation, not a result stated in the abstract.

What is known about the work

• Preprint: arXiv:2610.12580v1, category cs.CL, version 1
• Task: event type induction, naming, and annotation without a manual ontology
• Representation: joint embedding of the verbal and semantic views of an event
• Training: clustering guided by a contrastive loss
• Output: type names and their refinement
• Code: the PratikMaitra/CLUE repository on GitHub
• Not disclosed in the abstract: datasets, baselines, numerical metrics

The last point matters. The phrase "experiments demonstrate effectiveness," without numbers, remains a claim for now. Before judging any improvement, you need to look at the tables in the paper itself: what the method was compared against, on which corpora, and by which clustering and name-quality metrics.

Who will find this useful in practice

The most obvious scenario is teams that launch event extraction in a new domain and do not want to spend months agreeing on a schema with experts. Legal documents, financial reports, news in a narrow industry, support tickets: wherever event types are unknown in advance, an automatic draft of the ontology saves time.

A sensible course of action is as follows. Take a small sample of your own data and run it through the repository. Review the resulting clusters by hand: how homogeneous they are, and whether the names match how a person would name the event. Compare the result with an existing expert schema, if there is one. And use CLUE as a generator of the first version of the ontology, which an expert then edits in hours, not as a replacement for expertise. The method reduces expert bias but does not remove it: the bias moves into the choice of data and the clustering hyperparameters.

If the full experiments turn out to be convincing, the approach will become a convenient way to get started quickly with event annotation where no ready-made schemas exist.