AutoGineer
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
Download ZIP

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://mp-staging.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/publication.md

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

Governed publication, readback, and rollback

Use this workflow to apply a reviewed semantic model or make validated analytical results reusable. Publication is a durable governed write followed by exact readback. A chat response, chart, local receipt, or successful request is not publication.

MCP is read-only and cannot publish. Use only an approved REST or source writer with the caller's own permissions. Publication may expose a recommendation; it must not imply approval, commitment, or execution without a separate authorized event.

Choose an honest publication mode

  • Receipt only: retain validated artifacts locally when no approved writer exists. Report explicitly that nothing was published.

  • Native semantic model: use scoped Auto Ontology model export/import for Terms, attributes, represented tables, and semantic relationships.

  • Reusable definition: use a validated CustomAnalysis for supported SQL or a PqlAnalysis for supported PQL. These store definitions, not arbitrary result rows.

  • Governed result table: write immutable, keyed result partitions to an approved source table outside Auto Ontology, then ingest and model that table for reuse. Auto Ontology does not provide a generic MCP or REST endpoint for arbitrary result-row writeback.

Do not use conversation persistence as a result store. If none of the modes can meet the requested durability, identity, or permission requirements, stop at a receipt.

Pre-publication contract

Bind and validate:

  • source, catalog, and semantic model identity;

  • exact physical and semantic IDs and approved joins;

  • run, result, entity, scenario, and parent identities;

  • population, measure definition, unit, grain, and time basis;

  • producer/model/solver and input/definition/result hashes;

  • evidence class, uncertainty, validity, status, and supersession;

  • writer identity, authorized scope, destination, and rollback target.

Keep observed, computed, structural, modeled, predicted, recommended, and committed evidence distinct. Store run totals at run grain and complete scenario memberships when downstream joins require the full set.

Native semantic changes

  1. Export the exact database-ID scope and retain the original YAML plus SHA-256 as the rollback artifact.

  2. Preserve live physical IDs; generated IDs are not natural-name upserts.

  3. Validate the proposed diff and affected queries.

  4. Apply first in an isolated environment through the public API.

  5. Re-export the same scope and compare exact IDs, structure, properties, relationships, and counts.

  6. Run positive and negative readiness, answerability, SQL, row, and answer probes.

  7. Promote only the reviewed artifact; on mismatch, quarantine it and restore and verify the prior state where supported.

Fail closed around known product limitations:

  • issue #250: replacement may retain an omitted semantic FK;

  • issue #265: replacement may retain existing properties instead of updating them;

  • issue #267: a different physical ID with the same natural database name may surface as HTTP 500.

Do not bypass these failures with direct Postgres edits. A success: true response and payload-oriented summary counts do not prove persisted parity.

Governed analytical results

For a governed result table, use stable (run_id, result_id) and business entity keys, append-only run partitions or transactional staging, explicit units and grain, source/parent lineage, status, validity, and supersession. Verify row count, key uniqueness, hashes, and full-precision values before ingestion.

After ingestion, map results back to the original business entity with compatible typed keys. Compile the semantic layer and prove fresh readback from the published destination. Test invalid, stale, superseded, unknown-run, and ambiguous-measure cases; they must not silently fall back to the latest row.

Required receipt

Retain the requested scope, semantic input identity, writer class, permission result, destination or definition ID, payload/artifact hash, exact before/after diff, row/key/hash verification, compilation identity, post-write SQL and rows, and rollback target. Never retain tokens, passwords, or connection strings.

Current Auto Ontology certification fields are not an atomic review/promotion system. Until that product lifecycle exists, describe the reviewed state accurately and do not claim atomic certification, promotion, supersession, or rollback.

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.

Download ZIP

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