# G05 — Feedback-learning, governance and KPI design

**Completed:** 2026-07-30T00:36:20-04:00  
**Status:** Completed design only. No publishing, account creation, outreach, deployment, credential use, or customer-data mutation occurred.

## Executive decision

Brad/OA should build a **versioned learning system, not an autonomous posting optimizer**. Edits, approvals, rejections, performance observations, and identity/context corrections become append-only evidence about a specific source, concept, creative version, platform, handle, audience, and observation window. They may change recommendation scores and reviewer routing, but they do **not** silently rewrite policy, alter approved content, create identities, or authorize public action.

The safe operating boundary is:

- durable software owns canonical state, lineage, policies, permissions, approvals, suppressions, receipts, and audit history;
- deterministic workers perform validation, aggregation, queueing, reconciliation, and approved low-risk transformations;
- agents classify evidence and propose drafts, tests, and explanations;
- accountable humans resolve identity, rights, claims, sensitive context, brand judgment, and every public release until a separately approved pilot proves a narrower automation class safe.

This design extends G04’s gated 24 → 50–64 → 75–100 pieces/day rollout. The thresholds below are **Sterling operating proposals**, not proven Gary/Vayner or OA performance standards.

## 1. Canonical version and evidence model

Never overwrite a decision or learning input. Store a new event and a new version.

`source_asset → source_segment → concept_version → creative_version → review_decision → approval_receipt → placement_receipt → observation_window → business_event → learning_record`

### Immutable identities

- **Source asset:** content hash, capture time, creator, rights/sensitivity state, people/brands, context version, transcript/vision versions.
- **Concept version:** audience, persuasive/community job, claim, evidence links, CTA class, prohibited interpretations, author and timestamp.
- **Creative version:** media hash, copy hash, platform, exact immutable handle/resource ID, format, hook, thumbnail/cover, disclosure, transformations, model/prompt/tool versions.
- **Decision event:** `edit_requested`, `approved`, `rejected`, `quarantined`, `expired`, or `revoked`; actor, role, timestamp, reason codes, free-text rationale, before/after diff, policy version.
- **Placement receipt:** approved-version hash, provider resource ID, idempotency key, schedule/publish result, canonical URL/status, independent read-back, takedown or correction receipt.
- **Observation:** metric definition/version, platform/handle, retrieval timestamp, attribution window, denominator, unavailable/deleted state, and raw-evidence pointer.
- **Learning record:** evidence set, hypothesis, confidence, counterexamples, scope, recommended action, human decision, expiration, superseding record.

### Material-change rule

Any change to media, copy, claim, CTA, disclosure, platform, handle, audience, schedule, campaign/version, credential/resource binding, policy, rights, or spend invalidates the affected approval. Cosmetic metadata may be declared non-material only by a versioned policy and must still create a new receipt. Approval binds the exact payload hash—not a filename, campaign name, or editable dashboard row.

## 2. Feedback taxonomy: what the system is allowed to learn

Use controlled reason codes plus human notes. One event may carry multiple codes.

| Feedback class | Examples | Safe learning effect | Never automatic |
|---|---|---|---|
| Editorial edit | hook shortened, caption clarified, crop changed | rank similar proposals; update style suggestions within the same brand/platform scope | rewrite approved/live content |
| Approval | exact version accepted for named channel/window | positive evidence for that scoped pattern | approval of sibling variants or future posts |
| Rejection | off-brand, repetitive, weak, wrong audience | lower/suppress the scoped pattern; route recurrence to reviewer | global ban without minimum evidence/review |
| Identity/context correction | wrong person, role, company, locality, event, chronology | quarantine descendants; correct canonical entity/context record; require re-review | infer a new identity or merge people automatically |
| Rights/privacy correction | no consent, client/private data, logo/music issue | hard suppression on affected source/derivatives; incident workflow | “learn around” or obscure a rights restriction |
| Performance observation | watch quality, saves, qualified comments, inquiries | propose controlled experiments after window normalization | publish more because raw views increased |
| Operational failure | duplicate attempt, wrong route, timeout, backlog | adjust routing/retry policy; open reliability action | retry an uncertain side effect blindly |
| Business outcome | qualified inquiry, meeting, opportunity, revenue | estimate scoped incremental value with attribution confidence | claim causality from correlation |

### Correction propagation

1. Correct the canonical entity/context/rights record with actor and evidence.
2. Mark every dependent concept, creative, approval, placement candidate, and learning record `stale` or `quarantined`.
3. Block unpublished descendants immediately.
4. For live placements, create a human-reviewed impact list and compensation choice: leave with annotation, correct, hide, delete, or escalate.
5. Recompute recommendations only from corrected versions; preserve the original event chain.
6. A pattern with repeated identity/context corrections cannot regain normal routing merely from engagement performance.

## 3. Approval and decision gates

### Gate A — intake and rights

Before selection: source identity/hash, creator, sensitivity, rights/consent, location precision, people/brands, client/private-data screen. Missing or conflicting material fields means `QUARANTINED`, not low-confidence drafting.

### Gate B — concept and evidence

Before production: audience/job, claim and evidence, CTA class, platform/handle eligibility, prohibited interpretations, freshness. Unsupported claims, deceptive locality, fake persona framing, or unclear accountable ownership are rejected.

### Gate C — creative QA

Before approval: source fidelity, factual/identity accuracy, privacy crop/blur, rights, brand, native adaptation, accessibility/captions, duplication, CTA/link, and exact provider resource ID. A human QA reviewer checks every public candidate through the G04 pilot and scale phases.

### Gate D — version-bound approval

Approval receipt includes approver identity/role, tenant/brand, campaign and creative version, all hashes, platform, immutable handle/resource ID, audience/cohort, schedule window, policy version, expiration, and any spend/credit limit. Content approval, account/credential authorization, spend authorization, and launch authorization remain separate decisions.

### Gate E — prepare/commit/publication

A deterministic adapter may prepare an exact dry run. Any live mutation requires explicit authority for that scope, a valid unexpired receipt, route-identity canary, suppression check, idempotency lease, cap check, and kill-switch check. `approved`, `published`, and `verified` are separate states. No G05 work authorizes a post, comment, DM, invitation, new handle, or autonomous account action.

### Gate F — post-publication reconciliation

Independently read back provider ID, URL/status, payload identity where available, publication time, and account/handle. A success response without read-back is `publication_unverified`. Uncertain failures pause and reconcile; they do not retry blindly.

## 4. Confidence thresholds and autonomy ceiling

Confidence is scoped by **task + platform + handle class + audience + risk tier + policy version**. It is not a universal model score.

| Band | Requirements | Permitted action |
|---|---|---|
| **Hard stop** | rights/consent missing; private/client data; identity conflict; deceptive persona/locality; unsupported sensitive claim; account mismatch | quarantine/reject; human owner required |
| **Low (<0.70)** | weak source support, new pattern, ambiguous context, or correction history | may summarize uncertainty; cannot create a release candidate |
| **Medium (0.70–0.89)** | supported but novel or judgment-heavy | draft proposal only; full specialist review |
| **High (≥0.90)** | source-grounded, known low-risk pattern, complete provenance, no active suppression | may prefill/adapt and route to human QA/approval |
| **Promotion candidate** | ≥30 reviewed examples in the exact scoped class; ≥95% first-pass QA; <2% factual/identity correction; zero severe incidents; stable for two review windows | may automate deterministic preparation only after policy-owner approval and canary |

Additional rules:

- Confidence never overrides a hard stop, suppression, approval expiry, route mismatch, or kill switch.
- High engagement cannot raise identity, rights, privacy, or claim confidence.
- New handles, new platforms, new model/prompt versions, and material policy changes reset the relevant promotion evidence.
- Demotion is immediate on a severe incident, route mismatch, duplicate side effect, or correction spike; promotion is deliberate and review-board approved.
- Autonomous public posting remains outside this stage. Any future proposal must name the exact low-risk class, cap, canary, rollback/compensation, and sunset date.

## 5. Suppression and kill-switch design

### Suppression scopes

Support global, brand/tenant, person/entity, source asset, claim, topic, client, platform, handle, audience/cohort, geography, campaign/version, creative, credential/resource ID, and time-window suppression.

Every suppression has: immutable ID; scope; reason; evidence; creator/approver; severity; effective/expiry time; policy version; descendants affected; appeal/review owner; and superseding record. Resolve conflicts with **most restrictive wins**. Check suppressions at ingest, selection, creative compilation, approval, immediately before launch, and during long-running journeys where the channel permits.

### Trigger examples

- **Immediate hard suppression:** privacy/rights/consent failure, wrong identity/account, deceptive persona/locality, security/credential concern, legal request, severe factual harm.
- **Pattern suppression pending review:** two similar factual/identity corrections in a rolling 30 reviewed items; rejection rate ≥25% for a scoped pattern over at least 20 reviews; negative-feedback or takedown anomaly; stale time-sensitive context.
- **Volume hold:** QA/approval backlog >1 operating day, unresolved publication reconciliation, duplicates >0, or production exceeds approved platform/handle caps.

### Kill switches

Layer global → tenant/brand → platform/channel → handle → initiative/version → cohort/batch → credential → workflow execution. Activation blocks new prepares/commits and cancels cancellable schedules while preserving evidence. Restart requires incident owner, root-cause note, affected-scope inventory, reconciliation, corrected policy/version, canary, and explicit release decision.

## 6. Rollback, compensation, and incident handling

Most public actions are not truly reversible. Distinguish:

- **Software rollback:** restore prior code/config version while maintaining data compatibility.
- **Content rollback:** restore a prior approved page/asset version when the channel supports it.
- **Operational compensation:** cancel scheduled work; pause a handle; correct, hide, delete, or annotate a post under policy; suppress further sends; preserve both original and compensating receipts.
- **Business remediation:** notify internal owners, correct downstream CRM/attribution data, document affected people/clients, and decide whether external notice is required.

Incident sequence: `STOP → SCOPE → PRESERVE → RECONCILE → COMPENSATE → VERIFY → REVIEW → CONTROLLED RESTART`.

Severity proposal:

- **S0:** private/client-data exposure, wrong accountable identity/account, deceptive persona, rights/legal breach, unauthorized public action. Global or affected-brand kill switch; Brad + designated risk owner; no automated restart.
- **S1:** materially false claim, duplicate publication, harmful context, route mismatch caught after mutation. Affected channel/handle pause; impact and compensation review.
- **S2:** broken link/caption/render, isolated stale context, provider failure with no side effect. Hold affected batch; correct and reapprove.
- **S3:** quality preference/rework with no public impact. Normal learning event.

## 7. KPI tree: intake through business outcome

Use versioned definitions and fixed observation windows. Never overwrite early metrics with later totals, mix pieces with placements, or compare platforms without preserving denominators.

| Layer | Core KPIs | Decision use |
|---|---|---|
| Intake | source assets/day; context completeness; rights-ready rate; sensitive/quarantined rate; duplicate-source rate | capture quality and usable supply |
| Selection | moments selected; selection rate; time-to-triage; reasons not selected; topic/audience mix | editorial focus, not forced utilization |
| Production | native pieces/day; variants/moment; native-change dimensions; cycle time; human minutes; cost/piece; backlog age | capacity and marginal labor |
| Quality | first-pass QA rate; edit depth; rework/reject rate; factual/identity correction rate; accessibility defects; duplicate candidates prevented | whether review burden is falling safely |
| Governance | provenance completeness; approval invalidations; expired/stale approvals blocked; suppression hits; route canaries; uncertain side effects; incidents by severity; time to reconcile | authorization and safety health |
| Distribution | approved/published/verified counts kept separate; publish success; schedule accuracy; placement duplication; platform/handle caps | reliable execution, never raw volume alone |
| Attention quality | qualified reach; watch/retention quality; saves; shares; meaningful comments; profile/site actions; negative feedback; novelty/fatigue | audience usefulness and creative signal |
| Conversation | substantive conversations; qualified inquiries; response time; escalation rate; DNC/suppression compliance | movement from attention to relationship |
| Business | meetings; opportunities; opportunity quality; owned-audience growth; attributed pipeline/revenue; attribution confidence/window | economic relevance, not vanity reach |
| Learning | experiments completed; holdout lift; accepted recommendations; false-promotion rate; promoted/suppressed patterns; learning age/expiry; reviewer disagreement | whether evidence improves decisions |

### Metric integrity contract

Each metric stores definition version, numerator, denominator, platform/handle, piece/placement unit, audience/cohort, collection method, event time, retrieval time, observation window, currency if applicable, attribution method, and missing-data state. Provider metrics are observations, not canonical facts about causality.

### G04 rollout gates carried forward

- **Phase 0/private:** 100% lineage; sensitive material quarantined; invalidation, route, idempotency, and kill-switch canaries pass; no public action.
- **24-piece pilot:** proposed ≥95% provenance; zero severe incidents; factual/identity correction <2%; rework/reject <15%; Brad review ≤45 minutes/day; backlog <1 day.
- **50–64 controlled scale:** safety gates hold; Brad review ≤30 minutes/day; ≥90% of jobs finish inside the daily window; duplicate placements = 0; queue age <1 day; at least one theme/format shows incremental qualified attention.
- **75–100 target:** minimum 20-business-day proof window; zero severe incidents; clean route/idempotency reconciliation; review and queue gates hold; qualified conversations/business signal justify marginal labor.

These are promotion gates, not guarantees. A views increase with no qualified or business improvement is not a reason to scale.

## 8. Experiment and learning protocol

1. Register one hypothesis with primary metric, guardrails, target scope, minimum sample/window, holdout/comparator, and stop rule.
2. Freeze source/concept/creative/model/prompt/policy versions for the comparison.
3. Change one main factor where practical: topic, hook, format, platform, handle, CTA, or timing.
4. Collect fixed early and later windows; retain null/missing states.
5. Exclude or annotate incidents, paid amplification, account-status changes, and materially unequal distribution.
6. Estimate effect with uncertainty; do not promote from one viral outlier.
7. Learning agent proposes `promote`, `continue`, `hold`, or `suppress` with evidence and counterexamples.
8. Human reviewer accepts, narrows, rejects, or expires the recommendation.
9. Promotion creates a new versioned rule effective only for its declared scope; it never mutates past records.
10. Re-evaluate after drift, model/platform/policy change, correction spike, or a maximum 30-day learning age for volatile distribution patterns.

## 9. Review cadence and accountability

- **Per batch:** QA, exact approval, suppression/cap/route checks, release summary.
- **Daily:** backlog, corrections/rejections, incidents, uncertain placements, negative feedback, Brad review minutes.
- **Twice weekly during pilot:** pattern review with editor, identity/handle steward, claims/rights reviewer, analyst; no views-only promotion.
- **Weekly:** scorecard by source/concept/piece/placement/platform/handle; experiment decisions; suppression and stale-learning review.
- **Monthly after stability:** policy/model/prompt changes, access roster, active handles and charters, incident themes, marginal cost vs qualified/business signal, rollback rehearsal.
- **Quarterly or material change:** rights/privacy/legal review, vendor/platform capability re-verification, disaster/compensation exercise, autonomy ceiling review.

Decision rights: Brad owns personal identity and sensitive exceptions; managing editor owns editorial priorities; identity/rights reviewers have vetoes; policy owner controls gates and suppressions; release approver authorizes exact versions; analyst recommends but cannot publish or change policy.

## 10. Minimum canary suite before any live pilot

1. Edit after approval invalidates the receipt.
2. Wrong, stale, expired, duplicate, unauthorized, and wrong-handle approvals fail closed.
3. Identity correction quarantines every descendant and removes it from pending release.
4. Rights/privacy suppression wins over high confidence and performance.
5. Duplicate queue delivery creates one prepared job and zero duplicate public side effects.
6. Simulated timeout after provider mutation reconciles before any retry.
7. Global and handle-level kill switches halt exact scopes and preserve receipts.
8. Metric windows remain separate and denominators reconcile from source → piece → placement.
9. Model/prompt version change routes through canary and cannot inherit promotion automatically.
10. One end-to-end private dry run produces complete source, decision, approval, placement-simulation, observation, and learning lineage.

A future live canary, if separately approved, should use an existing accountable handle, one low-risk piece, a hard cap of one placement, exact immutable account proof, version-bound approval, independent read-back, and tested compensation. This stage does not authorize it.

## 11. Technology boundary and implementation recommendation

Keep the design composable and vendor-neutral:

- canonical operational records and append-only decisions in durable relational storage;
- immutable large source/evidence/receipt objects in content-addressed object storage;
- durable workflows for waits, retries, approvals, pause and compensation;
- queues for fan-out only, with idempotent consumers;
- a reviewer console backed by policy APIs, never UI status as launch authority;
- replaceable AI/model and platform adapters;
- derived analytics/search indexes rebuildable from canonical records.

The local technology-intelligence library was checked at execution time (1 vendor, 20 sources, 79 capabilities, 40 case studies, 6 implementation patterns). Its narrow Cloudflare query returned zero directly relevant records, so no database record is treated as evidence for this design. Sterling’s local Cloudflare marketing-control-plane reference supports a possible Workers/Workflows + durable state/evidence implementation pattern, but lifecycle, pricing, entitlements, limits, security, and target-account routes must be reverified from current official documentation before implementation. Complementary workflow, analytics, customer-identity, content, and channel systems may be stronger for specific jobs; canonical state and approvals must remain portable.

## 12. Evidence classes, limitations, and source boundary

- **Verified Gary guidance from G01/G02/G03:** source/pillar-to-micro-content, platforms + handles, accountable locality examples, platform-native contextualization, community participation, and human review of automated engagement.
- **Gary/Vayner self-report or corporate positioning:** the 343-post claim, broad volume prescriptions, and social-first/local-learning claims. These are not audited OA output, efficiency, or business results.
- **Sterling design inference:** all schemas, confidence bands, thresholds, gates, suppression triggers, severity definitions, KPI tree, cadences, canaries, and architecture boundaries in this document.
- **Unproven:** OA’s safe sustainable daily throughput; incremental benefit of added handles; Brad review time at scale; causal lift from any content pattern; per-platform automation eligibility; and business attribution quality.

Current public source anchors carried from the bounded G02 ledger:

- https://garyvaynerchuk.com/the-garyvee-content-strategy-how-to-grow-and-distribute-your-brands-social-media-content
- https://garyvaynerchuk.com/content-marketing-strategy
- https://garyvaynerchuk.com/instagram-for-business-180-strategy-grow-business-brand
- https://garyvaynerchuk.com/here-are-five-reasons-why-automating-on-social-media-sucks
- https://vaynermedia.com/social-first-marketing-models-vaynermedia
- https://vaynermedia.com/regional-marketing-strategy-vaynermedia
- https://about.instagram.com/blog/announcements/instagram-ranking-explained
- https://newsroom.tiktok.com/en-us/how-tiktok-recommends-videos-for-you
- https://support.google.com/youtube/answer/141805
- https://www.linkedin.com/help/linkedin/answer/a702683

The mislabeled `gary-attention-deck.pdf` remains excluded: its header is HTML, not `%PDF`; no deck claim is used here.

## 13. G06 handoff

G06 should carry forward:

1. the versioned event/lineage model and material-change invalidation rule;
2. the human/agent/deterministic-worker boundary;
3. hard-stop, confidence, suppression and kill-switch rules;
4. separate approved/published/verified states and reconciliation;
5. the KPI tree and metric-integrity contract;
6. G04’s staged gates plus the G05 canary suite;
7. the explicit conclusion that 75–100/day is a gated OA hypothesis, not a Gary-proven benchmark;
8. the unresolved evidence gaps and requirement to reverify platform/vendor routes before implementation.

## Verification

- Used one bounded, deduplicated evidence set: 29 prior G01/G02 records; G03 and G04; two reusable governance/architecture references; and one narrow technology-library query.
- Defined versioned learning for edits, approvals, rejections, performance, and identity/context corrections.
- Included approval gates, confidence thresholds, suppression, rollback/compensation, provenance, KPIs from intake through business outcome, cadences, decision rights, and canaries.
- Separated verified guidance, self-report/corporate position, current platform anchors, and Sterling inference.
- Preserved human approval and prohibited unsafe autonomous posting or engagement.
- Preserved the HTML-not-PDF correction and excluded the artifact.
- No Marketing Machine file was edited and no external or live action occurred.