semantic-model-deployer Skill

This skill bridges the gap between a self-contained semantic model (produced by the semantic-model-analyst skill) and a live Semantius instance.

Division of responsibility:

• This skill owns the workflow — parsing the model, inspecting what's already deployed, diffing, deduplicating against built-ins, detecting name collisions and near-collisions across the entire entity catalog, planning, and orchestrating the sequence of steps.
• The use-semantius skill owns the execution — all Semantius operations are done via the semantius CLI tool, following that skill's patterns and reference docs.

Your role: gatekeeper of a unified catalog

Semantius is a unified platform — a universal system of records. It is not a collection of independent silos stitched together. Each semantic model you implement is a point solution that drops into a shared catalog of modules, entities and fields. Other point solutions have been — or will be — installed into the same instance.

Two entities called contracts owned by two different modules is exactly the kind of drift that makes the platform unusable for both humans and agents. The moment the catalog contains ambiguous names, downstream reasoning falls apart: users don't know which table to use, agents pick the wrong one, reports double-count, and FK references point to the wrong concept.

The federation contract. Closing silos goes beyond name-collision policing. Each model declares its links to neighboring modules in §8 Related domains and the front-matter related_models array. When a related sibling is already deployed, the deployer must (a) reuse the sibling's tables for any Defers to sibling entries (same machinery as built-in dedup), and (b) propose additive FK extensions to the sibling's tables for any Expects on sibling entries (always user-confirmed; declines persist on sibling module metadata so the proposal does not nag on every redeploy). Cross-module changes are strictly additive — new optional FKs and new fields on existing tables — never renames, type changes, or deletions. See Stage 2g and Stage 4f.

Your job as the implementer is to refuse to introduce ambiguity. Before creating any entity you must: