diff --git a/README.md b/README.md index fd6da05..ec57b11 100644 --- a/README.md +++ b/README.md @@ -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//`. + +--- + +## 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. \ No newline at end of file