veripath/docs/architecture/DOP-AI-Visibility-Unified-Framework-v1.md

# AI Visibility & Local Discovery — Unified Framework v1
## Convergence of the new Operating System draft into existing DOP governance

Status: Draft for review — resolves terminology collisions before this becomes canonical.
Supersedes: Nothing yet. This is the merge layer sitting between the new AI Visibility OS draft and the existing DOP repo (Agent Charter, Audit Playbook, Onboarding Manual, GLOSSARY, economic model).
Owner: Tony
Date: 2026-08-06

---

## 0. Why this document exists

Two frameworks now describe overlapping territory:

1. Existing DOP system — Layers 1–7 audit methodology (Layer 3 economics non-skippable), Tier 1 (owner-verified) / Tier 2 (public observation) evidence model, agent-detects/human-approves governance, filesystem-artifact-over-self-report verification standard.
2. New AI Visibility & Local Discovery OS — Stage 0–10 client lifecycle, Module A–H workstreams, Verified/Indicative evidence classification, Get Found / Stay Found packaging.

Both are sound on their own terms. They were not built against each other, so they use similar-sounding words for different things. This document is the crosswalk — it decides which term wins, where, and why, so nothing downstream (reports, agent skills, client-facing language) inherits ambiguity.

---

## 1. Decision 1 — CORRECTED: there was no collision. Verified/Indicative already IS Tier 1/Tier 2.

Original assumption (wrong): I treated "Verified vs Indicative" and "Tier 1 vs Tier 2" as two different axes needing reconciliation, and proposed renaming the new OS's terms to "Observed/Inferred" to avoid a collision.

Ground truth, pulled directly from `audit-playbook-v1.md`:

> Evidence Model only — Every fact is Tier 1 (Verified) or Tier 2 (Indicative). No unmarked claims.

There is no second axis. Tier 1 is Verified. Tier 2 is Indicative. Same bucket, two labels used together, always. The playbook's Layer 1 rule reinforces this: "Public observation = Tier 2 until owner access or stronger verification upgrades it" — meaning Tier 1/2 already encodes *both* source authority and observation confidence in one scale, not two separate dimensions.

Resolution: Delete the "Observed/Inferred" rename — it solved a problem that doesn't exist. Module A's Verified/Indicative language (Section 11) is already correct as written and requires no change. Use "Tier 1 (Verified)" and "Tier 2 (Indicative)" together in all client-facing and internal documentation going forward, matching existing playbook style.

One real distinction worth preserving, not as a rename but as a note: the playbook's Tier 2 default rule — "Public observation = Tier 2 until owner access or stronger verification upgrades it" — is a *procedural* rule about how tiers get assigned, not a different taxonomy. Module A's Evidence Record schema (Section 20) should carry this default explicitly: any fact sourced from an AI engine output or public scrape starts at Tier 2 regardless of how confidently it was captured, and only moves to Tier 1 if the client confirms it directly.

Addendum — evidence authority nuance (added after Qwen review). The single Tier 1/2 scale holds, but different fact classes have different verifying authorities, and conflating them causes real confusion — "we verified the audit run happened" is not the same claim as "we verified the business fact inside it is true." Three classes:

1. Business-entity facts (name, phone, address, hours, services, categories, profile ownership). Default Tier 2 when observed publicly. Promotes to Tier 1 only via owner confirmation or owner-access verification.
2. Audit-run facts (prompt executed, engine captured, timestamp recorded, raw output stored, competitor appeared in captured output). Default Tier 1 when supported by stored filesystem/git/database artifacts — this verifies the audit *event* occurred, not that the business fact inside the output is true.
3. Public claims inside AI outputs (an engine stating the client's phone number, hours, or service scope). Default Tier 2 until owner confirmation or owner-access verification upgrades it.
Action: add this three-class breakdown to GLOSSARY under the Tier 1/2 entry, so "verified" is never ambiguous between "the run happened" and "the fact is true."

---

## 2. Decision 2 — CORRECTED: Layers are the whole engagement sequence, not audit depth inside Stage 2. Real gap found.

Original assumption (wrong): I guessed Layers 1–7 were a depth-scale nested inside Stage 2 (Discovery & Diagnosis).

RESOLVED — verified against `path-to-poc-sequencing.md`, pulled directly from main by Ty on 2026-08-06. The earlier "real gap found" claim was wrong. Layers 4 and 5 are fully specified in the actual sequence doc, each with entry criteria, exit criteria, required data, blocked-if-missing conditions, and a primary artifact — requirements-template.md (Layer 4) and workflows-template.md (Layer 5) both already exist in docs/templates/. This framework's earlier claim that these had "no equivalent" was built on an inability to reach the file, not on the file actually being empty. Confirmed sequence:

1. Account Intelligence — 1a Public baseline / 1b Owner-access. Artifact: data-inventory-v1.md
2. Threat Diagnosis. Artifact: threat-register-v1.md. Severity: Critical/Major/Minor
3. Economics & Pricing Validation — non-skippable, confirmed. Artifact: economics-v1.md / pricing-bands-v1.md
4. Response Requirements. Artifact: requirements-v1.md
5. Workflow Engineering. Artifact: workflows-v1.md
6. Agent Build & Test. Artifact: build-log-v1.md
7. POC Delivery & Retainer Conversation

Verified bridge map (no longer a working hypothesis):

| Client Stage | Layers (verified) | Notes |
|---|---|---|
| Stage 0–1 (Targeting & Lead Gen) | Pre-Layer 1 | ICP targeting, Free Check |
| Stage 2 (Discovery & Diagnosis) | Layer 1a + Layer 2 | Cold audit → Diagnostic Record |
| Stage 3 (Proposal & Packaging) | Layer 3 | Economics, non-skippable |
| Stage 4 (Onboarding & Access) | Layer 1b + Layer 4 | Owner-access verification *and* requirements — see structural correction below |
| Stage 5 (Remediation Sprint) | Layers 5 + 6 + 7 | Workflows, build/test, POC delivery |
| Stage 6 (Verification & Reset) | Re-run of Layers 1–2 tooling | Second diagnostic pass, not delivery |
| Stage 7–10 (Monitor → Offboard) | Post-PoC operations | Drift detection, stewardship |

Structural correction the sequence doc forces: Stage 4 cannot be Layer 4 alone. The sequence doc's own ordering — account intelligence → problems → requirements → workflows — plus the fact that owner-access verification (Layer 1b) has to happen before requirements can be finalized, means Stage 4 does double duty: owner-access work *and* requirements-gathering both land there. This also resolves where the Owner-Verified Correction Plan actually belongs (see Decision 7, corrected below) — it's Layer 1b content, not Layer 4.

Layer 7 still belongs at Stage 5, per the original catch — the sequence doc's own Layer 7 name ("POC Delivery") confirms this, it wasn't just a reasonable guess.

---

## 3. Decision 3 — Module A's Section 15 replaced with an enforceable Artifact A/B split

Non-Negotiable #5 states: *"No solution language in Layer 1 or 2. Diagnosis only. No 'fix this,' 'claim that,' or workflow suggestions."* Module A's original report structure (Section 15) bundled diagnostic content with solution content in one deliverable. Fix, converged on across two passes:

Artifact A — The Diagnostic Record (Layer 1 & 2 safe). Scope corrected after cross-check against existing repo templates — earlier drafts of this artifact duplicated data-inventory-v1.md (Layer 1) and threat-register-v1.md (Layer 2) instead of feeding them. Artifact A now holds only the measurement content with no existing home: Methodology & Limitations, the Core Visibility Index (70 pts quantitative, see below), Directional Context Indicators (Tier 2), Prompt-Level Evidence, and the per-engine sourcing table. Entity/signal state and evidence-ledger content are not restated here — they get transcribed into data-inventory-v1.md and threat-register-v1.md using those files' existing schemas as part of completing an audit run.
Artifact A is a source input to those two files, not a parallel record.

QA gate scope, refined after Qwen review — this was a real gap in the original rule. A blind banned-word scan across the whole document produces false positives: prompt text naturally contains "who should I call," raw engine output naturally contains "I recommend." The gate must apply only to authored diagnostic narrative, never to raw evidence payload:

| Field type | Gate applies? |
|---|---|
| Executive summary, observation narrative, competitor observation summaries | Yes — authored interpretation |
| Raw prompt text, raw engine output, source titles/URLs, platform field labels, quoted business names | No — observed evidence or system metadata |

Banned terms in the gated fields: should, recommend(s)/recommendation(s), fix/fixing, opportunity/opportunities, package(s), proposal/propose, solution(s), action plan, next step. Automated token matching is a first-pass control only — synonym evasion means human review stays required regardless.

Artifact B — The Strategy & Remediation Brief (Layer 3+). Scope corrected the same way. Earlier drafts duplicated requirements-v1.md (Layer 4) and workflows-v1.md (Layer 5) via a Prioritized Action List with Owner/Effort/Approval columns — that's workflow structure, already templated. Artifact B now holds only: the Opportunity Matrix (evidence × capacity × ticket size — the economic weighting layer with no existing home), Revenue-at-Risk scenarios, Package Recommendation, and Measurement Window. Actions themselves live in requirements-v1.md / workflows-v1.md; the Opportunity Matrix feeds into those by entry ID rather than restating them.

This enforces Non-Negotiable #5 by construction, not just by discipline — a scoped banned-word check on Artifact A's authored fields is trivial to automate as a QA gate, fitting the existing Gate pattern in Module A §19.

Severity vs. Priority — cross-reference, don't merge: the playbook's Threat Register uses Critical/Major/Minor (how bad is the problem — Layer 2, lives in Artifact A). Module A's Opportunity Prioritization Matrix uses Fix Now/Fix Soon/Monitor (how urgent is the fix — Layer 3+/5, lives in Artifact B). Keep both; note the distinction explicitly in GLOSSARY so a report never conflates a Critical *diagnosis* with a Fix Now *priority* as if they were the same field.

Scoring rubric issue — now resolved, not just flagged. Competitor Share Gap and Source/Citation Quality were qualitative bands dressed as part of a 0–100 formula. Split into two separate things instead of forcing a single false-precision number:

- Core Visibility Index (quantitative, 70 pts, lives in Artifact A): Mention rate (35) + Mention strength/position (20) + Description accuracy (15). Everything here is directly countable from captured audit runs.
- Directional Context Indicators (Tier 2, reported separately, not folded into the 70): Source/citation quality, Competitor observation share, Engine variance. Client language: *"The Core Visibility Index is based on directly countable audit observations. The directional context indicators are qualitative and indicative, not a measured market share."* If a single number is still wanted for sales simplicity, call it the "Directional Visibility Index" and disclose in the methodology note that part of it is qualitative.

Action: Replace Section 15 in Module A's source doc with the Artifact A/B structure above, replace §10's scoring model with the Core Visibility Index / Directional Context Indicators split, and apply the field-scoped QA gate. Commit Artifact A's template under docs/agents/ (Layer 1/2 tooling, same category as the audit playbook) and Artifact B's template under docs/templates/remediation-brief-template.md — both now drafted in full, see files attached to this session.

---

## 4. Decision 4 — Module G inherits Leonard's actual failure record, not generic language

The gap: Module G ("Agent & Automation Layer") says "human-in-the-loop gates on all client-facing claims and live changes." True, but it doesn't cite *why* — it reads like a generic AI-safety boilerplate rather than a rule earned from real incidents.

Resolution: Module G should explicitly reference the standing protocol already established:

- Never trust agent self-reports of task completion — verify via git state or filesystem artifacts directly.
- This rule exists because of documented failure patterns: false self-completion reports, fabricated file content, fabricated SHA values (Leonard, prior sessions).
- The two-branch (develop/main) workflow was retired after a fabricated verification report; all commits now go directly to main with human verification substituting for the branch-gate.

Confirmed by the actual playbook — this isn't hypothetical, it's already implemented for one workflow. The GBP cold-audit pattern already enforces exactly this kind of constrained autonomy: *"Leonard maps fields and fires only R1–R3"* via a fixed execution card, with an explicit ban on "free-form GBP reasoning." This is the working precedent for Module G's future agent skills (A1–A7 in Module A) — each skill spec should follow the same pattern: a fixed execution card / trigger-rule set, not open-ended judgment, especially before a skill has a scored track record in the task reliability ledger.

Action: Rewrite Module G's human-gate language to cite this precedent instead of restating a generic principle. When Module A's Skills A2 (Audit Runner) and A3 (Mention Extractor) are actually built, they should follow the GBP execution-card pattern — fixed trigger rules, not free-form reasoning — until each has scored runs in the task reliability ledger.

---

## 5. Decision 5 — Section 4 (Data, Tools & Infrastructure) reflects the storage decision already made

The gap: The new OS's Section 4 lists data objects generically (client master record, prompt libraries, audit runs, etc.) as if the storage architecture were still undecided.

Resolution: It's decided. Replace the generic list with the actual hybrid architecture:

- Canonical business records — flat JSON in git (free version history, audit trail)
- Runtime check state — Postgres or SQLite (client slug, surface, field, canonical value, observed value, state, timestamps, raw response blob)
- Schema primitives — fact/surface separation with adapter-declared field mappings, a prohibition predicate type for ghost-listing detection (match = failure), type tags on every fact driving normalization at comparison time

Action: Replace Section 4's data-object list with this architecture description. Storage mapping now confirmed per-object rather than left as a general split:

| Data object | Primary storage | Secondary/export | Reason |
|---|---|---|---|
| Client master record | Git JSON | Postgres/SQLite cache | Canonical, versioned, auditable |
| Prompt library + version manifest | Git JSON | DB reference | Immutable audit trail |
| Competitor set | Git JSON | DB reference | Versioned scope |
| Audit run manifest | Git JSON | DB runtime record | Immutable metadata |
| Schema version | Git JSON / repo files | DB reference | Canonical versioned artifact |
| Task reliability ledger | Git JSON or DB (volume-dependent) | — | Needed before skill promotion (Decision 8) |
| Engine output record, prompt execution log | Postgres/SQLite | Audit run export | High-volume runtime data |
| Mention extraction, competitor mention, source citation records | Postgres/SQLite | Artifact A evidence ledger | Derived runtime data |
| Evidence record | Postgres/SQLite | Approved Artifact A export | Runtime ledger becomes approved artifact |
| Opportunity record | Postgres/SQLite | Approved Artifact B export | Prescriptive work belongs in Layer 3+ |
| Citation status ledger | Postgres/SQLite | Sprint report export | Runtime check state |
| GBP change log, drift detection event | Postgres/SQLite | Monthly stewardship export | Runtime change tracking |

---

## 6. Decision 6 — Packaging language checked against Revenue-at-Risk conservatism
Get Found / Stay Found / Custom packaging (Stage 3) is new relative to what's in the existing repo — first appearance. No conflict, but it should be reviewed once against the existing Revenue-at-Risk conservative-language rules before it's client-facing, specifically: package recommendation copy shouldn't imply guaranteed lift ("Get Found gets you found" reads differently than "Get Found addresses verified entity defects").

Action: Low priority — flag for a pass once packaging copy is actually drafted, not before.

---

## 7. Decision 7 — Merging Ty's business-readiness gap analysis (a second, parallel track)

Ty produced docs/DOP-BusinessReview_ty_grok_Aug062026.md — a business-readiness gap analysis, not a documentation-architecture reconciliation. It asks a different question than everything above: not "do our terms collide," but "what unmade decisions would surprise a client." Both tracks are needed; they hadn't been merged. This section merges them.

### 7.1 What Ty's document adds that this framework was missing

A. Per-engine sourcing breakdown — corrects Module A §8 (Engine Selection). Module A currently treats ChatGPT, Gemini, Perplexity, Claude, and Grok as symmetrical — same prompt set, same method, across all five. Ty's breakdown says they aren't:
Status: Tier 2 (Indicative)
Source: Ty business-readiness review, 2026-08-06
Validation required: direct audit observation or authoritative documentation before treating as operating fact.

| Engine | Primary local-answer source, working model | Highest-leverage signal, working model | Evidence tier |
|---|---|---|---|
| Gemini | Google's local graph | GBP, Maps/Places, reviews, categories, hours | Tier 2 |
| ChatGPT | Bing web index + partner place data + open web | Foursquare places data, Bing-visible consistency, business website, directory NAP | Tier 2 |
| Claude | Tools/APIs + web, often Google Places when looking up locals | Google Places/Maps-aligned data, clear website, consistent public facts | Tier 2 |

Action: Add this table, with its tier tag and source line intact, to Module A §8.3 (Engine Metadata Required) as context for why the *same* prompt run against different engines should not be scored as if testing the same underlying signal. This also means Skill A3 (Mention Extractor) needs engine-aware source attribution, not just a flat "which sources were cited" field. Resolved: the earlier flag that this table was an unmarked claim is now closed — it carries an explicit Tier 2 tag, source, and date, matching Non-Negotiable #1.

B. Two-phase owner pacing — CORRECTED mapping. Ty's Phase A (Correction Plan, heavy owner attention, done once) / Phase B (ongoing change management, light touch, owner notifies once) gives concrete shape to something the Path to PoC sequence names but doesn't fully template. Original mapping guessed Layer 4; verified mapping is different:

| Ty's phase | Maps to (verified) |
|---|---|
| Phase A — Correction Plan | Layer 1b (Owner-access verification) + Stage 4 — fills a real documentation gap in Layer 1b's exit criteria, not a Layer 4 gap (Layer 4 already has `requirements-v1.md`) |
| Phase B — Ongoing change management | Stage 7 (Ongoing Monitoring) content, reframed as *stewardship*, not just drift-watching |

This is a genuinely useful fill, just for a different layer than first proposed: Layer 1b's exit criteria imply canonical NAP, access matrix, no-change zones, and approval boundaries, but the sequence doc doesn't template that content. Ty's Correction Plan is a concrete candidate for that Layer 1b artifact.

C. "Human-heavy, automation-light V1" — a corrective to drift already visible in this framework. Ty's document names this explicitly as a scaling constraint. It reinforces, at the whole-service level, something Decision 4 only applied narrowly (the GBP execution-card pattern, no free-form agent reasoning). Module A's Skill A1–A7 specs and the "Level 2 Agent-Assisted" language in the original OS draft imply more automation than a human-heavy V1 actually supports. Resolved — Module G replacement text:
## Module G — Agent & Automation Layer

### V1 posture
V1 is human-heavy and automation-light. Agent skills are tools underneath
human delivery, not autonomous operators. Skills A1–A7 are Level 2 /
aspirational unless explicitly promoted through a dated decision and
supporting reliability evidence (see Decision 8 promotion gate).

### Standing verification controls
Never trust agent self-reports of task completion. Completion must be
verified through git state, filesystem artifact, stored raw output,
database row, hash/checksum where applicable, or human inspection of
the actual changed surface. Earned from documented failure patterns:
false self-completion reports, fabricated file content, fabricated
SHA values, verification claims unsupported by repository state.

### Execution-card pattern
Agent skills begin as constrained execution cards, not open-ended
reasoning tasks. Each card defines: trigger conditions, allowed inputs,
forbidden actions, deterministic output format, human approval gate,
evidence required to prove completion, rollback/escalation path.
Working precedent: the GBP cold-audit pattern — Leonard maps fields
and fires only fixed rules R1–R3, no free-form GBP reasoning.

### Promotion rule
A skill receives expanded autonomy only after scored, successful runs
in the task reliability ledger (see Decision 8 thresholds). Until then:
no live client changes without human approval, no client-facing claims
without human review, no self-reported completion accepted as evidence.

D. Restraint as a design principle — genuinely new, not present anywhere else in either track. "Constant change can weaken confidence... leave alone what should stay stable" has no equivalent in Module A or the Path to PoC docs. Worth carrying into GLOSSARY or the eventual Phase B operating rules as an explicit principle: freshness is not the same as activity, and over-editing has a cost.

### 7.2 Exposure craft vs. content marketing boundary — resolved

The README lists V1 Scope Exclusions explicitly: Social media production, Paid advertising, Website redesign, Branding projects, Content marketing, Full SEO campaigns, CRM/email marketing. Ty's "exposure craft" sits close to that line. Boundary, now explicit:

In scope: platform category selection, attributes, service listing fields, structured short descriptions constrained by platform fields, Q&A seeded from owner-verified facts, schema properties derived from owner-verified data, canonical NAP enforcement, listing-field language matching customer search language.

Out of scope: open-ended copywriting, blog content, content marketing strategy, brand narrative development, social media production, paid advertising copy, website redesign copy.

Action: write this boundary into whatever doc formalizes Phase A / the Owner-Verified Correction Plan, so it isn't left to case-by-case judgment.

### 7.3 Consolidated open-decision list (merging both tracks)

Architecture / documentation track — resolved this pass:
- Confirm the Layer/Stage bridge map against the real `path-to-poc-sequencing.md` — done, verified, no longer a working hypothesis
- Split Module A §15 into Artifact A/B, commit both templates — done, both templates trimmed to remove duplication with existing repo templates and drafted in full
- Fix Module A §10's qualitative scoring bands — done, Core Visibility Index (70 pts quantitative) / Directional Context Indicators (Tier 2, separate) split
- Update GLOSSARY with Severity vs. Priority cross-reference — done, drafted in full at docs/GLOSSARY-additions.md

Business-readiness track (Ty's document) — still open:
- Website monitoring: exact always/never-checked list; remediation ownership; evidence standard
- V1 platform scope: which platforms are actually in v1; Foursquare/Bing Places depth
- Phase B intake channel, notice completeness requirements, turnaround SLAs, per-item-approval boundary
- AI sampling method, cadence, and owner-facing language — this is functionally a lightweight version of Module A's Free Check; worth explicitly naming as the same mechanism rather than a separate one
- Monthly report format when there's little to fix — "stewardship summary," not an empty repair list
- Retainer vs. project-only client criteria

Resolved this pass (was open, now closed):
- Tag the per-engine sourcing table with a source/date and Tier 2 marking — done
- Confirm Correction Plan's intended layer — done, re-homed to Layer 1b (owner-access verification), not Layer 4 — Layer 4's real deliverable is requirements-v1.md
- Add the exposure-craft / content-marketing boundary line — done, §7.2 above
- Add the Skills A1–A7 = Level 2/aspirational note to Module G — done, full replacement text drafted above and in GLOSSARY
- Reconcile Artifact A/B against existing `data-inventory-v1.md` / `threat-register-v1.md` / `requirements-v1.md` / `workflows-v1.md` — done, both artifacts trimmed to non-duplicated content with explicit feed-forward sections

Still open from Decision 8:
- Observability variance/fallback policy for Module A — no owner, no target date yet
- Add the client-facing-surface restriction (Artifact A stays internal) to Module F and the onboarding manual as a non-negotiable line

Action: This section (7.3) is now the single master open-decision list. Future work should check items off here rather than re-deriving them from either source document separately.

---

## 8. Decision 8 — Internal rigor vs. delivery velocity (response to multi-source adversarial critique)

Three independent reviews converged on the same core tension without coordinating: process weight as a scaling and commercial risk. That level of convergence is itself the signal to resolve, not just note.

### 8.1 The critique, calibrated

Where it lands: the process-complexity-vs-velocity tension is real. A separate, genuinely new point that hadn't surfaced anywhere else: observability fragility — Module A's audit engine assumes reliable, repeatable capture across five consumer AI products indefinitely, with no fallback for vendor UI changes, geo-personalization drift, anti-bot friction, or rate-limiting on automated-looking usage. That's an operational risk, not a governance one, and governance language doesn't fix it.

Where it overstates the case, on reflection:
- It treated the business as a thin, specialized "AI Visibility" bet. The actual thesis (README) is broader — Silent Customer Loss prevention across Customer Path Integrity, AI Visibility, and Local Competitive Awareness. The AI-answer channel is one surface, not the whole bet.
- It read Artifact A's banned-word discipline as something clients would find evasive. Artifact A was never meant to reach a client raw — it's internal evidentiary backing behind a synthesized plain-language report. This needs to be made explicit and non-negotiable in the docs so it can't drift into a client-facing artifact by accident.
- It critiqued SMB unit economics against a volume-scale future that hasn't been chosen. The ICP matrix and "proof first, retainer after demonstrated value" motion already exist to prevent indiscriminate SMB volume-chasing at this stage. The critique is a legitimate warning for a later decision, not a diagnosis of the current one.
- The conservative evidence-language positioning was framed as accidental friction. It's a deliberate, already-stated bet (evidence discipline as differentiator vs. overpromising agencies) — untested, but not an oversight.

### 8.2 Resolution

- Internal apparatus stays mandatory at current PoC scale, no exceptions. Artifact A's banned-word gate, Tier model, execution cards, and the reliability ledger all remain required while the business is at 2 clients and proving the model. This is not the place to cut corners — it's also the phase with the least revenue pressure to justify cutting them.
- Client-facing surface is explicitly restricted and this boundary is now non-negotiable, not just a stated intent.
Clients see: the Correction Plan (Phase A), the prioritized action list, and stewardship reporting (Phase B). They never see Artifact A, Tier tags, execution-card mechanics, or Layer/Stage internals. Action: add a line to Module F (Client Delivery System) and to the onboarding manual stating this boundary explicitly, so it's enforced by documentation, not by individual judgment call.
- A dated, measurable promotion gate — made concrete, not left as "a decision is required": the playbook already has the machinery for this in its Training/Evaluation Rubric (0–2 per criterion, pass ≥7/10, **Benchmark quality = 9–10 with zero scope violations**). Use it directly as the velocity re-optimization trigger:

  | Condition | Threshold |
  |---|---|
  | Scored runs logged in the task reliability ledger for a given skill | ≥5 runs |
  | Runs scoring at Benchmark quality (9–10, zero scope violations) | ≥80% of those runs |
  | Consecutive weeks with zero fabrication or self-report incidents for that skill | ≥4 weeks |
  | Client count before *any* skill is eligible for promotion review | ≥3 (i.e., past pure PoC, not before) |

  Only once a specific skill clears all four does it become eligible to move from execution-card-constrained to higher autonomy — decided per-skill, not as a blanket velocity switch for the whole system. This keeps the promotion mechanism itself evidence-gated, consistent with everything else in the repo, rather than a vague future intention.

- Observability fragility is logged as its own open operational item, separate from the complexity question: Module A needs an explicit variance and fallback policy — how much engine-to-engine variance is disclosed to clients vs. absorbed into the score, what happens when a vendor changes UI or rate-limits automated-looking sessions, and a defined minimum viable capture method if API access isn't available for a given engine. This has no owner yet and no target date. Action: add to §7.3's consolidated list as its own line, not bundled into the velocity gate above — a different kind of risk, different kind of fix.

Net effect: the critique doesn't change what gets built next, but it changes what "success" means before scaling — success now explicitly includes hitting the promotion thresholds above, not just delivering PoC results. That's a real answer to "when do we stop being this heavy," not just an acknowledgment that the question exists.

---

## 9. What's now resolved vs. still open

Resolved against the actual repo — audit-playbook-v1.md, README, path-to-poc-sequencing.md, and the four existing client/template files, all pulled from main (2026-08-06):
- No evidence-model collision existed. Verified = Tier 1, Indicative = Tier 2, one vocabulary, now with a three-class authority breakdown (business-entity facts / audit-run facts / public claims inside AI outputs).
- Layers 1–7 are the full, verified Path to PoC engagement sequence. The Stage↔Layer bridge map is confirmed, not a working hypothesis — including the Stage 4 double-duty correction (Layer 1b + Layer 4 both land there) that the sequence doc's own ordering forces.
- Layer 7/POC Delivery confirmed at Stage 5, not Stage 6 — the sequence doc's own naming confirms this was correct, not just a reasonable guess.
- Artifact A and Artifact B are trimmed to hold only content with no existing repo home, after discovering they originally duplicated data-inventory-v1.md, threat-register-v1.md, requirements-v1.md, and workflows-v1.md. Both now carry explicit Feed-Forward sections naming exact file paths, verified against live client directories (`docs/clients/overcome-fitness/`, `docs/clients/phoenix-salons/`).
- Module A's Section 15 replaced by the trimmed Artifact A/B split, satisfying Non-Negotiable #5 by construction, with the banned-word gate scoped to authored fields only (raw evidence exempt — avoids false positives on prompt text and engine output).
- The Core Visibility Index (70 pts quantitative) / Directional Context Indicators (Tier 2, separate) split resolves the earlier false-precision scoring issue.
- Module G's human-gate rationale ties to Leonard's documented failure patterns and the GBP execution-card precedent; full replacement text drafted.
- Data architecture and storage mapping (Decision 5) confirmed per-object.
- Ty's business-readiness gap analysis merged (Decision 7); per-engine sourcing table now carries an explicit Tier 2 tag and source date.
- The Owner-Verified Correction Plan is re-homed to Layer 1b, not Layer 4 — Layer 4's actual deliverable is requirements-v1.md.
- The multi-source complexity-vs-velocity critique resolved as Decision 8, including a measurable promotion gate against the existing reliability-ledger rubric.

Still open:
- Six business-readiness decisions from Ty's track (§7.3): website monitoring always/never list, V1 platform scope, Phase B intake/SLA rules, AI sampling cadence/language, monthly stewardship report format, retainer vs. project-only criteria.
- Observability fragility (Decision 8) — variance/fallback policy for Module A, no owner or target date yet.
- Requirements/workflows have templates but no live client instances yet — Artifact B's feed-forward targets (`requirements-v1.md`, `workflows-v1.md`) will need to be created per-client when Layer 4/5 work actually starts.

---

## 10. Immediate next step

The bridge-map verification that was blocking this document is done. Remaining work no longer has a single blocking dependency:

1. Commit the four files (this framework doc, Artifact A, Artifact B, GLOSSARY-additions) to main, direct commit per standing policy, no branch.
2. Work through §7.3's six remaining business-readiness decisions — none depend on further repo archaeology, they're just decisions to make.
3. Assign an owner and target date to the observability variance/fallback policy — still the only item in this document with no owner at all.
4. When Layer 4/5 work starts for a live client, create that client's requirements-v1.md and workflows-v1.md instances from the existing templates, and confirm Artifact B's Opportunity Matrix correctly feeds entries into them by ID.