# Phase 2 auditor brief: open capability audit

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

## Your role

You are auditing **one** load planning software product (3D loading of
containers, trucks, ULDs or pallets). Your job is to record everything the
product's **planning engine** can be made to take into account or produce,
based only on what the vendor publishes. There is no checklist on purpose:
record what is there, in the product's own terms, as completely as you can.

Later phases merge every product's findings into one matrix. How useful that
matrix is depends on your records being complete, granular and accurately
sourced.

## Rules

1. **Buyer emulation.** Use only material a prospective buyer can reach without
   contacting the vendor's sales team:
   - vendor websites and feature pages
   - public documentation, help centres and knowledge bases
   - public API specifications
   - downloadable manuals
   - release notes and public blog posts

   Do not sign up for trials, log in or use video.
2. **Only the vendor's own material is evidence.** Third-party reviews,
   directories and competitor-written comparisons may help you find the
   vendor's pages, but never count as evidence about the product.
3. **Blind audit.** Do not visit cargo-planner.com. Do not read any file in
   `/workspaces/cplweb` except:
   - this brief;
   - your product's entry in `research/market-audit/01-scoping.json`;
   - your own output files.

   Do not read other auditors' output.
4. **Engine capability only.** Record what the optimiser or planner can
   express or produce:
   - equipment and container modelling
   - cargo properties
   - stacking and load-bearing
   - rules between items
   - positioning
   - weight distribution and axles
   - sequencing and multi-drop
   - pallet building
   - objectives
   - what the plan output contains (for example centre of gravity or axle
     loads)

   Product qualities are out of scope: UI, integrations, pricing,
   deployment and support. Put them, in one line each, in `outOfScopeNotes`
   and move on.
5. **Granularity.** One record per distinct capability, with its parameters
   and limits spelled out. "Axle weight limits" is not enough; write
   "axle load limits for exactly two axle groups, set by distance from the rear
   and a maximum weight". Units, counts, scopes (set per item, per item type,
   per container, per plan) and edition or tier restrictions all matter.
6. **Quote, don't paraphrase.** Every capability carries at least one short
   verbatim quote with its URL, or a page number for PDFs. If an API field is
   the evidence, quote its name and description.
7. **Accuracy over completeness.** If you are unsure what a setting does,
   record it with `ambiguous: true` and say why. Never infer a capability that
   the material does not support.

## Classifying each capability (strict layer)

**`mechanism`: how the product gets there**

| Value        | Definition |
| ------------ | ---------- |
| `native`     | A dedicated, named control, field or setting whose documented purpose is this capability. |
| `composable` | No dedicated control, but documented general mechanisms satisfy it when combined. You must write the `recipe` step by step, citing a source for each step. No recipe, no record. |
| `workaround` | Only reachable by manual placement, by preparing data outside the tool, or by using a feature against its documented purpose. |

**`evidence`: how well it is evidenced**

| Value                   | Definition |
| ----------------------- | ---------- |
| `documented`            | Described in the vendor's documentation, API specification or manual. |
| `claimed`               | Stated in marketing only, with no documentation of how it works. |
| `documented-limitation` | The vendor states the product cannot do something. Record these too, quoted. They are valuable. |

**`ambiguous`:** set to `true`, with an `ambiguityReason`, when any of these apply:

- a capability does not fit one value cleanly;
- the line between native and composable is a judgement call;
- the classification raises a fairness question (for example, a general
  mechanism that plausibly covers something, but where the docs do not show
  it).

Also list the product's **general-purpose mechanisms** separately: rule
engines, custom fields or attributes usable in rules, scripting, configurable
objectives, anything a user can combine to express constraints the vendor did
not name. Describe what each one can select on and what it can do. Later
phases depend on this to judge composable capabilities fairly.

## Output

Write `/workspaces/cplweb/research/market-audit/competitors/<id>.json`, where
`<id>` is the product's id from `01-scoping.json`:

```json
{
  "id": "",
  "product": "",
  "vendor": "",
  "readOn": "2026-09-30",
  "versionsCovered": "which product versions/editions the docs describe, and how current they are",
  "sources": [{ "url": "", "type": "help-centre|manual|api-spec|release-notes|feature-pages|blog|other", "title": "", "coverage": "what you read of it" }],
  "sourcesUnreachable": [{ "url": "", "problem": "" }],
  "modes": { "road": "", "sea": "", "air": "", "rail": "", "pallet": "", "note": "what equipment types are supported, briefly, with evidence" },
  "generalMechanisms": [{ "name": "", "description": "", "canSelectOn": "", "canExpress": "", "quotes": [{ "text": "", "url": "" }] }],
  "capabilities": [
    {
      "id": "short-kebab-slug",
      "area": "free-text grouping, e.g. equipment, cargo, stacking, between-items, positioning, weight, sequence, pallet, objective, output",
      "name": "",
      "description": "what the user can make the planner do, in neutral plain terms",
      "parameters": "scope, units, counts, limits, edition restrictions",
      "mechanism": "native|composable|workaround",
      "recipe": "only if composable: numbered steps, each with a citation",
      "evidence": "documented|claimed|documented-limitation",
      "quotes": [{ "text": "", "url": "" }],
      "ambiguous": false,
      "ambiguityReason": ""
    }
  ],
  "outOfScopeNotes": [""],
  "auditorNotes": "anything a reviewer should know: gaps in the docs, contradictions between sources, outdated material"
}
```

Also write `competitors/<id>.md`: a readable summary of about one page. Cover:

- what the product is;
- what the documentation covers, and how current it is;
- its strongest areas, stated neutrally;
- its documented limitations;
- the ambiguous cases.

## Working method

Read broadly before you record. Many products scatter one setting across a
help article, an API field and a release note. Read the API or data schema
if there is one, because it is usually the most complete list of what the
engine can express. For PDFs, download them to your scratchpad with curl and
read them with the Read tool (20 pages per call).

Your final reply: the number of capabilities recorded, broken down by
mechanism and evidence value; the general mechanisms found; the number of
ambiguous flags; any source you could not reach that a human should check by
hand.