Skip to documentation

Atlas

Ontology authoring

The ontology is the workspace's schema of meaning: the set of entity types (Person, Organization, Project, System, …) and relation types (works_at, owns, depends_on, …) that extraction is allowed to use. Authoring it is how you tune the graph to a domain — an M&A engagement and a platform-migration engagement want very different vocabularies — and how you keep extraction consistent instead of letting each document invent its own types.

Entity & relation types

Every workspace ships with a seeded default ontology (Person, Organization, Project, Topic, Concept) so the type enum is never empty on first run and the graph is useful before you touch anything. From there you can:

  • Add types for your domain — System, Vendor, Risk, Control — each with a short description the extractor reads as guidance.
  • Add descriptions and examples that guide the extraction prompt. Examples are guidance; they are not a separate type-alias registry.
  • Constrain relations with expected subject/object types, so a works_at edge is understood to run Person → Organization.
  • Rename or remove types. Rename relabels existing entities and relation constraints in one transaction. Removal is refused while in use unless you choose another existing type for reassignment.

How types normalize extraction

The ontology is not documentation — it is compiled into the extraction contract for every chunk. In the worker, each chunk is sent to the extraction model slot with a schema built from the current ontology, and the result is normalized back against it:

  1. Schema in, per chunk

    The entity/relation type enums become the allowed values in the extraction schema. Frontier models use native structured output (Output.object); OpenAI-compatible and local models fall back to schema-in-prompt with a JSON-repair round.
  2. Normalize to an allowed type

    Native structured output constrains values to the current enum. The fallback parser performs a case-insensitive allowed-name match and uses the configured fallback type when a model still returns an unknown label.
  3. Re-extract deliberately

    An ontology edit affects future extraction immediately. Use the explicit re-extract action to enqueue every live document when you want existing derived facts regenerated under the new vocabulary.

Current workflow boundary

There is no durable unknown-type proposal queue, type-alias table, soft-retirement state, or ontology-keyed extraction-result cache. The authoring UI exposes CRUD, constraint validation, templates, live usage counts, guarded reassignment, and explicit re-extraction.
A domain ontology (illustrative)text
entity types
  Person        a named individual
  Organization  company, firm, agency        aliases: company, org, firm
  System        an application or platform    aliases: app, service, tool
  Vendor        a third-party supplier

relation types
  works_at      Person → Organization
  depends_on    System → System
  owns          Organization → System

Related