Concept governance

A knowledge graph an LLM helped build contains facts of very different reliability: a model's guess from one paragraph, a human's deliberate assertion, a steward-reviewed definition, an owner-certified term of record. eli.ai makes that difference explicit and machine-readable: every concept carries an authority tier, a lifecycle status, an owner/steward assignment, a full revision history with PROV-O provenance, and a review clock. None of it is invented here — each mechanism maps to an established practice from enterprise catalogs (Atlan, OpenMetadata, Glean), thesaurus standards (SKOS, ISO 25964, ADMS), and the operational history of Wikidata.

The four authority tiers

Authority answers one question: how much human vetting stands behind this concept? It is a strictly ordered ladder (machine_extracted < asserted < curated < certified), stored on entities and relations alike:

• machine_extracted — a model proposed it during ingestion. The default for everything extraction writes; zero human review implied.
• asserted — a human deliberately created it (manual entity or relation via UI or API). One person vouches for it, but nobody has reviewed it.
• curated — a steward reviewed or edited it, or it landed through an approved change request. Marking a machine-extracted concept as reviewed promotes it here automatically.
• certified — an owner or admin signed off. This is the only tier an assistant may state without hedging; everything below it is qualified when answers lean on it.

Lifecycle

Orthogonal to authority, lifecycle answers: should this concept be served at all? The states and transitions are a small, fixed map — deliberately a few lines of TypeScript, not a workflow engine:

• Live by default. New concepts land published unless explicitly created as draft. Knowledge should flow; gating is reserved for the operations that need it (next section).
• Hidden while working. draft and pending_review concepts never appear in retrieval, served entity cards, graph overviews, manifest hub lists, or autocomplete.
• Deprecated ≠ deleted. deprecated and superseded concepts stay retrievable — an assistant can still explain the old policy — but they are demoted and always labeled, and a superseded concept links to its successor. A successor must itself be a live, published entity, and a concept can never supersede itself.
• Terminal until retirement. Once deprecated or superseded, a concept does not return to published; the exit is retirement (soft delete), which removes it from serving entirely.

Two-track gating

Should every change to the graph require approval? Wikidata's operational history says no — bots and extraction pipelines write millions of statements live, at low rank, and the community promotes or deprecates after the fact. Requiring pre-approval for instance-level facts would have killed the project. eli.ai adopts the same two-track split:

• Track A — gated. Schema-level and destructive operations (proposing a new governed concept, rewriting a definition, deprecating, superseding, deleting) go through change requests: proposed, reviewed by the concept's owner or stewards, then applied atomically with full provenance.
• Track B — live by default. Instance-level extraction writes immediately at machine_extracted. Nothing blocks ingestion; the authority tier itself is the quarantine. Post-hoc review promotes — marking a concept reviewed lifts it to curated.

Relations carry the same idea at statement granularity: an assertion rank (deprecated / normal / preferred) modeled directly on Wikidata statement ranks, so conflicting edges can coexist with one marked preferred instead of fighting over a single truth slot.

Standards mapping

Every governance mechanism maps to a named practice, so the model survives scrutiny in enterprise settings and exports cleanly to standard vocabularies:

Provenance: PROV-O & SKOS

Every mutation — create, update, review, certify, authority change, owner change, deprecate, supersede, delete, change-request application, verification — appends an immutable row to entity_revisions: a version number, a full snapshot, a field-level diff (in the style of OpenMetadata's changeDescription), and provenance columns that carry a PROV-O "starting point" subset as column semantics:

• prov:wasAttributedTo → changed_by — who made the change.
• prov:wasRevisionOf→ version − 1 — each revision points at its predecessor through the version sequence.
• prov:generatedAtTime → created_at.
• prov:wasGeneratedBy → activity — the mechanism: ui, api, mcp, extraction:<runId>, or change_request:<id>.

The same standards alignment powers the export surface: GET /api/v1/export/skos emits published and deprecated concepts as SKOS/PROV-O JSON-LD — skos:Concept with prefLabel, aliases as altLabel, graph edges as broader/related, lifecycle as adms:status, attribution and modification timestamps intact. Your ontology is never locked in.

Review SLAs

Certification decays: a term of record certified in January may be wrong by July. Following Glean's verification model and Atlan's freshness ladder, every review or certification stamps last_reviewed_at and schedules next_review_at at now + reviewIntervalDays (a workspace setting, default 180 days — the same interval stamps next_verify_at on verified documents). From there the ladder runs automatically:

• Flagged — a published concept whose next_review_at has passed appears in the stale-concepts queue, most overdue first, on the Curation page.
• Alerted — the existing drift scan fires a deduplicated curation.review_overdue alert while any review is overdue, and resolves it when the queue clears. See Scheduling, drift & alerts.
• Cleared — marking the concept reviewed (or re-certifying it) restamps the clock; a review of a machine-extracted concept simultaneously promotes it to curated.