# Verify the synthetic report format sample

This bundle was exported through the platform's actual report create → review →
independent approval → issuance API using local synthetic users and an empty
assessment. **No scanner ran and no vulnerability was demonstrated.** The test
`services/platform/tests/test_published_sample.py` exercises and can regenerate
that path. The report has zero observations and evidence references. Its example
scope/authorization records are test fixtures, not proof of target testing.

## Establish trust before verification

Use a verifier and public-key pin obtained from an independently reviewed commit
or another trusted channel, not executable code and a key taken on faith from the
bundle being checked. The key is dedicated to this sample; its private material
was generated transiently and never exported. It is not a production signing key.

The public pin in this reviewed source version is:

- Key identifier: `published-sample-2026-09-21`
- Ed25519 public key (base64): `ej3Q17iz9kD4ghCyYU6Iryb6kY6cEVac5C6h/a9siUw=`

These values are only trustworthy if you trust the channel supplying this source
version. Reading a public key from `signature.json` cannot establish authorship.
A caller must provide both trusted values; the verifier does not trust the bundle
implicitly. The unsigned outer key identifier must match that trusted mapping.

## Run the verifier

Install the reviewed `cryptography` dependency in a local environment, then run:

```sh
python3 verify.py --trusted-key-id 'published-sample-2026-09-21' \
  --trusted-public-key 'ej3Q17iz9kD4ghCyYU6Iryb6kY6cEVac5C6h/a9siUw='
```

A hosted bundle that carries `transparency.json` (ADR 0090) also needs the
signing key's published log-signing companion, taken from the key registry
entry with purpose `transparency-signature` whose `signs_for` is the key id:

```sh
python3 verify.py --trusted-key-id '<key id>' --trusted-public-key '<Ed25519 key>' \
  --trusted-log-signing-public-key '<companion SubjectPublicKeyInfo DER, base64>'
```

This prints VALID only if the complete v1 issuance statement is signed by the
supplied key and the exact bytes of both artifacts match its digests. Invalid
JSON, missing fields, key substitution, signature changes, CRLF conversion and
appended newlines fail with INVALID and a nonzero exit. No text normalization or
newline stripping is performed.

For independent byte-digest comparison:

```sh
shasum -a 256 report.md snapshot.json
```

Expected in this version:

- report.md: `f467dc9c188364d2f7d965352f8d882aa434a6464ef904c5a0577882602462bc`
- snapshot.json: `24a406b47d5b6272fec93f8dc23c73acd13ce9daff8e222af0a5e6de89eebc87`

## Interpretation

The signature demonstrates byte integrity relative to the supplied trusted key.
Signed creator/approver strings are assertions, not proof of those people's
identity. This sample establishes neither scan execution nor finding accuracy,
coverage, compliance or production readiness. There is no request/response
transcript or detection-quality claim. Real engagements require their retained
execution evidence and independently trusted production signing keys.