The Missing Middle: What GuardSpine Actually Does

GitHub covers code. DocuSign covers signatures. Purview covers data movement. Nobody covers what AI actually changed inside a document. That’s the gap. Here’s what fills it.

The Blind Spot in Your Stack

Every enterprise I talk to has the same setup. Source control for code. Signing tools for contracts. Data loss prevention for sensitive files leaving the perimeter. They feel covered.

Then I ask one question: when your developer used Copilot to rewrite the auth middleware last Tuesday, where is the evidence of what changed and why?

Silence.

Source control tells you that lines 42-87 of auth.ts were replaced. It does not tell you that an AI model generated the replacement, that the replacement removed a rate-limiting check, that no human reviewed the security implications, or that the change violated your internal policy on authentication modifications. Git knows the diff. Git knows nothing about the context around it.

This is the missing middle. The space between “we track changes” and “we can prove what happened.” Every compliance framework — SOC 2, ISO 27001, FDA 21 CFR Part 11, NIST AI RMF — expects you to demonstrate control over your change process. Not just that changes happened, but that appropriate review occurred and that evidence exists to prove it.

What GuardSpine Is

GuardSpine is a governance layer that sits between your AI tools and your audit trail. When an AI-assisted change happens — to code, to a PDF, to a spreadsheet, to an image — GuardSpine captures the diff, classifies the risk, routes it for appropriate review, and seals the entire chain into a tamper-evident evidence bundle.

That evidence bundle is the product. Not a dashboard. Not a report. A cryptographically sealed package that any third party can verify offline, without trusting us, without calling our API, without needing a license key.

The architecture has two layers: an open-source trust layer and a private value layer. This matters. A lot.

The Open-Source Trust Layer

Eight packages, all Apache 2.0. This is not open-core theater where the “free” version is a demo. These are production components:

guardspine-spec defines the evidence bundle schema (v0.2.1). The format for how evidence is structured, hashed, and chained. Think of it as the grammar of governance.

guardspine-kernel (TypeScript) and guardspine-kernel-py (Python) implement the core sealing logic. Take a set of evidence items, build a hash chain, compute the root hash, attach signatures. These are the engines.

guardspine-verify is the offline verification CLI. Hand it a bundle, it tells you whether every hash checks out, every signature validates, and the chain is intact. No network calls. No account required.

codeguard-action is the GitHub Action. Drop it into any repo’s CI workflow and every pull request gets triaged by risk tier, reviewed by an AI council, and sealed into an evidence bundle. 737 tests. Version 1.0.1.

guardspine-adapter-webhook handles inbound events from GitHub, GitLab, and generic webhook sources. HMAC-SHA256 validation included.

n8n-nodes-guardspine connects GuardSpine to n8n workflow automation. 14 custom nodes for building governance workflows without writing code.

guardspine-openclaw integrates with OpenClaw for AI gateway governance.

All eight are Apache 2.0. Fork them. Audit them. Build on them. The trust layer cannot be proprietary because trust that depends on a vendor is not trust — it’s faith.

The Four Guard Lanes

GuardSpine does not treat all content the same way. A code change and a PDF edit have different structures, different risk profiles, and different diff algorithms. Trying to handle them with one generic pipeline produces garbage. So there are four lanes, each purpose-built.

CodeGuard

The first lane built and the most mature. CodeGuard handles code changes — pull requests, commits, merge requests. Here is the flow:

The diff comes in. CodeGuard parses it into change units: not just file-level diffs, but function-level, import-level, config-level changes. Each change unit gets classified into a risk tier (L0 through L4) based on deterministic pattern matching — not AI judgment. Auth changes, cryptography, PII handling, payment logic, infrastructure config — these all have predefined risk classifications.

Once classified, the change routes to the appropriate review process. L0 and L1 can auto-approve. L2 gets AI council review. L3 and L4 require multi-model council review with explicit approval tracking.

The AI council is not one model. It is multiple models — Claude, GPT, Gemini, or local models via Ollama — reviewing independently and voting. Diverse reviewers catch different failure modes. A council that agrees gives high confidence. A council that disagrees flags the change for human attention.

Every step — the diff, the classification, the reviews, the votes, the approval — gets sealed into an evidence bundle.

PDFGuard

PDFs are not code. You cannot git diff a PDF. But regulated industries change PDFs constantly — SOPs, batch records, regulatory submissions. PDFGuard renders each page, computes page-level diffs (pixel comparison with structural overlay), identifies what moved where, and packages the change evidence.

The output is not “the PDF changed.” The output is “page 14, section 3.2.1, the dosage calculation was modified from X to Y, here is the visual diff, here is who changed it, here is the policy evaluation.”

SheetGuard

Spreadsheets are worse than PDFs. A formula change in cell G47 can cascade through an entire financial model. SheetGuard tracks cell-level diffs and formula diffs separately. It knows the difference between someone changing a label (cosmetic) and someone changing a VLOOKUP reference (structural).

Financial models, clinical data sheets, inventory calculations — these are high-stakes artifacts where a single cell change can mean millions of dollars or a compliance violation. SheetGuard treats them accordingly.

ImageGuard

The newest lane. ImageGuard combines pixel-level diffing with object detection. It doesn’t just tell you “the image changed.” It tells you “the logo was moved from top-left to center, the background color changed from #FFFFFF to #F5F5F5, and a new text element was added in the lower-right quadrant.”

Marketing assets, product labels, packaging designs — anywhere visual content is subject to regulatory or brand governance.

The Evidence Bundle Flow

Every lane produces the same output: an evidence bundle. The flow is consistent regardless of content type:

1. Artifact ingestion. The changed artifact enters the appropriate lane.
2. Diff computation. The lane computes a content-appropriate diff.
3. Risk classification. Deterministic pattern matching assigns a risk tier.
4. Policy evaluation. The change is evaluated against configured policies.
5. Review routing. Based on risk tier and policy, the change routes to auto-approve, AI review, or human review.
6. Evidence collection. Every step produces evidence items: diffs, classifications, policy evaluations, review decisions, rationales.
7. Sealing. Evidence items are ordered, hashed, chained, and signed. The root hash commits the entire bundle.
8. Storage. The sealed bundle is stored and indexed.

149 API endpoints across 20+ routers handle this flow. That sounds like a lot. It is not — each router handles a specific domain (bundles, policies, reviews, users, lanes, connectors, webhooks), and the endpoints are RESTful CRUD plus the operations specific to each domain.

Open-Core, Not Open-Bait

The open-core model gets abused. Companies release a crippled free version, then charge for the features you actually need. That is bait, not a business model.

GuardSpine’s split is different. The open-source layer handles trust: creating evidence bundles, verifying them, the schema, the cryptographic primitives. You can build a complete governance system on the open-source components alone. People do.

The private layer handles scale: multi-tenant dashboards, team management, policy templates, compliance report generation, lane orchestration for large organizations. These are operational conveniences, not trust prerequisites.

If you stop paying us, your evidence bundles still verify. Your audit trail still works. Your data is still yours. That is the line between open-core and open-bait.

Why This Architecture

I could have built a SaaS dashboard that calls our API to “check” if a change is governed. That is what most governance tools do. You send them your data, they run their proprietary analysis, they give you a green or red light, and you trust them.

But trust that depends on a running server is conditional trust. Trust that depends on a vendor staying in business is fragile trust. Trust that depends on calling an API is trust with a single point of failure.

An evidence bundle that anyone can verify offline with open-source tools — that is unconditional trust. It does not degrade when we have downtime. It does not expire when your contract lapses. It does not depend on our opinion about what “governed” means.

The missing middle is not another monitoring tool. It is proof. Machine-verifiable, vendor-independent, offline-capable proof that your AI-assisted changes went through the process you defined.

Getting Started

If you want to see this in action before reading more theory, the next post walks through installation in 10 minutes. Three entry points: Python CLI, Node.js package, or GitHub Action. Pick one. If you want to go deeper into the cryptographic internals, the evidence bundles post covers the hash chain construction byte by byte.

If your organization is producing AI-assisted changes to regulated artifacts and your current answer to “prove it was governed” is “we have an approval process,” we should talk. The approval process is not evidence. The evidence bundle is.

Book a call and I will show you the gap in your current stack.