# Competitive Landscape Analysis

Maps what is observably true of each player in a segment — sourced, dated, and with what is claimed kept apart from what was checked.

## Deliverable

One Markdown document, `landscape-analysis.md`, in the structure set out under **Output** below. It takes the graded sources from **Source Evaluation & Evidence Synthesis**, and any question it cannot answer from them becomes an input to **Research Plan Design**.

## Required inputs

- **The segment to map** — stated so that a player is either inside it or outside it.
- **The dimensions that matter to the decision** — the few attributes the decision actually turns on, and who owns that decision.

Without both, stop. A landscape drawn with no decision behind it maps everything and settles nothing. Never choose the dimensions to suit the players already in view.

## Optional inputs

- The players the requester already has in view, and who named them
- Material on each player: documentation, published pricing, contracts, recordings of demonstrations
- Access to a trial or evaluation version of a player's offering
- The requester's own position on the same dimensions
- Earlier landscape work on the segment, with its date
- The date by which the map must be usable, since a landscape ages

Where no material is supplied for a player, every dimension for that player reads `unknown` and the player is marked unverified. An absent input never becomes an inference from the player's size, age or reputation.

## Execution

**1 — Fix the boundary.** Write the rule that puts a player inside the segment or outside it, and apply it before any player is examined. Record the players it excluded and the rule each one failed, so that the map can be reviewed rather than simply trusted.

**2 — Fix the dimensions.** Take them from the decision, not from whatever the available material happens to describe. Each dimension carries a stated test: what would have to be observed for a player to count as having it. A dimension with no test cannot be checked, only asserted.

**3 — Separate what is claimed from what is observed.** For each player and each dimension, record the claim as the player states it, with the source and the source's date; then record separately what was verified, with the material that verified it. The two are never merged into a single entry.

**4 — Record the gaps between claim and observation.** Where a claim was tested and not confirmed, say so and say how it was tested. Where a claim could not be tested at all, mark it `untested` rather than promoting the claim to a finding because nothing contradicted it.

**5 — Leave the unknowable unknown.** Revenue, headcount, roadmap, internal metrics and customer counts are recorded as `unknown` unless the player published them, and then only as a dated claim by that player. A landscape whose interior numbers were inferred is worse than one with blanks in it.

**6 — Date every entry.** Each line carries the date of the material it rests on and the date it was checked. State the period after which the map should be redrawn, and the events that would trigger a redraw sooner.

**7 — Write the differences that bear on the decision.** Where the players genuinely differ on the dimensions from step 2, and where they do not. A dimension on which every player is alike is reported as not discriminating, which is itself a result the decision can use.

## Output

`landscape-analysis.md`, in this order:

- **1. Segment and boundary rule** — the segment, the rule, and the date it was applied
- **2. Dimensions** — one line each: the dimension, the decision it serves, and the test for having it
- **3. Players** — one line per player: the name as the material carries it, where the name came from, and `verified` or `unverified`
- **4. Claims** — one line per player and dimension: the claim as stated, its source, and the source's date
- **5. Observations** — one line per player and dimension: what was verified, the material that verified it, and the date of the check
- **6. Gaps** — claims tested and not confirmed, and claims marked `untested`, each with how it was tested or why it could not be
- **7. Unknowns** — what was not established for each player, and what material would establish it
- **8. Differences that bear on the decision** — where the players differ, where they do not, and which dimensions did not discriminate
- **9. Expiry** — the date after which this map should be redrawn, and what would trigger a redraw sooner

## Validation

The map is ready when all of these hold:

- Every player in section 3 was admitted by the rule in section 1
- Every dimension in section 2 names the decision it serves and the test for having it
- Every entry in sections 4 and 5 carries a source and a date
- Nothing appears in section 5 without the material that verified it
- Revenue, headcount, roadmap and internal metrics appear only as `unknown` or as a dated claim by the player
- Section 9 carries a date

Fail the run if an entry carries no date, or if a player's claim has been recorded as an observation.

## Failure handling

- **No decision behind the request** — stop. Report that the dimensions cannot be chosen without one, and ask who owns the decision the map is for.
- **No material for a player** — list the player in section 3 as `unverified`, fill every dimension with `unknown`, and record in section 7 what material would change that. Do not describe a player from memory.
- **Material that cannot be reached** — record the attempt and its date, state what was blocked, and leave the entry `unknown`. Never substitute a second-hand description of the material for the material itself.
- **Sources disagree about a player** — record both in section 4 with their dates, and leave the corresponding entry in section 5 `unresolved` until one of them is verified. The more recent source is not automatically the correct one.
- **Partial coverage** — deliver the map for the players the material covers, list the rest in section 3 as `unverified`, and mark the analysis `PARTIAL — <verified> of <total> players verified`.
