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.
MEERKAT KNOWS · ZEGIT PROVES · WATCHSONG DISCLOSES
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.
zg — validate
$ zg validate
→ lint ............... ok
→ test ............... ok
→ acceptance ......... ok
→ security-scan ...... ok
DECISION: ALLOW
✓ AoV signed refs/zegit/aov/9f3c1a2
$ git push gateway main
remote: zegit: refs/heads/main → ACCEPT (commit 9f3c1a2)
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 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 took for granted. 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 assumes a specific, proven way of working and makes it the path of least resistance for developers and agents alike.
Trunk-based
main is always deployable. Small changes land continuously,
gated by evidence, not by branch ceremony. Long-lived branches are where
provenance goes to die. Without it, how 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. Know, prove, disclose.
meerkat
knows
A knowledge base your agents query over MCP, so work starts from what's actually true at your org.
Read the thesis
zegit
proves
Signs, gates, and bundles the evidence your developers and agents produce. The signed attestation is proof the work happened the way you claim.
Read the thesis
watchsong
discloses
Vulnerability disclosure as a service, at an early stage: a disclosure timeline and CRA reporting guidance for the products you ship, with CVE assignment once its CNA scope is granted.
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 as
ALLOW, REQUIRE_REVIEW, or BLOCK. zegit signs the
record into a DSSE attestation you can verify offline, years later, and the gateway lets
only ALLOW through. Tamper with the code and the evidence goes stale, because
it no longer matches the tree it was bound to.
ALLOW
REQUIRE_REVIEW
BLOCK
And 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, with 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, without migrating off the Git host you already use. Each bundle is DSSE-signed, cross-referenced to Annex I, and verifiable offline with nothing but the Root CA certificate.
CRA-grade governance for the Git you already have.
- Per-release Evidence Bundle
- Mapped to CRA Annex I (draft, expert review pending)
- Your SBOM, sealed under the signed manifest
- 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.
INSIDE THE CONTROL PLANE
Every release, every attestation — one place, per repository.
zegit is not another place to keep your code. It sits in front of the forge you already use and governs what is allowed to become a release: today as its own SSH gateway, which runs the checks on push and is the only writer to the protected branch on GitHub and Gitea, forwarding each accepted push once the Control Plane has re-verified it. Enforcement directly on GitHub.com and GitLab.com (shadow mode first) and on GitHub Enterprise Server is on the roadmap. Pick a repository and the Control Plane shows only that repository's tag requests, release policy and attestations. These are real renders of the scoped pages.
