Assay · System documentation
- How Assay works
How a decision report works
What a buyer sets up
How Assay works
Assay answers a buyer's question: does this software meet the standard we require? It answers it from signed evidence produced elsewhere, against a standard the buyer has written down — and it refuses to answer at all when the evidence cannot be verified.
This is the reference for anyone who needs to understand the system without reading its source — the people who build and support it, colleagues answering a question, and anyone evaluating the product. It assumes no background beyond "I know software gets bought and sold".
The one-paragraph version
A supplier has their code measured, and the result is signed and published as evidence. A buyer writes down the standard they require — a bar — and binds it to what they are buying. When a buyer requests a decision report, Assay fetches the signed evidence, verifies it, checks it against the bar, and produces a verdict with the reasoning attached. Assay never receives the source code, and never recalculates a score.
The altitude, and why
This documentation describes the system from a deliberate height. It does not list the checks a bar can contain, the current catalogue of measurable properties, or the internal rules that decide reach. Those change as the system improves, and documentation that repeated them would be wrong within the week — and documentation that is sometimes wrong is worse than none, because you stop being able to tell which parts to trust.
For the detail underneath, the code and the configuration are the source, and they are current by definition.
Why our own documentation is published. This is the documentation we write for ourselves — the same pages, at the same altitude, whether or not anyone outside reads them. We publish it because we have chosen to be transparent about how we work: our prices, how the product actually operates, and how a verdict is arrived at. Making the internal documentation public simply follows from that.
Related
- Security and data handling — the formal account of storage, retention, encryption and subprocessors. Where the two overlap, that page is authoritative.