Update README.md with new working definition, core concepts, evidence model, operating rule, and current phase
This commit is contained in:
@@ -1,21 +1,192 @@
|
||||
# Digital Operations Partner
|
||||
|
||||
A human-supervised, agent-assisted digital growth platform for small and medium businesses.
|
||||
A human-supervised, agent-assisted digital operations service for local service businesses.
|
||||
|
||||
The platform continuously discovers, analyzes, monitors, and prioritizes opportunities that improve a business's online visibility, reputation, customer acquisition and retention. The system is designed around expert human oversight and agent scalability.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Working Definition
|
||||
|
||||
> We continuously prevent silent customer loss for local businesses by making sure customers can find, trust, and engage the business, and that search engines and AI systems can find, understand, and accurately represent it, often before the business would ever notice something was wrong.
|
||||
|
||||
This is a working definition, not a final brand statement.
|
||||
|
||||
For the full business requirements, see:
|
||||
docs/business-model/business-requirements.md
|
||||
|
||||
---
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### Silent Customer Loss
|
||||
|
||||
Silent Customer Loss is the umbrella term for customer acquisition problems that occur without the business owner clearly seeing the loss.
|
||||
|
||||
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.
|
||||
|
||||
For the full terminology, see:
|
||||
docs/business-model/business-requirements.md
|
||||
|
||||
---
|
||||
|
||||
## Service Domains
|
||||
|
||||
The current service model is organized around three domains:
|
||||
|
||||
1. Customer Path Integrity
|
||||
Ensures customers can find, trust, contact, book, visit, or otherwise engage the business without preventable digital friction.
|
||||
|
||||
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
|
||||
|
||||
> 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.
|
||||
|
||||
For the full rule, including approval gates and the graduation threshold, see:
|
||||
docs/architecture/architectural-principles.md
|
||||
docs/business-model/client-lifecycle.md
|
||||
|
||||
---
|
||||
|
||||
## 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:
|
||||
|
||||
- Social media production
|
||||
- Paid advertising
|
||||
- Website redesign
|
||||
- Branding projects
|
||||
- Content marketing
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
/
|
||||
├── docs/ — Vision, architecture, business model, use cases, workflows, agents, roadmap
|
||||
├── research/ — Competitors, pricing, local SEO, market analysis
|
||||
├── specifications/ — Data models: client, opportunity, reporting, monitoring
|
||||
└── implementation/ — Onboarding, discovery, auditing, monitoring, reporting, automation
|
||||
```
|
||||
├── 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/
|
||||
|
||||
---
|
||||
|
||||
## Current Phase
|
||||
|
||||
Phase 1: Business Definition
|
||||
|
||||
Resolved foundations include:
|
||||
|
||||
- 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
|
||||
|
||||
Open work includes:
|
||||
|
||||
- Economic model
|
||||
- Pricing validation
|
||||
- Persona additions
|
||||
- Future system architecture
|
||||
- Tooling and implementation planning
|
||||
|
||||
---
|
||||
|
||||
## Philosophy
|
||||
|
||||
**Users → Problems → Requirements → Workflows → Agents → Tools**
|
||||
Users → Problems → Requirements → Workflows → Agents → Tools
|
||||
|
||||
No automation runs until the business is understood. This repository builds from first principles: use cases drive architecture, not the other way around.
|
||||
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