# Phase 4 brief: scoring every product against every row

This is the exact brief each phase 4 auditor received. It is kept as part of
the methodology disclosure (see `00-methodology.md`).

## Your role

You score **one** load planning product against **every** row of the unified
taxonomy (`03-taxonomy.json`, draft-2, 149 rows). Phase 2 recorded what this
product documents, without a checklist. Now every row gets a verdict, including
rows your product's phase 2 auditor was never looking for. A row with no
evidence in the phase 2 file is not a fail by default: you must search the
vendor's material for it before recording `not-documented`.

## Rules

Everything in `02-audit-brief.md` still applies:

- **Buyer emulation:** vendor material only. No login, no trial, no video, no
  contact with sales.
- **Blind audit:** do not visit cargo-planner.com. Do not read other products'
  files. In `/workspaces/cplweb`, read only:
  - `research/market-audit/00-methodology.md`
  - `research/market-audit/02-audit-brief.md`
  - this brief
  - `research/market-audit/03-taxonomy.json`
  - `research/market-audit/manual-checks.md`
  - your product's entry in `01-scoping.json`
  - your product's own `competitors/<id>.json` and `.md`
- **Quote, don't paraphrase,** with the URL, or the page number for a PDF.
- **Accuracy over completeness.**

## What to record for each row

| Field | Values and meaning |
| ----- | ------------------ |
| `evidence` | `documented`: the documentation shows the pass condition is met. `claimed`: marketing says so, with no documentation of how. `documented-limitation`: the vendor says it cannot. `not-documented`: you searched and found nothing. |
| `mechanism` | Only when evidence is `documented` or `claimed`. `native`: a dedicated control or field for this requirement. `composable`: no dedicated control, but documented general mechanisms meet it together; write the `recipe` as numbered steps, each with a citation (no recipe, no `composable`). `workaround`: only by manual placement, data prepared outside the tool, or using a feature against its documented purpose. |
| `availability` | `generally-available`, `beta` or `announced`, as the vendor states. Default `generally-available`. |
| `quotes` | 1–3 short verbatim quotes with URL. Reuse phase 2 quotes where they fit. |
| `searched` | Required for `not-documented`: every source and search you used, specifically enough that someone else could repeat the search. |
| `variant` | For broad rows whose definition note asks which variant a product has: say which. |
| `note` | One or two sentences a reviewer needs: scale limits, edition restrictions, conditions. |
| `ambiguous`, `ambiguityReason` | As in phase 2. Flag hedged wording ("will try", "partially"), contradictions between sources, and evidence that exists only in screenshots. |

Judge each row by its `requirement` and `passCondition`, and read its
`definitionNote` for edge cases. Do not pass a row on something close to it:

- "The output reports axle loads" does not pass "the plan respects axle
  limits".
- A plain weight limit does not pass a pressure-based bearing row.

If a capability almost meets a row, record the evidence and say what is
missing in `note`, with evidence `not-documented` or `documented-limitation`
as the case may be.

## Output

Write `/workspaces/cplweb/research/market-audit/scores/<id>.json`:

```json
{
  "id": "",
  "product": "",
  "taxonomyVersion": "draft-2",
  "scoredOn": "2026-09-30",
  "cells": [
    {
      "row": "row-id",
      "evidence": "documented|claimed|documented-limitation|not-documented",
      "mechanism": "native|composable|workaround|null",
      "availability": "generally-available|beta|announced",
      "recipe": "",
      "quotes": [{ "text": "", "url": "" }],
      "searched": "",
      "variant": "",
      "note": "",
      "ambiguous": false,
      "ambiguityReason": ""
    }
  ],
  "newFindings": "capabilities found during this pass that phase 2 missed (brief)",
  "auditorNotes": ""
}
```

There must be exactly one cell per row, all 149 of them. Check this with a
script before you finish.

**Save as you go.** Write the file after each cluster, not only at the end. A
run can be interrupted by usage limits, and partial work that is on disk can be
resumed.

Keep all downloads in your own scratchpad subfolder named after your product
id, never in the scratchpad root.

Your final reply should give:

- the counts of cells by evidence value, and by mechanism among `documented`
  cells;
- the number of cells flagged ambiguous;
- the rows where you are least sure;
- any capability phase 2 missed.