Positioning and Messaging Hierarchy

The document every other piece of copy should be derived from: a positioning statement, the competitive alternative you are actually beating, three value pillars with proof, messaging per persona, and an explicit anti-positioning list of what you refuse to claim.

A Markdown messaging hierarchy containing: (1) the competitive alternative and market frame with reasoning; (2) a one-sentence positioning statement; (3) three value pillars, each with a claim, a mechanism and the specific proof required or a [PROOF NEEDED] marker; (4) messaging for each persona in the brief with trigger, objection and the line that lands; (5) a phrase bank of approved and banned language; (6) an anti-positioning section of claims you will not make and why.

# Messaging hierarchy — data-contract testing in CI

## 1. The competitive alternative
The honest alternative is **not** a competing product. It is the sequence most teams run today: ship the schema change, let dbt tests catch it on the next scheduled run, and find out from a Slack message when a dashboard breaks. The second alternative is a hand-maintained list of 'do not touch' models that nobody updates.

This matters because it sets the comparison. Against a funded competitor you would argue features. Against 'we find out later' you argue **when** you find out, which is a much easier argument and a much clearer wedge.

## 2. Unique attributes
- Reads the dbt DAG, so it knows which downstream models and dashboards a change actually breaks, rather than flagging every schema diff.
- Runs inside the pull request, before merge, rather than after the next scheduled build.
- Completes in under 40 seconds on a 4,000-model project, which is the difference between a check engineers keep and a check engineers skip.

## 3. Market frame
Not 'data quality' — that category is crowded, owned by observability vendors, and evaluated on dashboards and alerting where you would lose. Frame as **CI for the analytics layer**: the same class of tool as a type checker or a test suite, evaluated on speed, false-positive rate and developer trust. You win that comparison and the buyer already understands it.

## Positioning statement
> For analytics engineering teams running dbt at scale, this is a CI check that fails the pull request when a schema change would break something downstream — because it reads your DAG, it flags what actually breaks and stays out of the way of everything that does not.

## Value pillars

### Pillar 1 — You find out before merge, not after breakfast
**Claim:** breaking changes are caught in the pull request rather than in a dashboard.
**Mechanism:** the check runs in CI on the diff, resolving impact through the dbt DAG.
**Proof required:** [PROOF NEEDED] — from a design partner, the number of breaking changes caught pre-merge in a quarter, and how many of those previously reached production. Without this the pillar is a mechanism description, not a value claim. This is the single highest-value piece of evidence to collect.

### Pillar 2 — It flags what breaks, not what changed
**Claim:** low false-positive rate, so engineers do not learn to ignore it.
**Mechanism:** DAG-aware impact resolution distinguishes a column rename with three dependants from one with none.
**Proof required:** [PROOF NEEDED] — the ratio of flagged changes to genuinely breaking changes across the design partners. A false-positive rate is the most credible number in this category and the one a sceptical analytics engineer will ask for first.

### Pillar 3 — Fast enough that nobody turns it off
**Claim:** under 40 seconds on a 4,000-model project.
**Mechanism:** impact analysis on the diff rather than a full-project compile.
**Proof required:** supplied in the brief. State the project size alongside the number every time — '40 seconds' without '4,000 models' is unfalsifiable and will be read as marketing.

## Messaging by persona

### Analytics engineer — the daily user
- **Trigger:** they broke a dashboard with a rename and found out from the finance team.
- **Objection:** 'another CI check that will be red for reasons that do not matter'.
- **The line:** It only fails when something downstream actually breaks. If nothing depends on the column, it stays quiet.

### Head of data — the buyer
- **Trigger:** a stakeholder lost trust in a number, and rebuilding that trust is now their problem.
- **Objection:** 'we already pay for a data observability tool'.
- **The line:** Observability tells you a table is wrong once it is wrong. This stops the change that would have made it wrong. They are complements and the overlap is small.

### Platform engineer — the security reviewer
- **Trigger:** a new tool wants access to the warehouse.
- **Objection:** 'what does it read, and where does it run'.
- **The line:** It runs in your CI runner against your repository and the dbt manifest. Answer the data-access question in the first sentence of the security page, not the fifth.

## Phrase bank

**Use:** breaking change, downstream impact, pull request, fails the build, dbt DAG, false positive rate, pre-merge, analytics engineer.

**Avoid:** data quality platform (loses the frame), AI-powered (this is graph traversal and technical buyers will punish the claim), single source of truth (means nothing to this audience), enterprise-grade, seamless, revolutionise, trusted by leading teams (three design partners is not 'leading teams' and the gap will be noticed).

## Anti-positioning
- **We are not a data observability platform.** Claiming it invites a feature comparison against vendors with anomaly detection, lineage UIs and incident management, and you lose that comparison on every axis except the one you are good at.
- **We do not guarantee zero broken dashboards.** A change can break a consumer that is not in the DAG. Overclaiming here converts your first miss into a credibility event.
- **We are not a testing framework replacement.** dbt tests assert on data; this asserts on impact. Positioning as a replacement starts an argument with the tool your users already like.
- **We do not have public customers yet.** Say 'three design partners' and name the scale of their projects. [VERIFY] any comparison to competitor customer counts — that data moves and a stale claim on a sales call is expensive.