# AI search content brief

Blank template and completed fictional example

Use the blank template for your own work and the completed fictional example to see how to record decisions, evidence and unresolved fields. Replace the example details before sharing. This manual file does not collect data or approve conclusions.

Pack version 1.0 · 14 September 2026. Template version 1.0.

Guide: https://rankecho.io/templates/ai-search-content-brief

## Part 1 — Blank template

# AI search content brief

Manual template — version 1.0. Complete the required fields and delete the instructions before handoff. The brief makes decisions and evidence reviewable; it does not predict a ranking, AI appearance, citation, visit, or sale.

## 1. Brief control
- Brief title [required]:
- Status: Draft / In review / Approved / Published / Superseded
- Canonical page URL [required]:
- New page or refresh [required]:
- Page type: Guide / Product / Pricing / Comparison / Use case / Support / Other
- Brief owner [real name required]:
- Writer [real name or TBD]:
- Subject-matter reviewer [real name or TBD]:
- Editorial reviewer [real name or TBD]:
- Product, legal, security, or compliance reviewer [name, not required, or TBD]:
- Target publication date:
- Brief version and last update:

## 2. Reader, job, and intent
- Primary audience [required]:
- Situation or trigger:
- Decision or task the page must help complete [required]:
- Primary query [required]:
- Natural conversational question [required]:
- Related questions:
- Market and language [required]:
- Buyer stage:

## 3. Search and source context
- Review date and conditions:
- Queries sampled:
- Representative result URLs:
- Representative sources visible in sampled AI answers, if checked:
- What readers need immediately [required]:
- What existing results answer well:
- What is missing, unclear, unsupported, or hard to use:
- Sample limits: qualitative review only; not search volume, difficulty, market share, or a selection explanation

## 4. Ownership and differentiation
- Existing canonical owner:
- Neighboring owner → distinct job:
- Why this page deserves a separate URL [required]:
- Questions handled elsewhere → owner URL:
- Pages to consolidate instead of duplicating:

## 5. Reader outcome
- Direct answer the page owes [required]:
- Publicly useful artifact or result [required]:
- Information advantage: original example / tested method / first-party evidence / useful synthesis / other
- Explicit non-goals and unsupported claims to exclude:

## 6. Buyer-question map
| Buyer question | Section | Answer required | Evidence required | Source | Reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- |
| [Question] | [H2] | [Specific answer] | [Fact, method, example, or none] | [Exact URL or pointer] | [Name or TBD] | Open |

## 7. Claim, source, and freshness register
| Exact proposed claim | Type | Source | What it supports and does not support | Checked | Freshness owner and trigger | Named reviewer | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Claim] | First-party fact / external fact / inference / example | [Exact source] | [Scope and limit] | [YYYY-MM-DD] | [Owner + event/date] | [Name or TBD] | Verified / Needs source / Revise / Remove / Synthetic-only |

Rules:
- A URL alone is not a review; record its support and limits.
- Keep as-of dates beside changing prices, features, policies, and comparisons.
- Do not publish Needs source, Remove, or Synthetic-only material as real fact.
- A role placeholder is not completed approval. Record a real reviewer or leave TBD.

## 8. Page plan
- Opening answer:
- Title:
- H1:
- Meta description:
- Canonical:
- Section → question → answer → claim/source IDs → artifact:
- Internal links: parent hub / previous task / next task / evidence / honest product destination
- Applicable structured data: only if it matches visible content; no special AI schema claim
- Conversion handoff: label / destination / eligibility / what it does / what it does not do

## 9. Delivery and review
- Primary answer and artifact in accessible public HTML: Yes / No
- Canonical, status, robots, sitemap, and index policy checked: Yes / No
- Title, H1, description, visible copy, and applicable schema agree: Yes / No
- Mobile and keyboard use checked: Yes / No
- Material claims verified by actual named owners: Yes / No
- Unsupported material removed or visibly unresolved: Yes / No
- Final URL, body version, reviewers, and UTC ship time recorded: Yes / No

## 10. Measurement and decision
- Baseline, window, units, denominators, exclusions, and concurrent changes:
- Traditional search discovery:
- Provider-native AI reporting, with each provider's unit kept separate:
- Fixed prompt-and-surface observations, including unavailable and failed checks:
- Identifiable AI referrals and landing pages:
- On-site task use and key events:
- Commercial outcomes only where a reliable join and attribution rule exist:
- Decision: Keep / Improve / Consolidate / Retire / Investigate product friction
- Interpretation: observed after publication / attributable / assisted / unknown

## Unresolved gaps and publication decision
| Gap | Owner | Resolution needed | Status |
| --- | --- | --- | --- |
| [Gap or none after review] | [Name/role] | [Source, decision, test, or approval] | Open / Resolved |

Publication decision: Ready / Not ready
Decision owner [actual person]:
Decision date:
Reason:

## Part 2 — Completed fictional example

### What does a completed SaaS brief look like?

This filled example uses Harborline Cloud, an imaginary B2B SaaS company, and a proposed customer-onboarding analytics guide. The company, page, facts, records, roles, and approvals are synthetic. They are not customer data, market evidence, or publishable product copy.

The record is structurally complete but ends Not ready. It records that no live result review was run, blocks an unsupported setup-time claim, removes an outcome claim, and leaves actual reviewers to be named. A completed field set is not a fabricated approval.

| Example field | Synthetic entry | Review result |
| --- | --- | --- |
| Reader and task | Growth lead at fictional Harborline Cloud choosing a customer-onboarding analytics workflow | Complete for demonstration |
| Canonical page | /resources/customer-onboarding-analytics owns category fit and evaluation | Fictional path |
| Question map | Definition, team fit, data inputs, setup, limitations, and next step | Complete; facts still need evidence |
| Claims | Connector scope, access model, plan eligibility, setup time, and customer outcome | Three Synthetic-only; setup time Needs source; outcome Remove |
| Reviewers | Writer, product owner, security owner, editor, and legal reviewer | All remain TBD |
| Publication decision | Not ready | No real sources, live page, or named approvals |

### How are the synthetic example questions and claims filled?

The excerpt below fills the production fields rather than treating a company name as a completed example. Harborline Cloud and every path, product fact, source pointer, role, and decision remain fictional. Synthetic-only and unresolved claims cannot move into publishable copy.

| Filled field | Synthetic entry | Publication state |
| --- | --- | --- |
| Page plan | Title: Customer Onboarding Analytics for B2B SaaS; H1: Customer onboarding analytics for B2B SaaS teams; canonical: /resources/customer-onboarding-analytics; opening answer defines the workflow, fit, inputs, limits, and evaluation step | Structure complete; factual review required |
| Buyer question Q01 | What should a B2B SaaS team connect to investigate onboarding? → section: Which records belong in the workflow? → answer: product events, account records, and support milestones → evidence: current connector and data-model documentation | Needs real sources and product reviewer |
| Buyer question Q02 | When is this workflow a poor fit? → section: Who should not use this approach? → answer: teams without stable account identifiers or an approved join policy need prerequisite work first → evidence: implementation and privacy requirements | Needs real sources, security review, and legal review where required |
| Buyer question Q03 | What happens after evaluation? → section: How should the team test fit? → answer: use a documented sample-data review before connecting production records → evidence: implementation guide and verified demo destination | Needs real destination and eligibility review |
| Claim C01 | Harborline Cloud connects product events, account records, and support milestones → fictional source: harborline.example/docs/connectors → source would support only the named connector scope; checked 2026-09-07; freshness trigger: connector change | Synthetic-only; product reviewer to be named |
| Claim C02 | A team can complete setup in one business day → no method, eligible population, or implementation record supplied | Needs source; exclude from draft |
| Claim C03 | The workflow improves customer retention → no study, counterfactual, denominator, or attribution method supplied | Remove |
| Conversion handoff | CTA: Review a sample workspace → fictional /demo destination → intended to show a sample only; it does not connect data, promise access, or establish fit | Destination and eligibility review required |
| Publication decision | Not ready — real sources, live-page checks, and actual named reviewers are absent | Blocked until every required review is recorded |

## Use this pack

1. Save a copy and complete Part 1 with your own records.
2. Use Part 2 as a teaching example, preserving missing data and unresolved review states.
3. Check sources, comparisons and approvals before sharing your completed version.

Next workflow: [Explore the Fix Engine](https://rankecho.io/product/fix-engine).