Port develop->main: value-creation-model.md with Evidence Tiers + Assignment Authority
This commit is contained in:
@@ -0,0 +1,94 @@
|
||||
# Value Creation Model
|
||||
|
||||
## Purpose
|
||||
|
||||
Explain how the company creates measurable or directional value for local service businesses.
|
||||
|
||||
## Core Value Thesis
|
||||
|
||||
The company creates value by reducing Silent Customer Loss through continuous monitoring, diagnosis, prioritization, and approved low-risk optimization of digital pathways that affect discovery, trust, and customer action.
|
||||
|
||||
## Value Categories
|
||||
|
||||
### Customer Path Leakage
|
||||
|
||||
Customer Path Leakage occurs when a customer has interest or intent but fails to contact, book, visit, or otherwise engage the business because of digital friction.
|
||||
|
||||
This category often produces **verified evidence** because the issue can be tied to a concrete defect, timestamp, platform state, or measurable artifact.
|
||||
|
||||
### Discovery Failure
|
||||
|
||||
Discovery Failure occurs when a potential customer never meaningfully encounters the business because customers, search engines, or AI systems do not find, understand, surface, or accurately represent it.
|
||||
|
||||
This category often produces **indicative evidence** because absence or weak representation in search or AI-assisted discovery can be sampled and demonstrated, but not always proven as a direct lost customer.
|
||||
|
||||
## Evidence Tiers
|
||||
|
||||
### Tier 1: Verified Evidence
|
||||
|
||||
Verified Evidence is based on concrete, timestamped, observable, or instrument-backed findings.
|
||||
|
||||
**Examples:**
|
||||
- Wrong phone number
|
||||
- Incorrect business hours
|
||||
- Broken booking link
|
||||
- Broken contact form
|
||||
- Incorrect listing data
|
||||
- Indexing problem
|
||||
- Metadata problem
|
||||
- Canonical tag issue
|
||||
- Missing or incorrect Google Business Profile information
|
||||
|
||||
**Reporting standard:**
|
||||
|
||||
Verified Evidence may be presented as a confirmed issue.
|
||||
|
||||
### Tier 2: Indicative Evidence
|
||||
|
||||
Indicative Evidence is based on sampled, directional, or probabilistic findings that suggest risk or opportunity but do not prove direct customer loss.
|
||||
|
||||
**Examples:**
|
||||
- AI answer absence
|
||||
- AI misrepresentation
|
||||
- Weak entity clarity
|
||||
- Inconsistent service descriptions
|
||||
- Thin FAQ coverage
|
||||
- Missing structured data
|
||||
- Competitors appearing more consistently in AI answer samples
|
||||
- Weak local discovery signals
|
||||
|
||||
**Reporting standard:**
|
||||
|
||||
Indicative Evidence must be presented as directional risk or opportunity, not as confirmed customer loss.
|
||||
|
||||
## Reporting Principle
|
||||
|
||||
Reports must distinguish between confirmed issues and directional risks.
|
||||
|
||||
The company should not overstate indicative findings as proven customer loss.
|
||||
|
||||
## Before/After Proof
|
||||
|
||||
Customer Path Leakage may support stronger before/after proof.
|
||||
|
||||
Discovery Failure may support directional before/after comparison, but should be labeled as sampled or indicative when appropriate.
|
||||
|
||||
# Evidence Tier Assignment Authority
|
||||
|
||||
Agents may propose an evidence tier for a finding, but the final evidence tier used in any client-facing report must be approved by a human reviewer during Version 1.
|
||||
|
||||
A finding may only be classified as Verified Evidence when it is supported by concrete, current, observable, timestamped, or instrument-backed evidence.
|
||||
|
||||
If a finding does not clearly meet the standard for Verified Evidence, it defaults to Indicative Evidence until a human reviewer confirms otherwise.
|
||||
|
||||
Ambiguous findings must not be presented as confirmed customer loss.
|
||||
|
||||
If an agent proposes a finding as Verified Evidence and the human reviewer rejects that classification, the finding defaults to Indicative Evidence unless the reviewer discards the finding entirely or requests additional evidence.
|
||||
|
||||
**Examples:**
|
||||
|
||||
- A currently visible wrong phone number on a verified business profile may qualify as Verified Evidence.
|
||||
- A broken booking link observed and timestamped during review may qualify as Verified Evidence.
|
||||
- A stale or unconfirmed citation mismatch defaults to Indicative Evidence until confirmed.
|
||||
- Absence from sampled AI answers is Indicative Evidence.
|
||||
- Agent-reported findings without supporting artifacts are not sufficient for Verified Evidence.
|
||||
Reference in New Issue
Block a user