# Fact verification — search before you assume

**The highest-priority rule in this skill.** Any factual claim about a specific product, technology, event, or person — whether it exists, when it launched, its current version, its specs — must be verified via `WebSearch` as the first step. Do not make claims from training-corpus memory.

## When this rule fires

Trigger on any of:

- The user names a specific product you're not certain about (*"DJI Pocket 4"*, *"Gemini 3 Pro"*, *"some new SDK"*).
- The task involves release timelines, version numbers, or specs from 2024 onward.
- Your inner monologue starts forming phrases like:
  - *"I think that hasn't launched yet..."*
  - *"The current version is probably..."*
  - *"I believe it's around..."*
  - *"It might not exist..."*
- The user asks you to design something for a specific product or company.

## The hard flow (runs before clarifying questions)

1. **`WebSearch`** the product name + a recency term (`"2026 latest"`, `"launch date"`, `"release"`, `"specs"`).
2. **Read 1–3 authoritative results** and confirm: *existence / release status / current version / key specs*.
3. **Write the facts into `product-facts.md`** in the project — do not rely on memory across turns.
4. **If the search returns nothing or is ambiguous** → ask the user, do not assume.

## Why this is #0 priority

A real failure mode (2026-04-20): user asked for a launch animation for DJI Pocket 4. The agent said from memory: *"Pocket 4 hasn't launched yet, let's make a concept demo."* Truth: Pocket 4 had launched 4 days earlier and an official launch film + product renders were live. Cost: 1–2 hours of rework on a conceptual silhouette animation that violated the user's actual expectation.

Cost of a `WebSearch`: ~10 seconds.
Cost of a wrong assumption: 1–2 hours of rework.

**This rule sits above asking clarifying questions.** The premise for asking a good question is that you have the facts right. If the facts are wrong, every question you ask is skewed.

## Forbidden phrasings

When you catch yourself about to type these, stop and search:

- ❌ *"I think X hasn't launched yet"*
- ❌ *"X is currently at version N"* (without a search)
- ❌ *"X might not exist"*
- ❌ *"As far as I know, X's specs are..."*

Replace with:

- ✅ *"Let me `WebSearch` the current status of X."*
- ✅ *"Authoritative sources say X is ..."*

## Relationship to the Core Asset Protocol

Fact verification is the **prerequisite** for [brand-context.md](brand-context.md). Confirm what the product is before hunting for its logo, product shots, and UI. The order matters — you can't find the right assets for a phantom product.

## What `product-facts.md` should look like

A short, dated, sourced file:

```markdown
# <Product> facts
> Verified: YYYY-MM-DD
> Sources: <URLs of authoritative pages consulted>

## Existence and status
- Released: YYYY-MM-DD
- Current version: vX
- Availability: <regions / channels>

## Key specs
- <spec 1>: <value>  (source: <URL>)
- <spec 2>: <value>  (source: <URL>)

## What changed recently
- <if relevant to the design brief>
```

Short. Sourced. Dated. No prose filler.

## When you're designing for a fictional or in-development product

The user may knowingly ask you to design for something that doesn't exist publicly (a concept, a personal side project, an unreleased product they own). In that case:

1. Confirm explicitly: *"Is <product> a real shipping product, or is this for a concept / internal project?"*
2. If internal/concept, skip the search and rely on user-provided facts. Note this in `product-facts.md` as *"concept — no public sources, facts per user brief"*.
3. If real but pre-release, search anyway — there's often leaked specs, teaser footage, or official placeholder pages you can anchor on.

The search is cheap. The assumption is expensive. Err on the side of searching.