# Compatibility report draft format

An owner records what happened on one model, firmware and software version.
A report starts as a local draft for review. It does not establish that a whole
device family is compatible, and it never upgrades a recipe's verification.

## Version 1

- `schemaVersion`: `1`.
- `status`: always `draft`.
- `verification`: always `unreviewed`, including successful observations.
- `createdAt`: the UTC ISO timestamp when the draft was prepared.
- `subject`: the guide's `device` and `hack` slugs, plus `recipe` when linked.
- `environment`: the exact `model`; `firmware` and `software` are strings or
  `null` when unknown. Preserve their versions, rather than inferring support.
- `outcome`: `not-tested`, `works`, `partial` or `failed`.
- `testedOn`: the actual test date (`YYYY-MM-DD`), or `null` for `not-tested`.
  Never use a source-read date as a device-test date or invent a future test.
- `observations`: what was checked and what happened, including the failure
  or limit for a partial result. A tested outcome needs an observation.
- `evidence`: an optional HTTPS link to evidence suitable for sharing, or
  `null`. Do not include signed links, login credentials or local addresses.

A documentary rehearsal must use `not-tested` and a null `testedOn`.
Neither an agent's ability to read a recipe nor a simulated fixture counts as
independent hardware reproduction.

## Owner review

Before sharing, inspect the entire JSON and remove keys, tokens, account
details, local addresses, SSIDs, serial numbers and information about the home.
The browser draft removes common identifiers from observations locally; this
is not a substitute for the owner's review. Dedicated version fields remain
intact. No credentials or device data are collected automatically.

Share the reviewed draft with the person coordinating the test. Publication
and a change to verification require a separate review of the actual evidence.