Skip to content

Latest commit

 

History

History
32 lines (20 loc) · 3.2 KB

File metadata and controls

32 lines (20 loc) · 3.2 KB

The moat: a bad edit can't land, but the gate never breaks the build

The problem

Maintaining a governed ontology (or a set of governed configs) at any scale runs into the same failures, and they are the kind that surface late:

  • a malformed edit lands and the graph stops conforming to its SHACL shapes — downstream consumers break in ways no one traces back to the edit;
  • a consequential change is recorded with no human authorization on file, or with a rubber-stamp "ok" that is worse than nothing because it looks like a sign-off;
  • a change jumps ahead of an incomplete governance step because the ordering was a convention, not a check;
  • and the obvious fix — "just run a validator in CI" — breaks every commit in environments that don't have the heavy validator installed, so people disable it.

Each of these is usually patched per-repo, late, and inconsistently: a SHACL run here, a PR-template checkbox there, a tribal "remember to finish step N first."

The structural advantage

owl-sop-enforcement-gate makes four governance properties a single ordered chokepoint in front of the edit, with one mode switch and zero hard dependencies:

  • an ontology edit cannot land while SHACL-nonconformant (structural validity is checked first, before any metadata);
  • a governed mutation cannot be recorded without a substantive verbatim rationale — the ≥ 50-non-whitespace-char floor rejects "ok" / punctuation-only, so the sign-off is real;
  • the most sensitive mutations additionally name a responsible owner (maker/checker);
  • a mutation cannot jump an incomplete prerequisite step;
  • and the whole thing degrades open — with no pyshacl/rdflib and no phase tracker, the heavy checks return "skipped"/"complete" and the gate allows, reserving BLOCK for a real violation a real checker actually reported.

Because the verdict is a pure value and the action is mode-aware, you can run it advisory (observe) on day one, flip to enforce (block) when ready, and keep a documented, loud override for the genuine exception — without changing a line of the check logic.

Why it is hard to replicate

The individual checks aren't exotic; the assembled, ordering-correct, degrade-open discipline is. Reproducing it means: getting the order right (structural validity before metadata), getting the substance floor right (presence is not enough), separating the verdict from the sys.exit so it's testable, wiring the heavy checks as seams so CI doesn't break on a bare runner, and proving every block/allow/override path with tests that run without the heavy dependency. That is a surprising amount of careful, build-sensitive work to get right once. Forking inherits it.

Where it pays off most

Any team that treats an ontology, a taxonomy, or a set of governed configs as a controlled artifact — knowledge-graph platforms, data-governance teams, regulated data models — where "who changed this, in their own words, was it valid, and was the prior step done?" must be answerable after the fact. The advisory→enforce ramp means you can adopt it without a flag day, and the degrade-open posture means it will never be the reason a green commit goes red on a minimal CI runner.