Implementation and operations playbooks

These playbooks turn the platform model into repeatable delivery procedures. Replace example owners and thresholds with workspace policy; do not weaken approval, evidence or isolation requirements to accelerate rollout.

Playbook 1: Launch a GEO workspace

Outcome

A workspace reaches its first trustworthy baseline and a prioritized, owned roadmap.

Procedure

1. Confirm Organization, GEO product entitlement, Tenant owner, and Workspace members.
2. Create a workspace for a coherent brand/program, environment and access boundary.
3. Add the primary domain and inspect discovery proposals before accepting targets.
4. Confirm canonical brand, website/pages, products/services/campaigns and aliases.
5. Add direct competitors and verify classification.
6. Configure markets, languages, objectives and owners.
7. Add and test a provider; select a workspace default.
8. Create representative topics, prompts and prompt sets.
9. Review request count and cost preview; set schedule budgets.
10. Run the baseline and inspect raw answers/evidence before accepting dashboard conclusions.
11. Triage findings into owned recommendations with due dates and verification plans.
12. Save an executive dashboard and schedule the required report.

Exit criteria

• No unresolved access or provider-health blocker
• Competitors included for competitive metrics
• Evidence available for every headline result
• Low-sample states visibly gated
• At least one owned action with expected lift and verification plan
• Next observation date and owner agreed

Playbook 2: Add or rotate an AI provider

Procedure

1. Choose the provider adapter and confirm endpoint/model compatibility.
2. Create a credential in encrypted storage or add a secret reference.
3. Restrict endpoint/egress policy; do not enable private-network access without review.
4. Configure capabilities such as text, vision, JSON mode or tools only when supported.
5. Run a health/capability test without exposing the credential.
6. Execute a small representative prompt set with bounded cost.
7. Review answer, citation, usage, latency and error normalization.
8. Activate the provider; make it default only after the test passes.
9. For rotation, overlap old/new credentials briefly, switch, verify and revoke the old credential.

Failure handling

• 401/403: validate credential, account/project access and provider API policy.
• 404: validate endpoint, API version and model name.
• 429: reduce concurrency, honor retry hints and revise budget/cadence.
• Timeout/5xx: use bounded backoff; do not duplicate completed observations.
• Citation mismatch: verify adapter mapping and retain raw evidence under policy.

Playbook 3: Establish a competitive baseline

1. Define the owned target and direct competitors.
2. Use category/problem/comparison prompts, not only brand-named prompts.
3. Apply the same provider, market, language, prompt set and time window.
4. Choose enough repetitions to understand answer variance.
5. Run observations and review unresolved entities before finalizing SOV.
6. Confirm denominator, sample size, confidence and low-sample threshold.
7. Annotate provider/model changes and known incidents.
8. Save the benchmark dashboard and cadence.

Do not publish a competitive ranking when competitor coverage, entity resolution or sample policy fails.

Playbook 4: Turn a finding into a verified action

Required fields

• Source finding and evidence
• Proposed change/diff
• Target, destination and scope
• Owner, approver and due date
• Impact/confidence/effort and expected lift
• Dependencies and risk class
• Idempotency key and execution window
• Verification and rollback procedure

Playbook 5: Publish website or machine-readable content

1. Select an approved recommendation and target.
2. Ground the draft only in approved, valid knowledge entries.
3. Choose page/content/FAQ/JSON-LD/llms.txt/feed format and destination.
4. Generate a new content version and review its provenance.
5. Preview the destination-specific diff.
6. Validate links, claims, structured data and accessibility where applicable.
7. Obtain approval and schedule or publish.
8. Verify destination URL, checksum/fields and visibility.
9. Start the measurement window and annotate the publication.
10. Roll back if verification or policy checks fail.

llms.txt and structured data can improve machine readability but are not universal ranking guarantees.

Playbook 6: Install tracking and validate attribution

Validation checklist

• Production and staging use separate sites/tokens.
• Allowed origins contain only intended HTTPS origins.
• Platform API keys are absent from browser code.
• Consent-denied behavior matches policy.
• URLs do not retain secret/PII-like query parameters.
• Browser and server events use shared event IDs when both send the same outcome.
• Referrer classification is reviewed; unknown sources remain unknown_ai.
• Retention and privacy-request workflow are tested.
• Attribution shows unattributed outcomes and tracking coverage.

Playbook 7: Run a campaign measurement window

Phase	Required activity
Before	Freeze target/message/claim model, capture baseline, verify tracking and define metrics/guardrails
Launch	Publish approved versions, verify destinations and add dashboard annotation
During	Monitor publication status, narrative/safety, AI referrals, run freshness and spend/cost where applicable
After	Run post-window observations, calculate lift with confidence, reconcile attribution and experiment results
Learn	Record outcome, update knowledge/roadmap and schedule follow-up measurement

Provider/model changes during the window must be annotated and may require segmented comparison.

Playbook 8: Handle provider or monitoring incidents

Do not delete failed runs to make dashboards look healthy. Preserve failure evidence, explain the affected window and create new observations/calculations.

Playbook 9: Handle failed publication or action

1. Stop automatic retries when the failure class is unsafe or unknown.
2. Inspect approval, policy, connection, destination, idempotency and external reference.
3. Determine whether the destination may have applied the change despite a timeout.
4. Perform read-after-write verification before retrying.
5. Resume only if retry is safe; otherwise move to manual reconciliation.
6. Roll back using the recorded prior version when required.
7. Verify rollback and record the incident/audit outcome.

Playbook 10: Offboard a workspace or connection

1. Disable schedules, autopilot and future publications.
2. Revoke platform keys, tracking tokens and external OAuth/credentials.
3. Export required reports and evidence under policy.
4. Resolve or cancel pending actions and delivery jobs.
5. Execute retention/privacy requirements.
6. Remove connection secret references and allowlists.
7. Confirm audit, immutable records and required aggregates remain according to policy.
8. Mark the workspace inactive; do not silently reassign its resources.

Ownership model

Responsibility	Typical owner
Target and competitor model	GEO/brand strategy owner
Provider credentials and budgets	Platform/AI operations
Prompt program and evidence review	GEO analyst/research
Knowledge and claims	Brand/legal/product owner
Content approval	Content/brand/legal approver
Channel connection and rollback	Web/CMS/channel owner
Tracking, consent and retention	Analytics/privacy owner
API keys and tenant access	Workspace/account administrator
Incident response	Platform operations with domain owner

Related documentation

• Getting started
• Integration selection guide
• Testing and troubleshooting
• Security, privacy, and governance