Catalog

Catalog is the Consensus workspace for viewing and managing the whole semantic layer, along with its connected schema entities. It's where curators browse every table, column, metric, business term, verified query, and relationship Consensus has modeled, inspect how they connect, and govern how they change - with a full version history behind every edit.

You've followed the semantic layer from idea (Consensus) to construction (Semantic Pipelines). This final chapter is the human's seat at the table - where a curator reviews what the pipelines proposed, corrects it, and approves it.

What it is

Consensus builds and maintains the semantic graph from your sources, but every enterprise still needs a place for a human to look at the whole graph, correct a definition, and see exactly who changed what and why. Catalog is that place. Open it from Consensus → Catalog. From one workspace, curators can:

• browse all supported entity groups from one place, in a grid or table view
• search by text and filter by datasource, schema, table, column, deleted status, and modified window (the filters offered depend on the entity type)
• inspect details in a right-side panel
• create, edit, or delete supported entity types
• navigate cross-entity references
• inspect historical versions and lineage traces

Entity families

Catalog covers every curated node type in the semantic graph, grouped into two families.

Schema and data entities anchor the graph to your actual warehouse structure. Semantic model entities are the curator-governed meaning layer described in Consensus - the same assets your AI agents and analysts reason over before any query is generated. Verified Queries are managed here too: pick Verified Query in the type list.

Capability matrix

Current UI/API behavior, by entity type:

A Semantic Dataset is created from the SQL Editor; choosing Create for that type in Catalog points you there. ACTION and CATEGORY can be created but not updated or deleted. Delete always requires explicit confirmation, and after a delete Catalog sends you to Needs Attention to review any dependents the delete affected.

Version history & lineage traces

The detail drawer for any entity has an Overview and a Version History mode; columns also get a Profile tab with their statistical profile. Version History is Catalog's governance backbone - it's what turns a semantic graph edit from an invisible mutation into an accountable, replayable change:

• see each entity version (vN) with a timestamp and actor metadata
• view change reason labels - manual edit, AI agent rewrite, automatic update, conflict resolution, system migration, datasource purge, or document processing
• expand a historical version to inspect that exact snapshot
• follow connected changes through version change connectors and related entities, including the metrics, business terms, tables, verified queries, and cached SQL resolutions a change touched

This is the same versioned, attributed, timestamped audit trail described in Consensus governance & explainability - Catalog is where you read it and act on it.

Governance & change controls

Entity-level controls enforce safe operations rather than relying on convention:

• TABLE and COLUMN are browsable and editable for metadata context, but not creatable or deletable from Catalog - they stay aligned with the source schema.
• ACTION and CATEGORY can be created but not updated or deleted.
• Create, update, and delete need the admin or curator role. Any signed-in user can browse.
• Delete is available only for supported types and always follows explicit confirmation.
• An edit never overwrites the previous version: it creates a new one.

What curators can change

Primary curator-managed entities:

• METRIC, VERIFIED_QUERY, BUSINESS_TERM, BUSINESS_ENTITY, EVENT, RELATIONSHIP, DATASET
• ACTION and CATEGORY (create only)
• TABLE_RELATIONSHIP and CATEGORY_SET
• descriptive metadata on TABLE and COLUMN

Recommended governance workflow

1. Scope the entity type

   Choose an entity type and narrow scope with datasource and hierarchy filters.

2. Inspect current state

   Review the current definition and linked references in Overview.

3. Apply intentional changes

   Create or edit with a clear, deliberate change - not a bulk sweep.

4. Validate downstream impact

   Navigate references to see which metrics, verified queries, and other assets depend on the entity before confirming.

5. Confirm the trace

   Check the new snapshot and change-reason label in Version History.

6. Reuse the snapshot

   Use lineage snapshots during review, regression checks, and incident analysis.

Ownership guidance by entity class

• TABLE and COLUMN - source-aligned structural metadata. Treat them as contextual anchors for semantic curation, not editable business definitions.
• TABLE_RELATIONSHIP and CATEGORY_SET - many are proposed by the knowledge pipelines. Curators can correct them here; to change them in bulk, adjust and re-run the upstream pipelines rather than editing by hand.
• Semantic entities (METRIC, VERIFIED_QUERY, BUSINESS_TERM, BUSINESS_ENTITY, EVENT, ACTION, CATEGORY, RELATIONSHIP, DATASET) - the curator-governed semantic intent layer. Keep labels, descriptions, synonyms, and references coherent so downstream discovery and agent reasoning quality remain stable.

Where it fits

Catalog governs the same graph every other Colrows surface compiles against - it doesn't sit off to the side:

• Consensus autonomously proposes and maintains the graph; Catalog is where a human reviews, corrects, and approves it.
• Data access control policies apply to the same entities curators manage here - editing a BUSINESS_TERM doesn't bypass RBAC/ABAC on the underlying tables and columns.
• The askMetadata MCP tool lets AI agents query the exact entities and definitions curated in Catalog - what a curator names and defines here is what an agent sees. Agents on the agent interface can search the same entities with searchSemanticEntities and read their current definitions in one batch with getSemanticEntities.
• AI Data Analyst grounds every answer in these same governed definitions, so a correction made in Catalog is reflected in future answers. Cached SQL that depended on a changed asset is marked stale and no longer reused.