FAQ

Frequently asked questions

Does Codevidence read my source code?

No. The build plugin reads compiled .class files after your normal build finishes and extracts only annotation metadata. Source never leaves your environment and is never transmitted anywhere. See why bytecode, not source.

Does Codevidence execute my code?

Not your production code. For Declared, the extractor parses bytecode statically — it never loads or runs a class. For Verified, your own JUnit tests run (they always did), and a JUnit extension records the outcome of the compliance assertions they call — but that’s your test suite in your pipeline, not Codevidence running anything.

What if I don’t use Java?

Today the annotations, assertions, and plugins are JVM-only — Java, and anything else that compiles to JVM bytecode and runs JUnit 5. Support for other stacks is on the roadmap, without a published timeline.

Is this a compliance guarantee?

No. Declared evidence proves a control was annotated in a specific build — provenance, not correctness. Verified evidence proves a test exercised the code and a typed assertion passed (or failed). Neither is Codevidence asserting that your organization is compliant, or that a control is correct in every case a test didn’t cover — see the evidence model.

Where does my evidence data live?

As JSON files in your build output — target/codevidence/ (Maven) or build/codevidence/ (Gradle). The plugin can optionally POST each record to an ingestion endpoint you configure; Codevidence doesn’t operate a hosted one yet. A record holds metadata about your code and build — control id, artifact hash, commit, build id, timestamp, service name — never source. See our privacy policy.

Still have a question?

Email hello@codevidence.com — a real person reads and replies.