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.
|
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.
|
This is a working definition, not a final brand statement.
|
||||||
|
|
||||||
For the full business requirements, see:
|
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:
|
It includes:
|
||||||
|
|
||||||
- Customer Path Leakage — a customer has interest or intent, but digital friction prevents contact, booking, visiting, or engagement.
|
- **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.
|
- **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:
|
### Service Domains
|
||||||
docs/business-model/business-requirements.md
|
|
||||||
|
|
||||||
---
|
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
|
Agents may propose classifications; humans approve final tiers before client-facing use in Version 1.
|
||||||
Ensures customers can find, trust, contact, book, visit, or otherwise engage the business without preventable digital friction.
|
|
||||||
|
|
||||||
2. AI Visibility Integrity / AEO
|
### Operating Rule
|
||||||
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
|
|
||||||
|
|
||||||
> Agents may detect and draft. Humans approve before publish.
|
> 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:
|
Master sequence: `docs/architecture/path-to-poc-sequencing.md`
|
||||||
docs/architecture/architectural-principles.md
|
|
||||||
docs/business-model/client-lifecycle.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
|
## V1 Scope Exclusions
|
||||||
|
|
||||||
Version 1 is intentionally not a general-purpose marketing agency.
|
Out of scope for V1 unless separately quoted:
|
||||||
|
|
||||||
The following are out of scope for V1 unless separately quoted as future project work:
|
|
||||||
|
|
||||||
- Social media production
|
- Social media production
|
||||||
- Paid advertising
|
- Paid advertising
|
||||||
@@ -100,83 +105,56 @@ The following are out of scope for V1 unless separately quoted as future project
|
|||||||
- Full SEO campaigns
|
- Full SEO campaigns
|
||||||
- CRM / email marketing
|
- 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
|
## Go-To-Market Motion
|
||||||
|
|
||||||
The initial go-to-market strategy is proof-of-concept first.
|
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.
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Repository Structure
|
## Repository Structure
|
||||||
/
|
|
||||||
├── docs/
|
```
|
||||||
│ ├── vision/
|
docs/
|
||||||
│ ├── architecture/
|
vision/
|
||||||
│ ├── business-model/
|
architecture/ # Path to PoC, economics guide, principles
|
||||||
│ ├── use-cases/
|
business-model/
|
||||||
│ ├── workflows/
|
use-cases/
|
||||||
│ ├── agents/
|
templates/ # Layer templates + GBP intake
|
||||||
│ └── roadmap/
|
agents/ # Charter, playbook, execution cards
|
||||||
│
|
clients/ # Per-client instances
|
||||||
├── research/
|
workflows/
|
||||||
│ ├── competitors/
|
roadmap/
|
||||||
│ ├── pricing/
|
research/
|
||||||
│ ├── local-seo/
|
specifications/
|
||||||
│ └── market-analysis/
|
implementation/
|
||||||
│
|
tools/ # Operational forms (GBP snapshot HTML, etc.)
|
||||||
├── specifications/
|
```
|
||||||
│ ├── client-model/
|
|
||||||
│ ├── opportunity-model/
|
|
||||||
│ ├── reporting-model/
|
|
||||||
│ └── monitoring-model/
|
|
||||||
│
|
|
||||||
└── implementation/
|
|
||||||
├── onboarding/
|
|
||||||
├── discovery/
|
|
||||||
├── auditing/
|
|
||||||
├── monitoring/
|
|
||||||
├── reporting/
|
|
||||||
└── automation/
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Current Phase
|
## Current Phase
|
||||||
|
|
||||||
Phase 1: Business Definition
|
**Phase: Path-to-PoC execution + first client benchmark**
|
||||||
|
|
||||||
Resolved foundations include:
|
Resolved foundations:
|
||||||
|
|
||||||
- Mission and working definition
|
- Mission and working definition
|
||||||
- Core terminology
|
- Evidence model and operating rule
|
||||||
- Evidence model
|
- Client lifecycle and V1 exclusions
|
||||||
- Evidence assignment authority
|
- Path to PoC sequencing (7 layers)
|
||||||
- Reconnaissance-versus-execution rule
|
- Economics & pricing execution guide
|
||||||
- Client lifecycle
|
- Audit playbook + Layer templates
|
||||||
- Version 1 scope exclusions
|
- GBP cold-audit intake form + Leonard execution card
|
||||||
- Proof-before-retainer go-to-market strategy
|
- First non-Phoenix client instance (Overcome Fitness) as Draft Benchmark
|
||||||
|
|
||||||
Open work includes:
|
Open work:
|
||||||
|
|
||||||
- Economic model
|
- GBP snapshot for Overcome Fitness (human form pass) before Layer 1/2 lock
|
||||||
- Pricing validation
|
- Economics validation with real client numbers
|
||||||
- Future system architecture
|
- Leonard scored runs against the playbook
|
||||||
- Tooling and implementation planning
|
- Pricing validation and delivery packaging
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -185,7 +163,3 @@ Open work includes:
|
|||||||
Users → Problems → Requirements → Workflows → Agents → Tools
|
Users → Problems → Requirements → Workflows → Agents → Tools
|
||||||
|
|
||||||
No automation runs until the business is understood.
|
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