Website decision register

Raw source preview

Raw, unprocessed file text shown below. Preview truncated for readability.

---
title: GTM Website - Decision Register
status: active
created: 2026-04-13
updated: 2026-04-13
purpose: Record open messaging decisions that should not be settled accidentally in implementation.
---

# <un>peel Website - Decision Register

## D-001 - Middle pillar label

**Status:** Decided for now  
**Current live default:** `Protect`

**Why it was reviewed:**  
The original `Collect` label kept the three-part rhythm neat, but it created too much risk that researchers would read the second pillar as fieldwork execution rather than fieldwork protection.

**Decision:**  
Use `Protect` in the live site because it keeps the same rhythm while making the during-fieldwork job immediately legible.

**Alternatives worth keeping for later review:**
- `Collect`
- `Verify`

**Decision trigger:**  
Review after first buyer feedback on the homepage mechanism section and switch only if a stronger label emerges from real buyer language.

---

## D-002 - When to expose the broader platform ambition publicly

**Status:** Open  
**Current live default:** Keep the public site today-biased

**Why it is open:**  
The broader long-term ambition is real: become the system of record for research, support external projects inside one container, and eventually widen access to trusted customer understanding across the business. That is strategically important, but not all of it is ready to claim publicly today.

**Current rule:**  
Do not lead with the future suite vision before the product truth can support it.

**Decision trigger:**  
Revisit when product readiness and launch timing make the broader story defensible.

---

## D-003 - Hero third-clause wording

**Status:** Decided for now  
**Current live default:** `Validate the answer`

**Why it was reviewed (round 1):**  
The previous wording, `Keep the context`, was too generic and underperformed against the first two clauses in the hero.

**Why it was reviewed (round 2):**  
`Build on what you know` was warm and human but pointed toward the accumulation/memory frame rather than the corroboration/validation frame. When the third pillar was renamed to Validate (D-012), the hero clause pointed in a different direction to the platform framework. `Validate the answer` was chosen over `Validate what you know` because "the answer" names the specific moment of pressure — a finding being challenged, a claim needing to hold up — which is the precise scenario the product addresses.

**Previous defaults:**
- `Keep the context` (original)
- `Build on what you know` (second version)

**Decision trigger:**  
Review after first buyer feedback on the hero and first-screen takeaways.

---

## D-004 - Product taxonomy in navigation and site architecture

**Status:** Decided for now  
**Current live default:** `Tools in <un>peel / Trust layer`

**Decision:**  
Use the public taxonomy:

- `Tools in <un>peel`
- `Trust layer`

**Why it was reviewed (first pass):**  
The original `Research tools / Trust layer` structure explained the proposition cleanly, but underplayed how buyers evaluate and buy the platform. The revised structure better reflects the commercial model:

- `Tools in <un>peel` = the things teams buy and use directly, explicitly inside one platform
- `Trust layer` = the differentiators that come with what they buy

**Why it was reviewed (second pass — platform-first IA pass):**  
`Research tools` implied tools were standalone peer products rather than features of one platform. `Tools in <un>peel` makes the platform relationship explicit in the group label.

**Alternatives considered:**
- `Research tools`
- `Research workflows / Quality checks / Evidence layer`
- `Research tools / Quality layer`
- `Products / Trust layer`

**Decision trigger:**  
Review after first buyer reactions to the platform-first taxonomy and route structure.

---

## D-005 - Rename `Questionnaire Reviewer`

**Status:** Decided for now  
**Current live default:** `Research Guard`

**Decision:**  
Rename the product to `Research Guard`.

**Why it was reviewed:**  
`Questionnaire Reviewer` is clear for the current use case, but it is too narrow for the broader direction of reviewing other kinds of research work over time. The replacement needed to stay trust-led, productized, and aligned with `Trust Centre`.

**Alternatives kept on record:**
- `Research Review`
- `Research QA`
- `Study Review`
- `Design Review`
- `Research Assistant` - rejected for this product because it feels too generic and too chatbot-like

**Decision trigger:**  
Review after early buyer feedback on the renamed trust-layer products.

---

## D-006 - Rename `Knowledge Base`

**Status:** Decided for now  
**Current live default:** `Insight Navigator`

**Current job to solve:**  
Name the product that acts as the system of record for customer knowledge, lets teams ask questions at project level and platform level, and will increasingly help surface corroborating evidence across studies over time.

**Why it was reviewed:**  
`Knowledge Base` is descriptively accurate but undersells the product as a buyable tool. The replacement needed to balance:

- commercial clarity
- product distinctiveness
- fit for project-level and platform-level querying
- room to grow into cross-study corroboration and evidence surfacing

**Decision:**  
Use `Insight Navigator` as the public product name because it:

- feels more like a buyable tool than `Knowledge Base`
- keeps the idea of guidance and retrieval without sounding administrative
- works for project-level and platform-level questioning
- leaves room for stronger corroboration across studies as the product matures

**Alternatives kept on record:**
- `Research Navigator` - strong option, but less directly connected to the customer-knowledge outcome
- `Knowledge Manager` - clearer on ownership, but sounds administrative and less premium
- `Research Memory` - strong strategic story, but weaker if the main interaction is asking questions
- `Evidence Navigator` - strong on rigor and traceability, but colder and less intuitive
- `Evidence Assistant` - literal, but still carries some generic AI-assistant fatigue
- `Research Assistant` - better as the in-product conversational experience than as the SKU name
- `Customer Expert` - rejected in principle; too awkward and overclaim-heavy

**Current working rule:**  
Treat `Research Assistant` as a possible interface description, not the product name, unless later user research clearly supports it.

**Decision trigger:**  
Review only after first buyer reactions to `Insight Navigator` and the updated product taxonomy.

---

## D-007 - Rename or keep `Trust layer`

**Status:** Open  
**Current live default:** `Trust layer`

**Why it is open:**  
`Trust layer` is strategically coherent, but it may read more like internal architecture language than buyer language. The current label needs testing against how insight leaders naturally describe Research Guard and Trust Centre.

**Current rule:**  
Keep `Trust layer` live for now, but treat it as a naming hypothesis rather than a locked brand asset.

**Alternatives under consideration:**
- `Built-in trust`
- `Research safeguards`
- `Trust infrastructure`
- `Quality layer`
- `Built-in quality`
- `Built-in confidence`

**Decision trigger:**  
Review after first buyer conversations and replace it if buyers consistently reach for clearer quality, safeguards, or validation language.

---

## D-008 - Tool naming and route strategy

**Status:** Decided for now  
**Current live default:** Surveys, Discussion Groups, AI Interviews at `/platform/*`

**Decision:**  
Rename tool pages to simple functional labels and move canonical routes from `/product/*` to `/platform/*`:

- `Survey Platform` → `Surveys` at `/platform/surveys`
- `Online Discussion Platform` → `Discussion Groups` at `/platform/discussion-groups`
- `AI Interviewer` → `AI Interviews` at `/platform/ai-interviews`
- `Insight Navigator` stays, moves to `/platform/insight-navigator`

Old `/product/*` routes redirect to new `/platform/*` routes.

**Why it was reviewed:**  
`Survey Platform` and `Online Discussion Platform` implied each tool was its own platform, contradicting the platform-first commercial model. `AI Interviewer` named a persona rather than a tool. The `/product/` URL prefix reinforced the wrong mental model — these are tools inside `<un>peel`, not standalone products.

**Alternatives considered:**
- Keeping "Platform" suffix in tool names
- Sub-branding all tools
- One-page platform architecture (all tools on a single page)
- Keeping `/product/` prefix with new slugs

**Note on Discussion Groups vs Discussion Boards:**  
`Discussion Groups` was chosen over `Discussion Boards` because research-buyer audiences use "groups" language (focus groups, discussion groups), not "boards" (which reads more like community/social contexts).

**Note on AI Chat → Conversational Questions:**  
The in-survey AI question feature (previously "AI Chat questions") has been renamed to "Conversational Questions" to clearly distinguish it from the standalone AI Interviews tool.

**Decision trigger:**  
Review after public launch if competitive positioning shifts or buyer language strongly favors different names.

---

## D-010 - Interview tool naming

**Status:** Decided for now
**Current live default:** `Guided Interviews` at `/platform/guided-interviews`

**Decision:**
Use `Guided Interviews` as the public tool name.

**Naming history:**
- `AI Interviewer` — original name. Named a persona rather than a tool; `/product/ai-interviewer` URL.
- `AI Interviews` — first rename (D-008). Functional but "AI" prefix risks becoming generic noise as every tool adopts AI labelling.
- `Depth Interviews` — second candidate. Borrowed the qual research IDI convention; cleaner than "AI Interviews" but felt too clinical and research-jargon-heavy.
- `Guided Interviews` — current live name. Describes the actual mechanic (researcher sets the guide, tool conducts at scale) without leaning on "AI" as the primary label. Pairs naturally with "Discussion Groups" as a second qual method.

**Alternatives kept on record:**
- `Scalable Interviews` — leads with the commercial differentiator (run many conversations without proportional researcher time); strong but slightly functional
- `Interviews` — simplest option, most consistent with "Surveys" just being "Surveys"; slightly risky as too generic without the qualifier
- `Conversations` — warmer, more natural; slightly ambiguous without context

**Legacy redirects in place:**
- `/product/ai-interviewer` → `/platform/guided-interviews`
- `/product/ai-interviews` → `/platform/guided-interviews`
- `/platform/depth-interviews` → `/platform/guided-interviews`

**Decision trigger:**
Review after first buyer reactions to the tool name, or if the product vision shifts significantly toward a more moderated/human-in-the-loop interview model that makes "Guided" ambiguous.

---

## D-009 - Solution framework rename: Design → Protect → Strengthen

**Status:** Decided  
**Previous framework:** Refine → Protect → Surface  
**Interim framework:** Design → Protect → Compound  
**Current live framework:** Design → Protect → Strengthen

**Decision:**  
Replace the three-pillar solution framework across the homepage Solution section, the `/platform` overview page, and all source docs.

- `Refine` → `Design` — covers Research Architect + Research Guard. "Refine" implied improving something that already exists; Research Architect builds context from scratch. "Design" covers both tools — both are about designing better research at different moments before fieldwork.
- `Protect` — unchanged. Covers the execution tools (Surveys, Discussion Groups, AI Interviews, Panel) + Trust Centre running alongside them.
- `Surface` → `Compound` → `Strengthen` — covers Insight Navigator. `Compound` captured the accumulation effect over time, but it left the buyer value too abstract. `Strengthen` better expresses the public outcome: connected studies and methods make t