keel

name	keel
description	Measure whether a codebase's verification actually touches the world, or whether it is checking itself. Keel gathers the verification edges it can read in a target (GitHub Actions, CircleCI, GitLab CI, Travis, package scripts, Makefile, Rakefile, pyproject and a dozen tool configs) — and reports the surfaces it recognised but could not parse, so blindness never passes for absence. It classifies each edge as anchored, self-referential, or unknown by asking whether the actor being verified can write to the signal's producer, and reports a grounding ratio. Novel cases are judged by the agent and then crystallized into probes — small reviewable scripts — so repeat shapes get cheaper every run. Then routes each ungrounded check to an anchored signal that already exists in the same graph. Use when: (1) auditing whether AI-generated or agent-maintained work is genuinely verified, (2) assessing how AI-native a codebase actually is — measured by what fraction of its verification the agents cannot author, (3) reviewing a CI/CD pipeline for circular verification, (4) someone claims tests pass and you want to know what that claim rests on, (5) measuring verifier independence. Triggers on keel, grounding ratio, grounded, is this actually verified, who checks the checker, circular verification, self-referential verification, verifier independence.
license	MIT
metadata	{"version":"1.0.0","homepage":"https://github.com/broomva/skills/tree/main/skills/governance/keel"}
primitive	null
category	governance
required	false
introduced_in	0.38.0

Keel

A ship's keel is the reference line everything else is measured from. It is also what keeps the ship from capsizing — an even keel is a stability property, not a decoration.

Keel measures one thing:

A check is only a check if the signal it reads comes from somewhere the thing being checked cannot write to.

Most verification in an agent-maintained codebase fails this. An LLM reviews what an LLM wrote. A doc is validated against another doc. A status field says "passed" because something set it to "passed". The pipeline is green and nothing has been verified.

The classification

Every verification edge gets exactly one class. The question is never "is this a good check" — it is who produces the signal, and can the actor write to that producer?

Class	Means	Examples
anchored	The producer is outside the actor's write boundary	a test process exit code, a type checker, a payment that settled, a third-party API, a customer action, an independent prober
self_referential	The producer is inside it	an LLM judging output, a doc checked against a doc, a self-set status field, an agent asserting it completed
unknown	The fork point could not be established	anything you cannot trace
not_a_check	It asserts nothing about correctness	a dev server, a help target, a formatter that only rewrites, a step that cannot fail (|| true, echo ok)

unknown fails closed — it counts against the ratio, exactly like self_referential. Absence of evidence of dependence is not evidence of independence. And unknown is never settable by the thing being measured: if the target could choose its own class it would never choose unknown.

not_a_check is excluded from the ratio — a node that asserts nothing would be a lie in either column. But it is the one shoppable class: mis-filing a real check here shrinks the denominator and inflates the score. So it carries the same burden of argument as any other verdict, the report prints its count beside the ratio, and the audit samples it like everything else. If you reach for it because a node is , the honest answer is .