Generated banner for Nvidia Ontology Management
Generated logo for Nvidia Ontology Management

Nvidia Ontology Management

NVIDIAOfficialCreated by NVIDIA

  • Skill
  • Workflow
  • Data and AI
  • Apache-2.0
  • Medium risk

From the author

Model and publish semantic definitions in Auto Ontology. Use for terms, relationships, measures, imports, and governed results—not deployment or querying.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for modeling, inspecting, and publishing semantic definitions in Auto Ontology. It emphasizes maintaining a rigorous semantic layer by separating routine metadata edits from complex modeling tasks and governed publication. The skill guides users through discovering current meanings, defining concepts and relationships, validating SQL attributes, and performing controlled model imports or exports. It is designed for environments where semantic accuracy and durable, governed changes are critical, ensuring that all modifications are backed by evidence and verified through exact readback procedures.

What it does

  • Inspects and edits semantic metadata like terms, relationships, and measures.
  • Validates SQL attributes and semantic definitions before application.
  • Manages bulk model imports and exports for catalog and semantic layer updates.
  • Enforces publication gates to ensure changes are durable and verified.
  • Provides workflows for modeling concepts, relationships, and reusable measures.
  • Facilitates verification of persisted changes through exact readback and comparison.

When to use it

  • When you need to define or update business concepts, relationships, or measures in Auto Ontology.
  • When performing bulk updates to the semantic model via import/export.
  • When you need to ensure a semantic change is governed, validated, and durable.
  • When troubleshooting semantic model inconsistencies or validation failures.

Advantages

  • Ensures semantic consistency through rigorous modeling and validation workflows.
  • Provides a clear path for governed publication and rollback of semantic models.
  • Reduces risk by requiring verification of persisted changes rather than relying on API success.
  • Supports complex semantic structures like derived SQL attributes and relationship paths.

Usage examples

“Define a new run-grain measure for revenue in Auto Ontology.”
The agent will guide you through the modeling.md workflow, requiring you to define the expression, grain, units, and additive dimensions before applying the change.
“Promote a revised semantic model to production.”
The agent will initiate the publication.md workflow, including backing up the current state, applying the change in isolation, and performing an exact readback comparison.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/nvidia-ontology-management/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nvidia-ontology-management.zip -d .agents/skills

Documentation by NVIDIA

<!-- SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. SPDX-License-Identifier: Apache-2.0 -->

Auto Ontology management and modeling

Purpose

Inspect and change Auto Ontology's semantic layer without confusing a successful API call with correct business meaning or durable publication. The machine-readable inputs, outputs, statuses, gates, and handoffs are in runtime-contract.yaml.

Choose the focused workflow before acting:

  • routine inspection or metadata edits: continue below and use write-api.md;

  • concepts, relationships, measures, units, grain, or policies: use modeling.md;

  • model promotion or reusable analytical results: use publication.md.

MCP tools only read. Create, patch, import, and compile-reset go through the Next.js /api/... gateway. Governed result rows require an approved source writer; Auto Ontology has no generic result-row writeback endpoint. Request bodies and field types live in docs/openapi/auto-ontology-api.json; this skill names operations and permissions only.

Prerequisites

Use a running, authenticated Auto Ontology deployment. Use nvidia-ontology-setup when the deployment or semantic layer is not ready.

Limitations

MCP is read-only, Auto Ontology has no generic result-row writeback endpoint, and current model import and certification APIs do not prove atomic promotion. Follow the publication gates below and fail closed when exact readback is unavailable.

Auth

Scripts use an API token (x-api-key or Authorization: Bearer). Mint it in the UI (user menu → API Tokens). A token acts as its owner — a viewer's token cannot do admin things. Creating and revoking tokens requires a signed-in session; a token cannot mint another token.

Writes below need catalog:edit unless noted. 403 means the owner's role lacks that permission, not that the path is wrong.

Instructions

  1. Discover current meaning via MCP (search_terms, get_term, get_term_columns, get_term_sql_attributes, describe_table) or REST if MCP is absent (GET /api/terms, GET /api/terms/{term_id}, GET /api/exploration/tables/{table_id}/details).

  2. Resolve the semantic contract when meaning changes. Record source binding, identity, population, relationship cardinality, measure expression, unit, grain, denominator, time, validity, and counterexamples; see modeling.md.

  3. State the proposed change to the user (term rename, new SQL attribute, import, and so on). Do not silently rewrite the glossary.

  4. Validate SQL before create/update: POST /api/sql-attributes/validate. A parse failure is HTTP 422, not valid: false.

  5. Apply the smallest write that matches the request (see write-api.md).

  6. Compilation is not a hidden side effect. Check GET /api/semantic-compilation/status. Do not call POST /api/semantic-compilation/reset as cleanup — it is an asynchronous, destructive rebuild of every database's compiled layer, returns 202, and requires semanticCompilation:manage.

  7. Verify the persisted change, not merely request success. Model imports require a scoped backup and exact re-export comparison; see publication.md. Then use MCP check_answerable / ask_question (or REST POST /api/question-entity-coverage and POST /api/chat/completions) for positive and negative behavior checks.

Semantic relationships and "what does this dataset mean"

Stay on the semantic layer. Do not browse raw schemas to answer meaning.

  • Term → columns: MCP get_term_columns or GET /api/terms/{term_id}/column-attributes

  • Term → derived SQL: MCP get_term_sql_attributes

  • Table → terms and SQL attributes: MCP describe_table or GET /api/exploration/tables/{table_id}/details

  • Semantic hop chain between two terms: GET /api/exploration/terms/{term_id}/path/{other_term_id}

  • Semantic graphs: GET /api/exploration/graph, GET /api/exploration/semantic-graph

These are semantic relationship paths, not generation provenance, source revision, certification history, or version lineage.

Bulk import / export

  • POST /api/model/export — YAML of catalog + semantic layer. Permission modelInterchange:export. Body may set catalog database IDs in databases (empty = all) and format (auto_ontology or ossie).

  • POST /api/model/import — multipart YAML; native Auto Ontology (data_layer / semantic_layer) or Apache Ossie (version, name, datasets at the root). Query replace (default true) and embed (default true). Permission modelInterchange:import. Can replace existing data — confirm with the user before replace=true, apply first in isolation, and use the exact readback workflow in publication.md.

Examples

  • To define a run-grain measure, follow the evidence and counterexample workflow in modeling.md.

  • To revise and promote a model, back up the exact scope and follow the staged readback workflow in publication.md.

Troubleshooting

For write failures, verify the authenticated owner's permission, distinguish HTTP 422 parse failures from validation results, and inspect compilation status before changing the model or resetting compilation.

See also

  • write-api.md

  • modeling.md

  • publication.md

  • nvidia-ontology-query — how to call Auto Ontology and validate query results

  • nvidia-ontology-setup — deployment not ready

  • mcp/auto_ontology_mcp/tools.py — live read-tool allow-list

Files

references/modeling.md

<!-- SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. SPDX-License-Identifier: Apache-2.0 -->

Source-grounded ontology modeling

Use this workflow when a request changes business meaning rather than only correcting copy. Routine API mechanics remain in write-api.md. Publication, promotion, and rollback belong to publication.md.

Start with the question contract

Before proposing an edit, record representative business questions and the required population, measure, grouping, time range, comparison, and exclusions. Use the exported physical catalog and approved source evidence for schemas, types, keys, nullability, time columns, and relationships. Names and small value samples are supporting evidence, not proof of identity or cardinality.

Define each concept by business identity and population. Similar names or equal current row sets do not make two concepts equivalent. Every attribute needs an exact physical source or an explicit derivation. Preserve physical and semantic IDs when editing an existing model; generated UUIDs are not natural-name upserts.

Relationship contract

For every relationship record:

  • source and target concepts and columns;

  • direction and business role;

  • expected one-to-one, one-to-many, or many-to-many multiplicity;

  • key/null behavior and observed join coverage;

  • approved query direction and known fanout risk;

  • validity, version, and source evidence.

A matching column name is not proof of a join. Test duplicate and null keys, reverse joins, missing mappings, and cardinality violations. A semantic relationship is not automatically a prediction edge, graph edge, or solver coefficient.

Measure contract

For every reusable measure record:

  • expression and source evidence;

  • row grain and permitted query/grouping grain;

  • physical unit, separately from time grain;

  • additive dimensions and forbidden reaggregation;

  • numerator, denominator, weights, and population filters;

  • null, empty-population, and zero-denominator behavior;

  • effective time, availability time, revision, validity, and supersession.

A quantity, fraction, period average, rate, and horizon total are different measures. Ratio-of-totals is not generally mean-of-ratios. A run-level total must not be summed after a one-to-many detail join.

Policies need authority, applicability, constrained fields, permitted changes, and required identities. Descriptive text is not executable procedure or permission to act.

Map the design to supported Auto Ontology operations

Use the smallest supported change:

  • patch an existing Term or ColumnAttribute for metadata corrections;

  • validate and create/update a SQL attribute for a reusable derivation;

  • use scoped native model export/import for concept population or relationship changes.

Auto Ontology has no direct public create-empty-Term endpoint and no complete direct structural relationship mutation workflow. Do not invent one. If the requested design cannot be expressed through the installed revision's public API, return a model gap instead of weakening the design.

Validate before handoff

Test source-backed examples and counterexamples for duplicate/null keys, fanout, reverse joins, missing mappings, stale versions, ambiguous periods, unit confusion, and intended empty populations. Verify that each scoped question is answerable without changing its material meaning.

Deliver:

  • a versioned semantic specification;

  • exact source and ID mappings;

  • relationship and measure contracts;

  • approved join paths;

  • positive and negative tests;

  • unresolved model or product gaps.

A successful SQL execution, import response, or non-empty answer does not certify semantic correctness. Hand the reviewed specification to the publication workflow for backup, staged application, exact readback, and rollback handling.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/nvidia-ontology-management · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nvidia-ontology-management.zip