The five-part series argued that a Knowledge Spine — the operationalization of an enterprise ontology — is how you give data, people, and AI agents one governed place to resolve meaning. It ran from the definition through the build, keeping it alive, funding it, and handing it to agents. This bonus instalment is for the team that read it and said: fine, we start Monday. What exactly do we do?

What follows is the field manual I wish every first vertebra team had. Examples use a supplier risk scenario and Stardog-flavored syntax, but every step translates to any capable semantic platform.

Ninety days, three phases, nine steps. The only hard gate is at day 90: if nothing has moved into the shared core, you have two applications rather than a spine.

Step 0: Pick the Question (Half a Day, Not Half a Quarter)

Everything downstream inherits its shape from the first question. Score candidates against five criteria:

It crosses at least two silos. If one system can answer it, you do not need a spine yet. “Which suppliers put our Q4 launches at risk” touches procurement, product, and contracts. That is the point.

It has a named owner in pain. Someone assembles this answer manually today, hates it, and will vouch for the fix. That person is your first believer and your acceptance test.

It recurs. A question asked monthly compounds value; a one-time analysis does not justify infrastructure.

The data exists. You are connecting sources, not launching a data quality program. If the underlying data is missing, pick another question.

It matters to a sponsor. Attached to revenue, risk, or cost that leadership already tracks.

Write the question down verbatim, with the owner’s name next to it. This sentence is your scope contract: no class enters the ontology unless the question needs it.

Step 1: Draft the Ontology (Week 1)

Gather the inputs an LLM can work from: existing glossaries, warehouse schemas, API documentation, a transcript of the SME explaining how they answer the question today. Then have the LLM draft a candidate model and let the SMEs cut it down. Review is faster than authorship; that asymmetry is what makes week one possible.

Target 15 to 30 classes. For supplier risk, the core might be:

@prefix :    <https://ontology.acme.com/core#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:Supplier   a owl:Class .
:Component  a owl:Class .
:Product    a owl:Class .
:Launch     a owl:Class .
:RiskEvent  a owl:Class .

:supplies      a owl:ObjectProperty ; rdfs:domain :Supplier  ; rdfs:range :Component .
:usedIn        a owl:ObjectProperty ; rdfs:domain :Component ; rdfs:range :Product .
:scheduledFor  a owl:ObjectProperty ; rdfs:domain :Product   ; rdfs:range :Launch .
:affects       a owl:ObjectProperty ; rdfs:domain :RiskEvent ; rdfs:range :Supplier .

Three disciplines from day one:

Definitions are part of the model. Every class gets an rdfs:comment written in business language and approved by the SME. The definition is the deliverable; the class is just its address.

Constraints ship with concepts. A SHACL shape per class, so validation exists before the first mapping does:

@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

:SupplierShape a sh:NodeShape ;
  sh:targetClass :Supplier ;
  sh:property [ sh:path :supplierId ; sh:minCount 1 ; sh:datatype xsd:string ] ;
  sh:property [ sh:path :supplies   ; sh:minCount 1 ; sh:class    :Component ] .

IRIs are forever. Decide your identifier scheme now — a stable namespace you control, opaque or readable, but never derived from org structure, because org structure changes. Renaming IRIs later is the semantic equivalent of changing primary keys in production.

Step 2: Instantiate (Week 2, First Half)

Stand up the semantic platform and load the ontology. Selection criteria that actually matter, in order: virtualization capability against your lakehouse, SHACL validation, reasoning support, SPARQL plus a BI/SQL endpoint, API surface for agents, and operational fit (security integration, deployment model). Feature checklists beyond these six rows are procurement theater.

Create three environments from the start: dev, staging, production. The ontology is code now; it gets an environment pipeline like code.

Step 3: Map Sources Virtually (Week 2, Second Half)

Connect one or two sources that carry the question’s data. Virtual first: the data stays in the lakehouse, and a mapping declares how rows become instances. Conceptually:

FROM lakehouse table procurement.suppliers
MAP  row              TO :Supplier iri("supplier:{supplier_id}")
MAP  supplier_id      TO :supplierId
MAP  component_fk     TO :supplies iri("component:{component_id}")

A query against :Supplier now compiles to SQL pushed down to the source at runtime. No copies, no drift, and source-side governance still applies.

When to materialize instead: entities extracted from documents, data needing heavy reasoning, and hot paths where federated latency hurts. The default is virtual; materialization is the documented exception with an owner and a refresh strategy.

Run the SHACL suite against the mapped data immediately. The violations you find are not failures; they are the first honest picture of the gap between what the business says and what the data does. Triage them with the SME.

Step 4: Ship the Answer (Weeks 3 and 4)

Now close the loop on the question. The query that earns the budget:

SELECT ?supplier ?product ?launchDate WHERE {
  ?risk      :affects      ?supplier .
  ?supplier  :supplies     ?component .
  ?component :usedIn       ?product .
  ?product   :scheduledFor ?launch .
  ?launch    :date         ?launchDate .
  FILTER(?launchDate < "2026-12-31"^^xsd:date)
}

Deliver it through whichever surface the named owner actually uses: a dashboard via the BI/SQL endpoint, an API for an application, or a natural language interface for direct questions. Do not build all three; build the one the believer will touch this month.

Acceptance is not “the query runs.” Acceptance is the owner retiring their spreadsheet.

Step 5: Expose It to Agents (Week 4, in Parallel)

This is 2026: the spine’s fastest-growing consumer is agentic. The pattern that has emerged as the default is wrapping the spine as an MCP server, so any agent from any vendor can resolve meaning through it. Expose a small, deliberate tool surface:

lookup_entity (resolve a name to a governed IRI and definition), query (parameterized graph queries, not raw SPARQL from the agent), explain (return the lineage behind an answer), and validate (check a proposed statement against the ontology and constraints).

Two rules keep this safe. Agents get read access through governed queries, never raw write access to the model. And every agent answer must carry lineage, because an agent that cannot explain where its answer came from is indistinguishable from one that made it up.

Step 6: Governance as Code (Days 31 to 60)

The first vertebra proved value; now make it trustworthy. The repo is the governance system:

spine/
  ontology/core.ttl          (upper ontology, spine team owns)
  ontology/supplier-risk.ttl (domain module, steward owns)
  shapes/                    (SHACL, versioned with the model)
  mappings/                  (virtual graph mappings per source)
  queries/compatibility/     (real consumer queries as tests)
  CHANGELOG.md

The CI pipeline on every change: syntax validation, SHACL run against staging data, and the compatibility suite — the actual queries your consumers depend on, executed against the candidate release. A change that breaks a consumer query fails the build, and lineage tells you exactly who to talk to.

Release rules, kept boring on purpose: additive changes ship anytime; meaning changes get a new version and a deprecation window with the old definition still resolvable; nothing is ever silently overwritten. Ownership is metadata on modules, so a reorg is an update to a property, not a migration.

Step 7: Instrument for Drift (Days 31 to 60, in Parallel)

Wire the three signals from Part 3 before you need them: SHACL violation trends by module (meaning drift wears a data quality disguise), failed and unanswered question tracking (a cluster of failures is a map of where the business moved), and bypass detection (usage dropping while the business question persists means people are routing around you).

This is also where a Sentinel agent earns a seat: reviewing logs and schema changes, drafting candidate updates, filing them for steward review. Agents propose; humans approve.

Step 8: The Second Vertebra (Days 61 to 90)

Pick the adjacent question that shares concepts with the first — supplier risk shares Supplier and Contract with contract obligations. Then do the refactor that makes it a spine:

Shared concepts move up into the core module. Domain specifics stay in domain modules with domain stewards. Cross-domain identity gets resolved deliberately: one IRI per real-world entity, with owl:sameAs links or an entity resolution step where sources disagree. If, at day 90, nothing has moved into the shared core, stop and fix that before adding a third vertebra. Two applications side by side are not a spine.

The Pitfall Checklist

Ten failure modes, collected from every semantic initiative postmortem I have seen. Print it, and review it at each vertebra boundary:

  1. A class in the model that no current question needs (the cathedral, one concept at a time).
  2. Definitions in a wiki instead of in the ontology.
  3. IRIs derived from org structure or source system names.
  4. A mapping nobody owns.
  5. Materialization without a refresh strategy.
  6. A release without a compatibility run.
  7. A deprecation without a window or a notified consumer.
  8. Agent access via raw queries instead of a governed tool surface.
  9. Metrics that count triples and classes instead of questions and hours.
  10. A second vertebra that shares nothing with the first.

Each maps to a step above. None is fatal on the day it happens; all are fatal in aggregate.

The Cadence That Makes It Stick

The rhythm, once running, is modest: a weekly steward review of proposed changes (30 minutes once the Sentinel drafts them), a release train every two to four weeks, a vertebra retrospective at each 30 to 45 day boundary, and a quarterly ledger for the sponsor: questions answered, hours retired, consumers connected, cost per answered question trending down.

That last report is your budget season armor. Vertebra by vertebra, the spine earns its keep in numbers the CFO already believes in.

The Bottom Line

Nothing in this manual is exotic. A scoped question, a small governed model, virtual mappings, a shipped answer, an MCP surface for agents, CI on meaning, drift signals, and a disciplined second vertebra. The difficulty was never the technology; it was the temptation to skip the discipline and model the universe instead.

Start Monday. Pick the question. Ship the answer in 30 days. Everything else in the series follows from there.