Stop rebuilding compliance evidence every audit cycle.

The problem

Compliance evidence still lives in spreadsheets and Slack threads

How it works · Declared → Verified → Observed

Evidence you can actually trust — and evidence you can't, labeled honestly

Not all compliance evidence is equally strong. Codevidence is explicit about the difference — and today it takes you from what a developer declared all the way to what a test confirms.

A cryptographic artifact hash tells you evidence came from this exact build. Whether the control actually behaves as claimed is a separate question — the one Verified answers, with a test.

1. 01 Available now

   DECLARED

   Developers annotate compliance-relevant code with a lightweight, typed annotation. A build-time step extracts it directly from compiled bytecode — your source code never leaves your environment.

2. 02 Available now

   VERIFIED

   A JUnit test, annotated with @VerifiesControl, calls a typed compliance assertion — and Codevidence records whether that check passed or failed, linked to the control it verifies. The gap between what a developer declared and what the code actually does, closed.

3. 03 Coming next

   OBSERVED

   Runtime instrumentation confirms the control executed in production, tied to a specific deployment and commit — the strongest evidence tier, generated from real behavior, not developer intent.

See what Verified looks like in code ↓

The mapping

Many call sites. One control. One source of truth.

Compliance logic is rarely in one place. Codevidence collapses every code path that implements a control into a single evidence record — declared at build, verified by a test, and anchored to the exact commit either way.

Trust & architecture

We never read your source code. On purpose.

Enterprises won't grant a third-party SaaS access to their codebase — and they shouldn't have to, just to prove they're compliant. Codevidence is architected around that constraint from day one: a Maven/Gradle plugin scans your compiled .class files after your normal build finishes, extracting only annotation metadata — never source, never business logic, never executed. What comes out is a structured JSON evidence record — never your source, never your business logic — that carries a cryptographic artifact hash, commit SHA, and build timestamp, so the chain of custody holds end to end. It stays in your build output, and — only when you set an API key — is also posted to your Codevidence portal (or an ingestion endpoint of your own).

That's not just an access-control choice — it's what makes the evidence model work. Codevidence doesn't need to read your source to establish a cryptographic provenance chain between a declared control and the exact artifact that implements it. Evidence platforms that connect to your repo can tell you a control exists somewhere in your codebase. Codevidence tells you exactly which artifact, class, method, commit, and build claimed to implement it — and proves that claim didn’t change silently between audits.

Where this fits

Why not just use Vanta or Drata?

Evidence-automation platforms are excellent at connecting to your cloud, your ticketing system, and your Git provider. What they can’t do is establish a cryptographically anchored link between a compliance claim and the specific application-code artifact that implements it — without reading your source. That’s a narrower problem, and it’s the one Codevidence solves. Run them together: the platform manages your program, Codevidence anchors the code-level evidence underneath it.

Evidence doesn’t have to stop at a JSON file.

Every evidence record is structured JSON in your build output — portable, diffable, and entirely yours. The Codevidence tenant portal rolls those records up: sign in at app.codevidence.com and every control shows the code that implements and verifies it, an Article 30-style record, and the evidence JSON behind it. The build plugin publishes to it now; live per-tenant history is the piece we’re rolling out with our design partners.

Publishing is opt-in: the plugin only posts when you set a CODEVIDENCE_API_KEY. See build plugin configuration.

For engineers

One annotation. Any framework. Zero new infrastructure to run.

Mark compliance-relevant methods the same way you already mark @Transactional or @Cacheable. The same annotation covers SOC 2, SOX, GDPR, and anything else that needs evidence — the framework field just points at the criterion it satisfies. Codevidence's build plugin does the rest. Below: two Declared examples, and a Verified one — a test that confirms the control actually behaves the way it was declared to.

@ComplianceControl(
    id = "consent.capture",
    framework = "GDPR:Art.30"
)
public void recordConsent(String userId) {
    // your existing implementation
}

{
  "schemaVersion": "0.1",
  "kind": "declared",
  "control": {
    "id": "consent.capture",
    "framework": "GDPR:Art.30"
  },
  "artifact": {
    "sha256": "a1b2c3...",
    "class": "com.acme.checkout.ConsentService",
    "method": "recordConsent",
    "descriptor": "(Ljava/lang/String;)V"
  },
  "provenance": {
    "commit": "a3f9e21",
    "commitSource": "ci-env:GITHUB_SHA",
    "buildId": "ci-4821",
    "buildEnvironment": "ci",
    "timestamp": "2026-08-28T14:32:00Z",
    "serviceId": "checkout-service"
  }
}

@ComplianceControl(
    id = "data.encryption.at-rest",
    framework = "SOC2:CC6.1"
)
public void persistCustomerRecord(CustomerRecord record) {
    // your existing implementation
}

{
  "schemaVersion": "0.1",
  "kind": "declared",
  "control": {
    "id": "data.encryption.at-rest",
    "framework": "SOC2:CC6.1"
  },
  "artifact": {
    "sha256": "d4e5f6...",
    "class": "com.acme.storage.CustomerRepository",
    "method": "persistCustomerRecord",
    "descriptor": "(Lcom/acme/storage/CustomerRecord;)V"
  },
  "provenance": {
    "commit": "a3f9e21",
    "commitSource": "ci-env:GITHUB_SHA",
    "buildId": "ci-4821",
    "buildEnvironment": "ci",
    "timestamp": "2026-08-28T14:32:00Z",
    "serviceId": "customer-service"
  }
}

@VerifiesControl(id = "consent.capture")
@Test
public void consentIsRecordedWithLawfulBasis() {
    var service = new ConsentService();
    service.recordConsent("user-42");

    ComplianceAssertions.assertConsentRecorded("user-42", "consent");
}

{
  "schemaVersion": "0.1",
  "kind": "verified",
  "verifiesControl": "consent.capture",
  "test": {
    "testClass": "com.acme.checkout.ConsentServiceTest",
    "testMethod": "consentIsRecordedWithLawfulBasis",
    "assertionType": "assertConsentRecorded"
  },
  "result": {
    "status": "passed",
    "buildId": "ci-4822",
    "commit": "a3f9e21",
    "timestamp": "2026-08-28T14:41:00Z"
  }
}

Every annotated method produces its own evidence record at build time — one per control, tied to the exact class, method, and commit that implements it. Records are written as structured JSON under target/codevidence/; teams that need semantic interoperability with existing privacy or GRC ontologies (e.g. DPV for GDPR) can export to JSON-LD or RDF.

The third pair is Verified: a @VerifiesControl test calls a typed compliance assertion, and Codevidence records whether it passed or failed as its own evidence record, linked back to the Declared control. Read the full spec →

See the evidence

What a control's evidence looks like, assembled

One control, end to end: where it lives in your code, the exact build that proves it, and every prior build that carried it too.

checkout-service
└── ConsentService
    └── recordConsent()

This is a mockup of what an evidence record looks like once assembled — the build plugin generates the underlying Declared data today. Browsing it laid out like this is part of your Codevidence workspace, described above — early access, not a live product yet.

Use cases

Built for the moments that actually matter