MEERKAT KNOWS · MONGOOSE WORKS · ZEGIT PROVES

You have a pipeline. Can you prove it?

zegit turns every change your developers and agents make into signed, audit-grade evidence — bound to the exact commit. Not CI logs. Not PR approvals. Proof.

THE GAP

Claims aren't proof.

Your README says TDD. Your process doc says trunk-based. Your pipeline says continuous delivery. But when someone asks you to prove that a specific release actually went through those practices — that the tests ran, the checks passed, the review happened, against this exact code — what do you hand them? CI logs scroll away. PR approvals are a green checkmark and a vibe. SBOMs sit in a bucket, unsigned. The practice is real. The proof is missing.

And the ground is shifting. Even where your process is still mostly manual today, the gaps widen the moment autonomous agents enter the scene — more changes, more actors, and less of the human context your controls quietly relied on. At the same time, the EU Cyber Resilience Act turns we follow good practice into something you must prove — for a specific release, who did what and which quality controls ran.

AN OPINIONATED PATH

Sound engineering is how you let agents in safely.

zegit isn't neutral plumbing. It assumes a specific, proven way of working — and makes that the path of least resistance for developers and agents alike.

Test-driven

If you can't write the test, the spec isn't done yet. Acceptance criteria are executable; "done" means the evidence is green and bound to the commit.

Trunk-based

main is always deployable. Small changes, continuously — gated by evidence, not by branch ceremony. Long-lived branches are where provenance goes to die — so how else do you trace the blast radius of the latest supply-chain attack or the zero-day disclosed this morning?

Continuous delivery

Verify, don't re-run. Validation happens once, at the edge; everything downstream checks the signed result. There can only be one way to production: the pipeline.

Work this way, and the proof writes itself.

THE TOOLCHAIN

Three tools. One evidence record.

meerkat knows

A knowledge base your agents query over MCP, so work starts from what's actually true at your org.

Read the thesis
mongoose works

An agent harness — an OpenCode-style TUI — where developers and agents do the work. Every meaningful step emits an evidence record bound to the git state it ran against.

Read the thesis
zegit proves

Signs, gates, and bundles those records. The signed attestation is proof the work happened the way you claim.

Read the thesis
unsigned raw record
validated carries decision
signed DSSE attestation

WHAT YOU GET

One record. Escalating trust.

Every record is bound to an exact commit and tree. The policy engine grades it — ALLOW, REQUIRE_REVIEW, or BLOCK. zegit signs the passing ones into a DSSE attestation you can verify offline, years later. Tamper with the code and the evidence goes stale — by construction.

ALLOW REQUIRE_REVIEW BLOCK

And this isn't just good hygiene anymore — the regulator is starting to ask the same question.

EU CYBER RESILIENCE ACT

Now the regulator is asking too.

The Cyber Resilience Act pulls every manufacturer of software with digital elements into scope — secure-by-design obligations, vulnerability handling, and demonstrable evidence across the lifecycle. CI logs and PR reviews won't satisfy a conformity assessment, and most teams have no credible way to operationalize it in their pipeline.

zegit turns every release tag into an audit-grade CRA Evidence Bundle — DSSE-signed, cross-referenced to Annex I, and verifiable offline — without migrating off the Git host you already use.

CRA-grade governance for the Git you already have.

  • Per-release Evidence Bundle
  • Mapped to CRA Annex I
  • Signed SBOM + vuln scans
  • Quorum-approved release tags
  • Offline-verifiable, for years

You don't bolt this on. Work the opinionated way — TDD, trunk-based, continuous delivery — and the bundle is already written. Compliance is the floor; good engineering is the point.