Skip to content

The GOVENANT Standard — Part 16: The Repo Scanner and Continuous Certification

The structural half of the audit instrument (Part 9), automated as a read-only GitHub integration — and, once installed, run as a check on every pull request, turning conformance from a quarterly snapshot into a continuous property of the codebase.

The governing constraint, stated first: code proves structure; only runtime proves life. The reference implementation’s first audit (00 §0.2) is the permanent cautionary tale — architecture excellent, delivery flatlined. A code-only scan would have graded that system beautifully while it shipped nothing. The scanner therefore carries a hard verdict ceiling (§16.3): it may assert structural findings; it MUST NOT assert ALIVE or COVERED, ever.


16.1 What the scanner is

A read-only repository integration (GitHub App first; GitLab/Azure DevOps followers) that runs in the customer’s CI environment and exports aggregate findings only — the same run-in-their-environment, nothing-leaves architecture as the self-serve audit kit (J2), with an order-of-magnitude lower ask: an App install is a familiar, scoped, revocable grant that passes security review where “read credentials to production data” dies.

One scan, three products (§16.4): the audit wedge, the integration accelerator, and governance CI.

16.2 What it detects

ProbeWhat it findsStandard basis
Terminal-edge inventoryCall sites that touch the world: mail/SMTP SDKs, CRM clients, payment APIs, repo mutations, filing/upload endpointsPart 0 §0.7; the domain map, drafted mechanically
Side doorsCredentials and provider SDKs reachable from agent code paths — the fence-rule enumeration, automated15 §15.9 step 1; 14 §14.7.2
Chokepoint violationsActuation call sites that bypass the single gated functionAP-5; Part 4 §4.4 rule 1
Bus bifurcationEvent types as string literals rather than typed constants imported by both sidesAP-3; Part 4 §4.4 rule 2 (“a typo must fail the build” — a linter’s job by definition)
Hopeful fieldsNullable reason/assertion/decided_by columns where the standard requires NOT NULLAP-7; Part 4 §4.4 rule 3
Blind sensorsMonitors filtering on fields no producer writesAP-6 (partially static: producer→field→sensor trace)
Coverage invariants C1–C3Scope creep (duty levers ⊄ charter) and dependency-order inversions, from configPart 3 §3.5 — explicitly “statically checkable”
Scheduler inventoryCron entries, queue consumers, event subscriptions scattered across deploy configPart 3 §3.10 — the roster-import draft, generated

Every finding cites file:line and carries a confidence tier; low-confidence heuristics are labeled as leads, never as findings (§16.5).

16.3 The verdict ceiling

The scanner’s maximum verdict is “structurally L2-capable”: gates exist, chokepoints hold, side doors enumerated (or absent), invariants pass. It MUST NOT claim:

  • ALIVE — a database fact: one governed action traceable by ID with a verified outcome row (00 §0.5). Invisible in source.
  • COVERED — a database fact: duties due vs. delivered vs. reasoned misses. Invisible in source.
  • Any maturity level as achieved rather than candidate — the audit’s rules of evidence (Part 9: ground truth is the database and the code) require both halves.

The report’s own closing line enforces the upsell honestly: “Structure verified. Now prove it’s alive.” The scan is the X-ray; the runtime audit is the pulse. Selling the X-ray as the whole physical would be the instrument committing the exact fraud it exists to catch.

16.4 The three products

16.4.1 The wedge — scan-as-audit (transforms J2)

The self-serve entry drops from “grant DB access, run a kit” to “install an App, read the report in an hour.” Output: the structural scorecard, the anti-pattern findings, and the side-door inventory — forwardable to the buyer in the same afternoon. The runtime audit remains the paid second act, now pre-sold by the scan’s own ceiling disclaimer.

16.4.2 The integration accelerator — scan-to-PR (transforms Install; attacks J3-F3, J4 effort)

The scan’s output is the domain map and the gap register — so generate the work:

  • Levers drafted from the terminal-edge inventory (each with its owning-role placeholder and a proposed outcome assertion from the provider’s response shape).
  • The gating codemod: a draft PR per actuation call site swapping the direct SDK call for actions.create (15 §15.3), reviewable function-by-function.
  • The roster import drafted from the scheduler inventory (Part 3 §3.10 steps 1–2, generated).

Install stops being a services project and becomes reviewing a pull request. Human review is mandatory — the codemod is a proposal entering through the constitution plane like any other agent-authored artifact (5 §5.2: agent-authored config is an outbound artifact).

16.4.3 Governance CI — continuous certification (the moat)

Installed as a required check, the scanner runs on every PR:

  • “This PR introduces an ungated terminal edge” → blocked at merge. The fence rule becomes something that cannot regress.
  • New event types without consumers, new duties failing C2/C3, new hopeful fields → caught at review time, not at the next quarterly audit.
  • Certificates pin to commit SHAs (extending 13 §13.3’s version-pinning): the certificate names the SHA whose scan passed and whose runtime probes passed; the check history is the structural half of the probe log. Conformance becomes a continuous property with a public ledger of its own — a claim no snapshot-based badge can match.

16.5 Precision discipline (brand-critical)

One false “ungated edge” finding in a prospect’s repo, publicly dunked on, discredits the instrument (J2-F6, applied double — the scanner runs unattended at scale). Rules:

  1. Conservative by construction: findings only where the rule is mechanical (a provider SDK import reachable from an agent entrypoint); heuristics ship as labeled leads.
  2. Every finding cites evidence (file:line + the matched pattern) — the scanner obeys the audit’s own rules of evidence.
  3. Suppressions are provenance-carrying config, reviewable and visible in the report (“3 findings suppressed by the customer”), never silent.
  4. Language/framework coverage is published as a matrix — a scan of a stack the scanner half-understands must say so rather than under-report.

16.6 Limits

  • Code-only blindness (§16.3) — restated because it will be forgotten by sales before it is forgotten by engineering.
  • Legacy is off-repo: J3’s claims core is a mainframe, not a GitHub repo. The scanner accelerates the modern-stack half of an enterprise engagement; the legacy connector work remains manual.
  • Coverage matrix reality: start narrow (TypeScript + Python; the top agent frameworks; a fingerprint library of major provider SDKs) and publish the matrix. Breadth grows with the fingerprint library, which is itself a compounding asset — every engagement teaches it new edges.

16.7 Build order

  1. Fingerprint library for terminal edges + side doors (TS/Python, top providers) → the wedge report (§16.4.1).
  2. PR-check mode with the fence-rule gate (§16.4.3 minimal: block new ungated edges) — small delta over #1, disproportionate moat.
  3. The codemod generator (§16.4.2) — highest engineering cost, gated on #1’s precision holding in the field.
  4. SHA-pinned certification once the registry exists (13 §13.9 item 3).