Read the reasoning, not just the result

This is not a product with a marketing site and a locked black box behind it. The reasoning is documented because the reasoning is the product: a governance tool that cannot explain itself is asking for exactly the trust it is supposed to replace.

Start here, by what you are trying to do

Understand how a conclusion is reached

The methodology page describes the four classes of evidence, how rules are versioned, and why UNKNOWN is a result rather than a failure.

Get a security review through

The security page states what is read, what is never read, and what the read-only promise actually rests on.

Work out whether it fits your stack

The how-it-works page lists the engines, the application frameworks and ORMs, and the API description formats that are read.

Put it in a pipeline

The developers page covers the command line, the exit codes and the governance gates.

Hand something to an auditor

Export the reports today. The evidence package page describes the archive that is planned, its manifest and how its integrity will be verified.

Architecture decision records

Every significant decision in this codebase has a numbered record: the context, the decision, the consequences accepted, and the alternatives that were rejected and why. Records that make a security or correctness claim declare it as a named guarantee, and a test must reference that name or the build fails — so a documented promise cannot quietly drift away from the code that is supposed to keep it.

They ship with the source. If you are evaluating the product seriously, they are the most useful thing to read.

In the application

The About screen carries the release history, the rule set version and what this deployment is configured to do. Settings shows the operator half: whether an identity provider is in use, whether anything leaves the platform, and what an assistant is permitted to do.