Tony_tech/veripath
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Delete docs/product-idea-review.md

Browse Source 
Ty- deleting as it’s superseded by a vision doc
This commit is contained in:
Ty
2026-07-26 06:29:45 +00:00
parent 2e59c51e8b
commit 0714a3461d
1 changed files with 0 additions and 410 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/product-idea-review.md
-410
View File
@@ -1,410 +0,0 @@
# Product Idea Review: Digital Operations Partner
**Date**: 2026-07-24 (Rev 1.0) / 2026-07-25 (Rev 2.0) / 2026-07-25 (Rev 2.1–2.3)
**Status**: Phase 1 – Business Definition
**Reviewer context**: External strategic review based on current repository documentation and extended concept exploration.
**Revision 2.0 notes** (major): Expanded multi-surface listing coverage; introduced AI-mediated go-to-market and public Business Assessment AI; added tiered commercial packaging; added current delegated-access feasibility analysis.
**Revision 2.1 notes** (minor): Added Technical Research section with structured analysis of the Agent-to-Agent (A2A) protocol.
**Revision 2.2 notes** (minor): Added corrected Model Context Protocol (MCP) research analysis under Technical Research, including Shopify Storefront MCP reality and the gap between live MCP servers and transparent major-LLM usage.
**Revision 2.3 notes** (minor): Added Section 13 — Corpus of States for Trustworthy AI Discovery and Interaction — placed after protocol research. Cross-references §4 (listing surfaces) and §12 (protocols) so the corpus is a unifying inventory, not a restatement.
---
## 1. Executive Summary
Digital Operations Partner is a human-supervised, agent-assisted service that continuously monitors and protects local service businesses from **silent customer loss**. It focuses on three domains:
1. Customer Path Integrity
2. AI Visibility Integrity / AEO
3. Local Competitive Awareness
The concept remains unusually disciplined. The problem is real, the scope is deliberately narrow, the evidence model is clear, and the operating rule (“Agents may detect and draft. Humans approve before publish.”) is sound.
**Overall assessment (Rev 2.0)**: Strong strategic foundation. The highest-leverage evolution is to make the company the trusted answer that AIs return when local business owners ask how to become more discoverable and interactive for chatbots and AI systems. A public, anonymous multi-surface Business Assessment AI becomes the scalable front door; the human-supervised, proof-first delivery model remains the core service.
No major pivot is required. Execution discipline and sequenced capability building remain the critical path.
---
## 2. Where the Idea Meets the Mark
### 2.1 Clear, underserved problem
Silent customer loss (Customer Path Leakage + Discovery Failure) is a genuine and growing issue. Most owners do not systematically monitor the digital pathways that feed them customers, and AI-mediated discovery adds a new layer of risk they are poorly equipped to handle.
### 2.2 Disciplined scope
Version 1 correctly excludes social media production, paid advertising, website redesign, branding, content marketing, full SEO campaigns, and CRM/email marketing.
### 2.3 Evidence model
The two-tier evidence system (Verified vs Indicative) with human approval of final classifications is a meaningful differentiator.
### 2.4 Operating rule
“Agents may detect and draft. Humans approve before publish,” plus the 100-task zero-error graduation rule, is excellent risk management.
### 2.5 Proof-before-retainer motion
Leading with focused assessment → evidence → optional low-risk Proof-of-Concept → before/after report remains the right commercial posture.
### 2.6 Human-in-the-loop philosophy
Rejecting black-box automation aligns with both risk control and local-business trust realities.
### 2.7 Target cohort clarity
Personas (salon, plumber, med spa, roofer, gym) and emphasis on owner-operated or small-team local service businesses are well chosen.
### 2.8 Strategic GTM opportunity (new in Rev 2.0)
Becoming the practical answer that Grok, Gemini, ChatGPT and similar systems give when an owner asks “How do I make my business more discoverable / AI-ready / interactive for chatbots?” creates a powerful, defensible acquisition channel. The company must itself be a strong example of the visibility it sells (“be your own best customer”).
---
## 3. Key Risks
### 3.1 Manual handoff creates adoption friction (High)
Time-poor, lower-digital-maturity owners will delay or abandon recommendations they must implement themselves, especially on legacy websites. This remains the largest early retention risk.
### 3.2 Delegated access is required for true correction loops (High)
Without authorized access, the service stays largely diagnostic. Feasibility varies sharply by platform (see Section 5).
### 3.3 Website correction across CMSs is operationally hard (High)
Automated editing across WordPress, Wix, Squarespace, Weebly and legacy platforms is not realistic for Version 1.
### 3.4 High-touch delivery still constrains scale (Medium–High)
Human review capacity remains a ceiling. The new public assessment layer raises the top of the funnel but does not remove the delivery constraint.
### 3.5 Public assessment quality risk (new – High)
If the anonymous Business Assessment AI produces weak, generic, or inaccurate findings, it will damage both owner trust and the “AIs recommend us” strategy.
### 3.6 Expectation mismatch across tiers (new – Medium)
DIY buyers, moderate-plan buyers, and full-retainer clients will have different expectations. Boundaries must be explicit.
### 3.7 Scope-creep pressure (Medium)
Clients who experience value will ask for website work, content, and advertising. Discipline must hold.
### 3.8 AI Visibility messaging can still feel abstract (Medium)
Many owners still think primarily in “more calls and bookings.” Positioning must keep silent customer loss primary and AI Visibility secondary in early sales conversations.
---
## 4. Multi-Surface Listing Reality
The service must treat the following as first-class surfaces for both detection and (where feasible) correction:
| Surface | Primary Role | Typical Leverage |
|---------|--------------|------------------|
| Google Business Profile | Maps, search, AI training data | Highest for most U.S. local service businesses |
| Apple Business Connect / Apple Maps | iPhone / Apple ecosystem discovery | High and often under-managed |
| Bing Places | Microsoft ecosystem + some AI surfaces | Moderate |
| Yelp | Reputation + discovery in certain verticals/geographies | Variable but still meaningful |
| Other major citations | Consistency layer | Important for NAP integrity |
Detection and diagnosis should be multi-surface from the start. Automated or semi-automated correction should be sequenced by feasibility (see next section).
---
## 5. Delegated Access Feasibility (Current Reality)
| Platform | Read (public / API) | Delegated Write / Manage | Practical Difficulty for a new service |
|----------|---------------------|---------------------------|---------------------------------------|
| **Google Business Profile** | Strong | Strong via OAuth 2.0 | Medium – Cloud project, OAuth verification, Google API access approval required |
| **Apple Business** | Moderate | Available via partner API + OAuth | Higher – formal partner / trusted-partner process |
| **Bing Places** | Moderate | Weak / limited | High – little reliable third-party write access |
| **Yelp** | Strong (public read) | Restricted to contracted partners | High for write access |
**Implications**
- Google Business Profile is the clear first target for real delegated access and approved auto-correction.
- Apple is the next most realistic once partner processes are completed.
- Bing and Yelp are primarily detection + consistency surfaces in the near term.
- The public Business Assessment AI can already operate across all surfaces using only publicly visible data. Delegated access is required only when the service needs to make changes on the client’s behalf.
- Recommended sequence: public anonymous diagnosis → Google OAuth for highest-leverage corrections → expand later.
---
## 6. Go-to-Market Evolution (Rev 2.0)
### 6.1 Long-term acquisition goal
Become the trusted, concrete answer that major AI systems return when local business owners ask how to improve discoverability and interactivity for chatbots and AI systems.
### 6.2 Public Business Assessment AI (front door)
- Lives on the company website.
- No login, no delegated access.
- Accepts a business name + location or website URL.
- Scans publicly visible Google Business Profile, Bing, Apple, Yelp, and the website.
- Returns a clear, non-technical readout of current positioning and concrete improvement opportunities.
- Frames findings in the language of silent customer loss and AI misunderstanding.
- Serves as both lead tool and live demonstration of competence.
### 6.3 Commercial packaging
| Tier | What the owner receives | Nature |
|------|-------------------------|--------|
| **DIY / Discount** | Full output of the public Business Assessment AI + self-serve recommendations | Pure self-serve |
| **Moderate** | Assessment + limited hours with a human (guidance, prioritization, light implementation help) | Hybrid |
| **Full Retainer** | Ongoing multi-surface monitoring + approved low-risk optimization | High-touch, managed |
This creates a natural progression while protecting the high-touch core.
### 6.4 Relationship to high-touch delivery
The public assessment and AI-recommendation strategy raise the top of the funnel. The human-supervised Proof-of-Concept and retainer remain the delivery model. High-touch is no longer only a constraint; it is the trusted backend behind a more scalable front door.
---
## 7. Recommendations for MVP (Version 1)
1. **Build the public Business Assessment AI early** as a GTM asset (anonymous, multi-surface, high signal quality).
2. **Make multi-surface detection the default** (Google, Apple, Bing, Yelp, website, key citations).
3. **Prioritize Google Business Profile for the first real delegated-access and correction capability**.
4. **Keep website work diagnostic** in MVP; offer any generated clean alternative site only as a separately quoted project.
5. **Keep assessments short and decision-oriented**.
6. **Set expectations explicitly** across DIY, Moderate, and Retainer tiers.
7. **Lead messaging with silent customer loss / Customer Path Integrity**; treat AI Visibility as an important secondary layer.
8. **Protect the human approval gate**; graduate task types only after documented reliability.
---
## 8. Guidance for Later Stages
- Expand delegated access deliberately (Google first, then Apple partner process, then evaluate Bing/Yelp write paths).
- Introduce tiered website handling (modern platforms vs legacy).
- Keep generated alternative sites as a distinct, quoted offering.
- Raise clients-per-reviewer ceiling through reliable low-touch corrections on high-leverage surfaces.
- Continuously improve public content and the Assessment AI so that major AI systems increasingly recommend the company.
---
## 9. Suggested Success KPIs
**Acquisition & GTM**
- Qualified conversations / Assessment completions
- Source mix (AI referral vs other)
- DIY → Moderate and Moderate → Retainer conversion rates
**Conversion**
- PoC / Moderate → Full Retainer conversion
- Time to decision
**Client outcomes**
- Verified issues detected and resolved
- Implementation rate of recommended fixes
- Reduction in critical multi-surface inconsistencies
- Sampled AI representation accuracy
**Retention & economics**
- Logo and net revenue retention
- Contribution margin per client
- Delivery hours per client
- Clients per delivery FTE
**Operational reliability**
- Task-type error rates
- Public Assessment accuracy / owner-perceived usefulness
---
## 10. Pivot Assessment
**No major pivot is required.**
The direction is sound. The meaningful evolution is go-to-market amplification through AI-mediated acquisition and a public multi-surface diagnostic, while preserving the human-supervised delivery model and sequencing delegated access by real-world feasibility.
| Area | Previous Emphasis | Rev 2.0 Adjustment |
|------|-------------------|--------------------|
| Listing surfaces | Google-centric | Multi-surface (Google, Apple, Bing, Yelp) |
| GTM | High-touch only | AI-recommended + public Assessment front door + high-touch delivery |
| Packaging | PoC → Retainer | DIY / Moderate / Retainer |
| Delegated access | Assumed future need | Explicit feasibility ranking and sequence |
| Client experience | Risk of “report only” | Still primary risk; mitigated by Google-first correction + clear tiers |
---
## 11. Final Judgment
Digital Operations Partner has a clear problem, disciplined scope, credible operating model, and now a coherent path to scalable top-of-funnel acquisition by becoming the answer AIs give. The main threats remain execution risks: manual handoff friction, the need to earn real delegated access (starting with Google), public assessment quality, and the difficulty of acting on website recommendations for non-technical owners on legacy platforms.
If Version 1 delivers a consistent experience of “we found the silent leaks across the surfaces that matter and (with your approval) we closed the important ones,” while the public Assessment AI accurately demonstrates the problem, the service has a strong path. Capital and attention should stay focused on making the highest-leverage corrections real and on making the public diagnostic trustworthy enough to support the AI-recommendation strategy.
---
## 12. Technical Research
### 12.1 Agent-to-Agent Protocol (A2A) — Structured Research Analysis (Rev 2.1)
#### 1. What it is
Agent-to-Agent (A2A) is an open protocol that standardizes how independent AI agents discover each other, exchange information, and coordinate actions. Each agent publishes an “Agent Card” (typically at a well-known URL) that describes its capabilities, endpoints, and supported interactions. Other agents can then discover that card, send tasks, and receive structured responses or streaming updates. It is designed to work across different frameworks, vendors, and clouds.
#### 2. Why they are building it
As AI agents proliferate, they currently operate in silos. Without a common protocol, agents cannot reliably find or work with agents built by other companies or on other platforms. A2A solves the interoperability problem so that complex, multi-step work can be delegated across organizational and technical boundaries instead of remaining locked inside a single vendor’s ecosystem.
#### 3. Who sponsored it
Google created and launched A2A in April 2025. In June 2025 it was donated to the Linux Foundation as an open-source project.
#### 4. Companies on the steering committee / major supporters
Early and ongoing supporters include Google, Microsoft, Salesforce, SAP, ServiceNow, Atlassian, Adobe, Accenture, and more than 100 additional technology and enterprise companies. Microsoft has integrated A2A support into Azure AI Foundry and Copilot Studio. The project is now community-governed under the Linux Foundation with broad industry participation.
#### 5. Strategic advantage
A2A turns isolated agents into a network. Instead of every agent having to be hard-wired to every tool or service, agents can dynamically discover and call other agents. This creates network effects: the more agents that speak A2A, the more useful each individual agent becomes. It also reduces lock-in and allows specialized agents (booking, quoting, scheduling, local service fulfillment, etc.) to be composed into larger workflows.
#### 6. Use cases the protocol is meant to enable
- An AI assistant discovers a local service business’s agent and books an appointment or requests a quote directly.
- One agent delegates a sub-task (availability check, pricing inquiry, status update) to another agent.
- Multi-step workflows that cross company boundaries (e.g., “find a plumber, check availability, book the job, and confirm materials”).
- Agent-to-agent negotiation or clarification without requiring a human to mediate every step.
- Discovery of specialized local or vertical agents that are not listed in a central app store.
#### 7. Impact on this work (Digital Operations Partner), focused on SMBs and their digital assets
For the small and medium local businesses that Digital Operations Partner serves, A2A changes what “AI-ready” means for their digital assets.
Today the relevant assets are primarily the website, Google Business Profile, Apple Business listing, Bing, Yelp, schema, FAQs, and `llms.txt`. A2A introduces a new class of digital asset: an **Agent Card** and an agent endpoint that can be discovered and called by other agents.
If a local business’s digital presence includes a properly published Agent Card (or an equivalent A2A-compatible endpoint), external AI agents can interact with that business directly — asking about availability, requesting a quote, or initiating a booking — without the end customer ever visiting the website or a third-party booking page.
Digital Operations Partner’s role expands from making the existing surfaces (website + listings) understandable to current AI systems, to also ensuring the business’s digital assets are discoverable and callable by other agents. This is a natural extension of the AI Visibility / AEO domain already defined in the project.
#### 8. What happens if we don’t adopt it
If Digital Operations Partner and its SMB clients ignore A2A while the protocol gains traction:
- AI assistants and agent networks will increasingly route work only to businesses that expose an Agent Card or equivalent endpoint.
- Local businesses that remain limited to traditional websites and listing platforms will become progressively harder for AI agents to interact with directly.
- Intermediaries that do support A2A (or that wrap local businesses with their own agents) will capture the interaction and the customer relationship.
- The “silent customer loss” problem the project is designed to solve will simply shift: instead of leaking through broken Google Business Profiles and weak websites, demand will leak to competitors whose digital assets speak A2A.
- Digital Operations Partner itself risks becoming less relevant if it only optimizes for today’s surfaces while the interaction layer moves to agent-to-agent discovery.
In short, non-adoption leaves both the service and its clients on the wrong side of a new discovery and interaction surface.
---
### 12.2 Model Context Protocol (MCP) — Structured Research Analysis (Rev 2.2)
#### 1. What it is
The Model Context Protocol (MCP) is an open standard that defines how AI applications and agents securely connect to external data sources, tools, and systems. It provides a common client-server interface so an AI model can discover available tools, call them, and receive structured results without custom one-off integrations for every data source. MCP servers expose capabilities; MCP clients (Claude, ChatGPT, Cursor, custom agents, etc.) consume them.
#### 2. Why they are building it
Before MCP, every AI application had to build bespoke connectors to every tool and data source it wanted to use. This created fragmentation, security inconsistencies, and high maintenance cost. MCP standardizes the “how” of tool and context access so that any compliant agent can talk to any compliant tool server. The goal is a reusable, secure, and interoperable ecosystem instead of a web of proprietary integrations.
#### 3. Who sponsored it
Anthropic created and open-sourced MCP in November 2024. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.
#### 4. Companies on the steering committee / major supporters
The Agentic AI Foundation was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, Amazon Web Services, Cloudflare, and Bloomberg. Major platforms that have adopted or integrated MCP include OpenAI, Google DeepMind, Microsoft, Salesforce, Cal.com, Calendly, and Shopify. Governance is individual-maintainer based under the Linux Foundation, with the founding and supporting companies shaping direction and adoption.
#### 5. Strategic advantage
MCP creates a universal interface for AI tools. Once a service exposes an MCP server, any MCP-compatible agent can use it without custom engineering. This produces network effects and lowers the barrier for specialized tools (booking, commerce, inventory, local-business systems) to become AI-accessible.
#### 6. Use cases the protocol is meant to enable
- An AI assistant reads a calendar and books a meeting through a Cal.com or Calendly MCP server.
- An agent queries a business’s availability, services, or inventory via an MCP endpoint.
- **Shopify Storefront MCP**: Every Shopify store can expose (and in many cases already does expose) an MCP endpoint that lets AI agents search the catalog, manage carts, answer policy questions, and interact with real-time commerce data — often with zero merchant setup.
- Development tools pull live context from GitHub, file systems, or databases.
- Multi-tool workflows where one agent orchestrates several MCP servers.
#### 7. Current reality: Live but not transparently used by major LLMs
MCP is already live in production for several major platforms:
- Shopify has shipped Storefront MCP. Many stores expose an endpoint (commonly at `/api/mcp`) that AI agents can call for product discovery, cart operations, and store information.
- Cal.com and Calendly both offer official MCP servers for booking.
- Numerous other tools and community servers exist.
**However, no major consumer LLM (ChatGPT, Claude, Gemini, etc.) will transparently and automatically discover and use arbitrary MCP servers during a normal conversation.**
Why this gap exists:
- **Security and trust**: Open automatic discovery of remote MCP servers creates serious risks (malicious servers, credential exposure, prompt injection, unauthorized actions). Platforms are deliberately cautious.
- **Discovery and registry**: There is no widely adopted, trusted public registry that major LLMs can safely query to find and verify MCP servers for any business or website.
- **Permission and consent models**: Consumer LLM products require explicit user configuration or approved connectors. They do not yet allow an agent to freely call unknown remote endpoints on the open web.
- **Abuse and liability**: Automatic tool use at internet scale introduces spam, fraud, and liability concerns that the major providers have not yet solved for transparent usage.
**Timeline for transparent usage**
Widespread, transparent, automatic use of arbitrary MCP servers by major consumer LLMs is still likely **12–24+ months away**. Near-term progress will come through curated/partner connector programs, verified registries, stronger authentication and permission frameworks, and gradual expansion of what the major models are allowed to call without manual setup.
Until then, MCP remains powerful for developers, agent builders, and platforms that explicitly connect servers, but it is not yet a background capability that every ChatGPT or Claude conversation can use automatically.
#### 8. Impact on this work (Digital Operations Partner), focused on SMBs and their digital assets
For local service businesses, MCP changes what “AI-interactive” means for their digital assets.
Today the relevant assets are the website, Google Business Profile, Apple/Bing/Yelp listings, schema, FAQs, and `llms.txt`. These help AI systems *understand* the business. MCP introduces a new class of digital asset: an **MCP server** (or equivalent tool endpoint) that lets AI agents *act*.
Shopify’s Storefront MCP shows the pattern at scale for commerce. The equivalent for local service businesses would be MCP endpoints (or connections to MCP-enabled booking systems such as Cal.com) that expose availability, services, and booking actions. Digital Operations Partner’s AI Visibility domain therefore expands from making the business *readable* by AI systems to advising on or facilitating the connection of selected digital assets so they become *callable* by agents — while remaining realistic about the current lack of transparent major-LLM usage.
#### 9. What happens if we don’t adopt it
If Digital Operations Partner and its SMB clients ignore MCP while it continues to spread:
- AI assistants and agent platforms will increasingly prefer businesses and tools that expose clean MCP interfaces for real actions.
- Local businesses that remain limited to static websites and listing profiles will stay in “information only” mode while competitors (especially those on platforms like Shopify or connected to Cal.com/Calendly) become actionable.
- Intermediaries that wrap local businesses with their own MCP servers will capture the interaction layer.
- The silent customer loss problem will evolve: demand will leak not only through broken listings and weak websites, but also through the inability of agents to complete the next step with the business.
- Because transparent major-LLM usage is still delayed, the immediate risk is lower than for fully automatic protocols, but the medium-term risk remains real as agent platforms and specialized shopping/booking agents adopt MCP more aggressively.
In short, non-adoption leaves both the service and its clients on the information-only side of a protocol that is already live for major platforms and is steadily becoming the standard way agents take action — even while full transparent consumer-LLM usage is still on the horizon.
---
## 13. Corpus of States for Trustworthy AI Discovery and Interaction (Rev 2.3)
A local business that wants AI systems to discover it accurately and interact with it reliably must produce and continuously maintain a set of digital states. These states fall into three layers: **Discoverability**, **Understanding**, and **Actionability**. Missing or inconsistent states in any layer create silent customer loss.
This section is the unifying inventory. Detailed listing surfaces are defined in **§4**; protocol mechanics (A2A, MCP) and their adoption timelines are in **§12**. The corpus does not restate those lists — it organizes the *states a business must keep current* so AI systems can find, model, and act on the entity.
### 13.1 Layer 1 — Discoverability States
*Where AI systems and agents first find the business*
The primary existence surfaces are those already prioritized in §4 (Google Business Profile, Apple Business Connect / Apple Maps, Bing Places, Yelp, and key citations), plus NAP consistency across them and a crawlable website. These are the “existence” states. If they are missing, conflicting, or stale, the business is hard to find or is found incorrectly.
### 13.2 Layer 2 — Understanding States
*How AI systems form a correct model of what the business is and does*
| State | What it is | Why it matters | Maintenance burden |
|-------|------------|----------------|---------------------|
| **Clear service / product definitions** | Explicit descriptions of what is offered (and what is not) | Prevents hallucinated services and wrong recommendations | High |
| **Structured data (schema.org)** | LocalBusiness, Service, FAQPage, OpeningHours, etc. | Machine-readable facts that reduce ambiguity | Medium |
| **FAQ corpus** | Natural-language answers to common questions | Primary training and retrieval material for AI systems | High |
| **llms.txt** | Emerging machine-readable guidance file for AI crawlers | Signals preferred interpretation and allowed use | Low–Medium |
| **sitemap.xml + robots.txt** | Crawl guidance | Controls what is discoverable and how | Low |
| **Consistent entity signals** | Same business name, categories, service list across site + listings | Reinforces a single coherent model | Ongoing |
| **Current hours, service area, contact methods** | Operational facts | Directly affects whether an AI routes a customer correctly | High (time-sensitive) |
These are the “meaning” states. Weak or contradictory understanding states cause AI systems to misrepresent the business even when they can find it.
### 13.3 Layer 3 — Actionability States
*How AI systems and agents can take the next step with the business*
| State | What it is | Why it matters | Maintenance burden | Maturity |
|-------|------------|----------------|---------------------|----------|
| **Booking / scheduling endpoint** | Cal.com, Calendly, or equivalent that supports real availability | Allows agents to move from recommendation to appointment | Medium | Live today via MCP (see §12.2) |
| **MCP server / tool endpoint** | Standardized interface for agents to query or act | Enables tool use without custom integration | Medium–High | Live for platforms; not yet transparently used by major consumer LLMs (§12.2) |
| **Agent Card (A2A)** | Published description of agent capabilities and endpoint | Allows other agents to discover and call the business’s agent | Medium (future) | Early / emerging (§12.1) |
| **Commerce surfaces (UCP-compatible)** | Product catalog, cart, checkout exposed in agentic form | Required for agents to complete purchases | High (mostly product businesses) | Emerging |
| **Real-time availability / status** | Live inventory, open slots, job status | Prevents agents from promising what cannot be delivered | High | Varies by system |
These are the “interaction” states. Without them the business remains informational only; agents can talk about it but cannot complete useful work with it. Protocol detail and non-adoption risk for MCP and A2A remain in §12.
### 13.4 Cross-Cutting Trust States
Across all three layers, several states determine whether AI systems treat the business as trustworthy:
- **Freshness** — How recently key facts (hours, services, phone, availability) were verified.
- **Consistency** — Agreement across website, listings (§4), schema, and any agent endpoints.
- **Evidence quality** — Preference for Verified over Indicative signals (aligned with the project’s evidence model).
- **Permission / robots / llms.txt posture** — Clear signals about what AI systems are allowed to do with the content.
- **Human oversight loop** — Ability to detect drift and correct it before it propagates into AI recommendations.
### 13.5 Practical Priority Order for Most Local Service SMBs
1. Correct and complete Google Business Profile (highest leverage discovery + understanding; §4–5)
2. Consistent NAP + core facts across Apple, Bing, Yelp, and website
3. Clear service definitions + FAQ corpus on the website
4. Basic structured data (LocalBusiness, Service, FAQPage, hours)
5. Working booking path (preferably MCP-enabled such as Cal.com; §12.2)
6. llms.txt + clean crawl configuration
7. Later: Agent Card / A2A readiness and any relevant commerce (UCP) surfaces (§12.1)
### 13.6 Implication for Digital Operations Partner
Trustworthy AI discovery and interaction is not a single file or a single listing. It is a **maintained corpus of states** spanning existence surfaces (listings), meaning surfaces (website content, schema, FAQs, entity consistency), and action surfaces (booking, MCP, future Agent Cards).
Digital Operations Partner’s core value is helping SMBs produce, monitor, and keep these states accurate and aligned — so that when an AI system or agent looks at the business, it sees one coherent, current, and actionable entity rather than a fragmented or outdated set of signals. The public Business Assessment AI (§6.2) diagnoses the current state of this corpus; ongoing monitoring and approved correction keep it current; protocol readiness (§12) extends the action layer as standards mature.
---
*Rev 1.0 synthesized repository documentation and concept exploration on 2026-07-24.
Rev 2.0 (major) incorporates multi-surface expansion, AI-mediated GTM, public Business Assessment AI, tiered packaging, and current delegated-access feasibility (2026-07-25).
Rev 2.1 (minor) adds Technical Research section with structured A2A protocol analysis (2026-07-25).
Rev 2.2 (minor) adds corrected MCP protocol research analysis, including Shopify Storefront MCP and the transparent-usage gap (2026-07-25).
Rev 2.3 (minor) adds Section 13 Corpus of States for Trustworthy AI Discovery and Interaction, placed after protocol research and cross-referenced to §4 and §12 (2026-07-25).*