Refresh root README: current phase, Path to PoC, clients, templates, playbook, GBP tools
This commit is contained in:
@@ -2,9 +2,9 @@
|
||||
|
||||
A human-supervised, agent-assisted digital operations service for local service businesses.
|
||||
|
||||
This project exists to prevent silent customer loss by making sure customers can find, trust, and engage a business, and that search engines and AI systems can find, understand, and accurately represent it, often before the business would notice something was wrong.
|
||||
This project exists to prevent silent customer loss by making sure customers can find, trust, and engage a business, and that search engines and AI systems can find, understand, and accurately represent it — often before the business would notice something was wrong.
|
||||
|
||||
This repository defines the business foundation, operating model, evidence standards, client lifecycle, and future system architecture for a Digital Operations Partner service.
|
||||
This repository defines the business foundation, operating model, evidence standards, client lifecycle, Path to PoC sequencing, and tooling for a Digital Operations Partner service.
|
||||
|
||||
---
|
||||
|
||||
@@ -15,7 +15,7 @@ This repository defines the business foundation, operating model, evidence stand
|
||||
This is a working definition, not a final brand statement.
|
||||
|
||||
For the full business requirements, see:
|
||||
docs/business-model/business-requirements.md
|
||||
`docs/business-model/business-requirements.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -27,70 +27,75 @@ Silent Customer Loss is the umbrella term for customer acquisition problems that
|
||||
|
||||
It includes:
|
||||
|
||||
- Customer Path Leakage — a customer has interest or intent, but digital friction prevents contact, booking, visiting, or engagement.
|
||||
- Discovery Failure — a potential customer never meaningfully encounters the business because customers, search engines, or AI systems do not find, understand, surface, or accurately represent it.
|
||||
- **Customer Path Leakage** — a customer has interest or intent, but digital friction prevents contact, booking, visiting, or engagement.
|
||||
- **Discovery Failure** — a potential customer never meaningfully encounters the business because customers, search engines, or AI systems do not find, understand, surface, or accurately represent it.
|
||||
|
||||
For the full terminology, see:
|
||||
docs/business-model/business-requirements.md
|
||||
### Service Domains
|
||||
|
||||
---
|
||||
1. **Customer Path Integrity** — customers can find, trust, contact, book, visit, or otherwise engage without preventable digital friction.
|
||||
2. **AI Visibility Integrity / AEO** — search engines and AI systems can find, understand, and accurately represent the business.
|
||||
3. **Local Competitive Awareness** — local market context via competitor visibility, positioning, review movement, and AI-answer comparison.
|
||||
|
||||
## Service Domains
|
||||
### Evidence Model
|
||||
|
||||
The current service model is organized around three domains:
|
||||
- **Tier 1: Verified Evidence** — concrete, timestamped, observable, or instrument-backed findings.
|
||||
- **Tier 2: Indicative Evidence** — sampled, directional, probabilistic, or risk-based findings.
|
||||
|
||||
1. Customer Path Integrity
|
||||
Ensures customers can find, trust, contact, book, visit, or otherwise engage the business without preventable digital friction.
|
||||
Agents may propose classifications; humans approve final tiers before client-facing use in Version 1.
|
||||
|
||||
2. AI Visibility Integrity / AEO
|
||||
Improves whether search engines and AI systems can find, understand, and accurately represent the business. This does not guarantee placement, ranking, citation, or recommendation by any AI system.
|
||||
|
||||
3. Local Competitive Awareness
|
||||
Provides local market context by monitoring competitor visibility, positioning, review movement, and AI-answer comparison. This is a built-in capability for every client relationship, not a standalone SKU — depth and frequency vary by tier.
|
||||
|
||||
For full scope details, see:
|
||||
docs/business-model/business-requirements.md
|
||||
|
||||
---
|
||||
|
||||
## Evidence Model
|
||||
|
||||
The project uses a two-tier evidence model:
|
||||
|
||||
- Tier 1: Verified Evidence — concrete, timestamped, observable, or instrument-backed findings.
|
||||
- Tier 2: Indicative Evidence — sampled, directional, probabilistic, or risk-based findings.
|
||||
|
||||
Agents may propose evidence classifications, but human reviewers approve final evidence tiers before client-facing use during Version 1.
|
||||
|
||||
Ambiguous findings default to Indicative Evidence. Rejected Tier 1 classifications default to Tier 2 unless the reviewer discards the finding or requests more evidence.
|
||||
|
||||
For the authoritative evidence rules, see:
|
||||
docs/business-model/value-creation-model.md
|
||||
|
||||
For the governing architectural principle, see:
|
||||
docs/architecture/architectural-principles.md
|
||||
|
||||
---
|
||||
|
||||
## Operating Rule
|
||||
### Operating Rule
|
||||
|
||||
> Agents may detect and draft. Humans approve before publish.
|
||||
|
||||
This applies to any action that publishes to a client-facing surface.
|
||||
---
|
||||
|
||||
During Version 1, this approval gate remains in place unless a specific task type completes a documented reliability run of at least 100 tasks with zero errors for that exact task type.
|
||||
## Path to PoC (Governing Sequence)
|
||||
|
||||
For the full rule, including approval gates and the graduation threshold, see:
|
||||
docs/architecture/architectural-principles.md
|
||||
docs/business-model/client-lifecycle.md
|
||||
Master sequence: `docs/architecture/path-to-poc-sequencing.md`
|
||||
|
||||
Layers (fixed order):
|
||||
|
||||
1. Account Intelligence (Data Inventory)
|
||||
2. Threat Diagnosis (Threat Register)
|
||||
3. Economics & Pricing Validation
|
||||
4. Requirements
|
||||
5. Workflows
|
||||
6. Agent Build & Test
|
||||
7. POC Delivery
|
||||
|
||||
Client artifacts live under `docs/clients/<client-name>/`.
|
||||
|
||||
---
|
||||
|
||||
## Agent & Audit Tooling
|
||||
|
||||
| Doc / Tool | Path |
|
||||
|------------|------|
|
||||
| Agent Charter | `docs/agents/agent-charter-v1.md` |
|
||||
| Audit Playbook | `docs/agents/audit-playbook-v1.md` |
|
||||
| Leonard GBP Execution Card | `docs/agents/leonard-gbp-execution-card.md` |
|
||||
| GBP Snapshot Intake (markdown) | `docs/templates/gbp-snapshot-intake.md` |
|
||||
| GBP Snapshot Form (HTML) | `tools/gbp-snapshot-form.html` |
|
||||
| Data Inventory template | `docs/templates/data-inventory-template.md` |
|
||||
| Threat Register template | `docs/templates/threat-register-template.md` |
|
||||
| Requirements template | `docs/templates/requirements-template.md` |
|
||||
| Workflows template | `docs/templates/workflows-template.md` |
|
||||
|
||||
**Cold audit GBP workflow:** open `tools/gbp-snapshot-form.html` → fill → generate → paste to Leonard with the execution card instruction.
|
||||
|
||||
---
|
||||
|
||||
## Active Client Instances
|
||||
|
||||
| Client | Status | Path |
|
||||
|--------|--------|------|
|
||||
| Overcome Fitness | Draft Benchmark (Layers 1–2 in progress; GBP still open) | `docs/clients/overcome-fitness/` |
|
||||
|
||||
---
|
||||
|
||||
## V1 Scope Exclusions
|
||||
|
||||
Version 1 is intentionally not a general-purpose marketing agency.
|
||||
|
||||
The following are out of scope for V1 unless separately quoted as future project work:
|
||||
Out of scope for V1 unless separately quoted:
|
||||
|
||||
- Social media production
|
||||
- Paid advertising
|
||||
@@ -100,83 +105,56 @@ The following are out of scope for V1 unless separately quoted as future project
|
||||
- Full SEO campaigns
|
||||
- CRM / email marketing
|
||||
|
||||
These exclusions protect the business from scope creep and keep the service focused on digital operations oversight, evidence-backed recommendations, and approved low-risk optimization.
|
||||
|
||||
---
|
||||
|
||||
## Go-To-Market Motion
|
||||
|
||||
The initial go-to-market strategy is proof-of-concept first.
|
||||
|
||||
The business demonstrates value through a focused initial assessment, evidence-backed findings, a low-risk proof-of-concept fix when appropriate, and a before/after report. The retainer offer follows demonstrated value rather than leading with a cold subscription pitch.
|
||||
|
||||
The business competes on local proof, trust, and relationship-driven referrals — not on being the cheapest SEO, GEO, or AEO provider.
|
||||
|
||||
For the full lifecycle, see:
|
||||
docs/business-model/client-lifecycle.md
|
||||
|
||||
---
|
||||
|
||||
## Use Case Personas
|
||||
|
||||
Representative business personas are maintained in docs/use-cases/. This directory is actively evolving as Version 1 vertical priorities are validated — check recent commits before assuming any given persona reflects current scope decisions.
|
||||
Proof-of-concept first. Demonstrate value through focused assessment, evidence-backed findings, a low-risk PoC fix when appropriate, and a before/after report. Retainer follows demonstrated value.
|
||||
|
||||
---
|
||||
|
||||
## Repository Structure
|
||||
/
|
||||
├── docs/
|
||||
│ ├── vision/
|
||||
│ ├── architecture/
|
||||
│ ├── business-model/
|
||||
│ ├── use-cases/
|
||||
│ ├── workflows/
|
||||
│ ├── agents/
|
||||
│ └── roadmap/
|
||||
│
|
||||
├── research/
|
||||
│ ├── competitors/
|
||||
│ ├── pricing/
|
||||
│ ├── local-seo/
|
||||
│ └── market-analysis/
|
||||
│
|
||||
├── specifications/
|
||||
│ ├── client-model/
|
||||
│ ├── opportunity-model/
|
||||
│ ├── reporting-model/
|
||||
│ └── monitoring-model/
|
||||
│
|
||||
└── implementation/
|
||||
├── onboarding/
|
||||
├── discovery/
|
||||
├── auditing/
|
||||
├── monitoring/
|
||||
├── reporting/
|
||||
└── automation/
|
||||
|
||||
```
|
||||
docs/
|
||||
vision/
|
||||
architecture/ # Path to PoC, economics guide, principles
|
||||
business-model/
|
||||
use-cases/
|
||||
templates/ # Layer templates + GBP intake
|
||||
agents/ # Charter, playbook, execution cards
|
||||
clients/ # Per-client instances
|
||||
workflows/
|
||||
roadmap/
|
||||
research/
|
||||
specifications/
|
||||
implementation/
|
||||
tools/ # Operational forms (GBP snapshot HTML, etc.)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Current Phase
|
||||
|
||||
Phase 1: Business Definition
|
||||
**Phase: Path-to-PoC execution + first client benchmark**
|
||||
|
||||
Resolved foundations include:
|
||||
Resolved foundations:
|
||||
|
||||
- Mission and working definition
|
||||
- Core terminology
|
||||
- Evidence model
|
||||
- Evidence assignment authority
|
||||
- Reconnaissance-versus-execution rule
|
||||
- Client lifecycle
|
||||
- Version 1 scope exclusions
|
||||
- Proof-before-retainer go-to-market strategy
|
||||
- Evidence model and operating rule
|
||||
- Client lifecycle and V1 exclusions
|
||||
- Path to PoC sequencing (7 layers)
|
||||
- Economics & pricing execution guide
|
||||
- Audit playbook + Layer templates
|
||||
- GBP cold-audit intake form + Leonard execution card
|
||||
- First non-Phoenix client instance (Overcome Fitness) as Draft Benchmark
|
||||
|
||||
Open work includes:
|
||||
Open work:
|
||||
|
||||
- Economic model
|
||||
- Pricing validation
|
||||
- Future system architecture
|
||||
- Tooling and implementation planning
|
||||
- GBP snapshot for Overcome Fitness (human form pass) before Layer 1/2 lock
|
||||
- Economics validation with real client numbers
|
||||
- Leonard scored runs against the playbook
|
||||
- Pricing validation and delivery packaging
|
||||
|
||||
---
|
||||
|
||||
@@ -185,7 +163,3 @@ Open work includes:
|
||||
Users → Problems → Requirements → Workflows → Agents → Tools
|
||||
|
||||
No automation runs until the business is understood.
|
||||
|
||||
This repository builds from first principles. Use cases drive architecture. Business requirements drive workflows. Workflows drive agents. Agents drive tool selection.
|
||||
|
||||
The project is intentionally not starting with tools, APIs, automations, or implementation code.
|
||||
Reference in New Issue
Block a user