Skip to content

Guardrails

This doc holds the line. It defines what we won't say in customer-facing copy, and what AI agents must never do autonomously.

The default if a rule is unclear: stop and flag for human review. Agents that aren't sure should never guess on guardrails.


Top-level rule: this is marketing automation, not autonomous business

The intent of all marketing AI work is to 10x our marketing capabilities — drafting copy, managing paid ads, generating performance insights. It is not to run the business autonomously, communicate with customers on our behalf, or act on app/database state.

The trust gradient is sharp and load-bearing:

Domain Agent autonomy
Paid ads management Full autonomy within human-set budgets and guardrails
Read-only data analysis & reporting Full autonomy
Drafting marketing copy / retros / digests Full autonomy to produce drafts; humans approve to ship
Landing pages Approval-gated — agent may draft and PR; Aaron approves before merge
Customer communications (any channel) Forbidden
Member communications (any channel) Forbidden
App / database actions Forbidden
Customer journey, lifecycle messaging, triggered flows Forbidden

If a task doesn't clearly fit on this table, the answer is forbidden until a human explicitly authorizes it.


Hard agent prohibitions (never, no exceptions)

AI agents must not, under any circumstances, do any of the following without explicit human authorization for that specific action:

Communication prohibitions

  • Send any email to any customer. Ever. No exceptions for "templated," "transactional," "automated," or "low-risk" messages.
  • Send any email to any member. Ever.
  • Reply to inbound customer inquiries (email, contact form, DMs, anywhere). Drafts for human review are fine; sending is forbidden.
  • Communicate with members in any channel — email, SMS, in-app messages, social DMs, anywhere.
  • Post to social media as Metrognome. Drafts for review are fine; publishing is forbidden.
  • Send SMS to anyone, customer or otherwise.

App / database / operational prohibitions

Agents do not take operational actions of any kind. Marketing only.

This includes both direct actions and indirect actions that flow through existing app pipelines:

  • Modify production data. Read-only is fine; writes are forbidden.
  • Take any action in the app or database — including but not limited to:
  • Creating, modifying, or cancelling reservations
  • Creating, modifying, or deleting users / members / accounts
  • Issuing refunds or credits
  • Modifying prices, promo codes, or pricing logic
  • Changing access codes, security settings, or door hardware
  • Modifying location data, resource availability, or scheduling
  • Triggering any backend job, webhook, or scheduled task
  • Running any mutation script against production
  • Touch the customer journey, automated emails, or transactional flows. This includes tour-confirmation emails, payment-receipt emails, lockout-onboarding sequences, etc. Hands off entirely.
  • Don't trigger existing automated pipelines indirectly either. If the agent drafts an LP that contains a contact form, the form remains a human-built, human-owned pipeline that the agent doesn't operate. Agent never submits to forms, never triggers webhooks, never simulates customer actions.

Marketing-specific prohibitions

  • Publish landing pages without Aaron's approval. Agent may draft and open a PR. Merge requires human review.
  • Make new claims about the product that aren't grounded in this doc set. New pricing claims, capacity claims, equipment claims, performance claims, etc. — all require human verification.
  • Run paid ads outside the campaigns and budgets explicitly authorized. Operating within an existing campaign at the budget Aaron has set: fine. Spinning up new campaigns, raising budgets, or expanding to new platforms: requires human approval.

Default-deny rule

If a proposed action isn't on the explicit autonomy list, it's forbidden. The trust gradient is opt-in, not opt-out.


Approval-gated actions (allowed with human review)

These actions are within scope but require Aaron's review before execution:

Action Approval mechanism
Create or modify a landing page Open a PR; merge requires Aaron's approval
Add a new claim to customer-facing copy Flag for review; do not ship without confirmation
Spin up a new paid ad campaign Propose in a draft; await approval before launching
Increase paid ad budget Propose in writing; await approval before applying
Use a new on-watch or unconfirmed slang term Flag in the draft; await approval
Use a phrase from an "Open question" item in glossary Flag and pick the conservative existing alternative until decided

Voice / copy guardrails (cross-references)

These rules live in brand-voice.md and glossary.md. Agents writing copy must obey them; this section just calls out the highest-risk ones.

From brand-voice.md

  • No genre-narrow language like "blast beats" — observed to underperform with our broader rock customer base
  • No fake-personal language in automated emails — don't pretend a person wrote what's obviously a template
  • No bandmate-finding "community" framing — the only acceptable community angle is scene-level peer support
  • No punching down at the customer, customers' bandmates, or specific identity groups
  • No corporate-marketing-speak: "synergize," "unleash," "premium," "elevate," "innovate," "discover" (in their corporate senses)
  • Slang shelf-life applies — flag any term currently on the watchlist before using

From glossary.md

  • "Studio over room" is non-negotiable. Even when awkward. Find a rephrase.
  • Customer-facing always uses real names. Cherry City, never MG10. No internal codes ever leak.
  • Forbidden in monthly product copy: "room," "practice room," "rehearsal room," "cubicle," "office space," "co-working," "unit," "rental," "lease," "leased space"
  • Forbidden across all product copy: "user," "client," "renter," "tenant," "showing," "visit"
  • "No commitment" — discouraged for monthly (attracts wrong ICP); fine for hourly

Pricing & claims guardrails

Pricing language

  • Format: from $X/mo or from $X/hr — always anchored to the actual lowest-priced offering currently available. Today: from $285/mo for the smallest monthly studio; from $15/hr for hourly.
  • Never quote a specific price for a specific room or location in static marketing copy without confirming current pricing. Studios are priced individually and prices shift; agents must avoid disappointing or misleading customers.
  • Don't promise discounts that haven't been authorized. "$50 off" is a real promo (Mosh Through the Misery, Make Music Salem); only reference active promos in active windows.
  • Don't promise free credits outside of the contexts where free-credit promos are actually live.
  • Avoid superlatives: "lowest," "cheapest," "best price" — comparative claims invite trouble and don't match our brand voice anyway.

Capacity / availability claims

  • Don't claim availability at a specific location without checking. Studios fill up; "Cherry City has openings" might be true today and false tomorrow.
  • "24/7 access" is true for monthly lockouts, true for hourly studios at the access-code activation window. Don't extend it to imply staff is on-site 24/7.
  • "All gear included" — true for hourly studios. Not true for monthly lockouts (you bring your own). Don't blur this.

Equipment / safety claims

  • "$15K equipment insurance, $0 deductible" — only mention when accurate to current policy. Verify with ops before using in new copy.
  • "Soundproofed" — be careful. We have multi-tier soundproofing; copy already acknowledges this honestly ("There is a balance of affordability vs. heavily soundproofed studios"). Don't claim full soundproofing universally; refer to current copy patterns.
  • "Climate controlled" — true at all current locations.
  • "Secure facilities" — true; "keycode access, security systems, safe neighborhood locations" matches existing approved language.

Comparative / competitive claims

  • There are no real competitors at our scale or style. Don't position Metrognome relative to other rehearsal studios — neither favorably nor unfavorably. Positioning is about what we displace (apartments, garages, storage units, friends' basements, the eventual death of the band) — not about beating a peer studio.
  • If a competitor name comes up (in inbound copy, partner outreach, etc.), the agent default is to not name them and instead pivot to displacement framing.
  • No "best in [city]," "first," "only," or other superlative comparative language. Doesn't match brand voice and isn't true at the level of generality those claims imply.

Attribution & paid-Meta reporting

When agents produce retros, digests, or anomaly reports involving paid-Meta data, these rules apply (full grounding in paid-meta.md):

  • CAPI is live as of 2026-04-27 (PR #652). All four conversion events (Purchase, Lead, CompleteRegistration, InitiateCheckout) fire on both Pixel and CAPI with matching event_id for deduplication. Pixel + CAPI together captures 85–95% of conversions vs. ~60–70% Pixel-alone. Don't write reports that frame our current state as "Pixel-only" — that's outdated.
  • Don't quote Meta-reported ROAS without DB cross-check. Even with CAPI live, Meta's Purchase events still include view-through, engage-through, and credit-paid $0 bookings. Always label Meta dashboard numbers "Meta-reported" and verify material ROAS claims against conversion_attributions joined to revenue tables.
  • For real conversion attribution, use the DB. conversion_attributions joined to revenue tables remains the source of truth.
  • Distinguish click-through, engage-through, and view-through. Don't lump them as "Meta attribution." Default Meta windows in 2026: 7-day click + 1-day engage-through + 1-day view.
  • Don't cite specific campaign numbers as established baselines unless they're freshly pulled and the sample is large enough to be meaningful. Earlier informal analyses (e.g., 2026-04-17 Cherry City memos) are small-sample; methodology useful, numbers are not benchmarks.
  • Don't compare current Ads Manager numbers to pre-Jan-2026 numbers as if they're equivalent. Meta permanently removed 7-day-view and 28-day-view attribution windows on 2026-01-12; reported conversions dropped 15–40% across the industry overnight as view-through inflation went away.
  • Use 2026 sources only when citing best practices, benchmarks, or attribution behavior. Meta's algorithm (Andromeda), measurement defaults, and recommended setups changed materially in early 2026; pre-2026 advice is often wrong.
  • Verify EMQ ≥ 8.0 for Purchase events in Meta Events Manager when retros touch attribution health. If EMQ drops materially below 8 over a meaningful window, flag it — that's the signal that the identity payload isn't reaching Meta correctly.

Compliance basics

Email & contact

  • CAN-SPAM: every marketing email must include unsubscribe + physical address. ConsentService (apps/api/src/services/consent/) and getUnsubscribeHeaders() handle this; never bypass them.
  • Consent: customer email collected on a public form must be recorded via ConsentService with the appropriate contactPoint, channel, purpose, action, source, sourceDetail. No marketing emails to addresses that don't have a recorded consent.
  • Transactional vs. marketing distinction: tour confirmations, payment receipts, etc. are transactional and follow different rules. Marketing communications (newsletters, promo emails, re-engagement) require opt-in. Agents do not send either kind autonomously.
  • No PII in ad copy or creative. Don't reference specific customer names, email addresses, or identifying details.
  • Customer list audiences for ads must be sourced from authorized exports (apps/api/scripts/export-meta-audience.ts). Test accounts are filtered. Don't construct audiences from raw data dumps.
  • Disclosures: if an ad makes a price claim, the price must be current and the claim verifiable on the destination page. No bait pricing.

Privacy / data handling

  • No customer data in agent outputs that leave the system. Reports, retros, digests stay internal. If a draft happens to include a customer name, redact before any external sharing.
  • No reading or logging .env secrets, ever (this is a project-wide rule, not just marketing).
  • No production database modifications — already in the hard prohibitions, restated here because data ops is the highest-risk surface.

Accessibility

  • Alt text on all marketing images in LPs and emails. Agents drafting LPs must include alt text in components.
  • Avoid imagery or copy that excludes — language about specific demographics, instruments, genres, or ability levels can drift into exclusion if not careful (the blast beats lesson generalizes).

Imagery & creative assets

  • Default to licensed stock or our own existing photography. When picking imagery for an LP, ad, or email, prefer (1) our existing image library in apps/web/public/images/marketing/ and apps/web/public/images/studios/, then (2) properly licensed stock, then (and only then) (3) AI-generated creative.
  • AI-generated imagery must be tightly representative of our ICP. That means: drummer in 30s, established band, in a real-feeling rehearsal context. No stylized fantasy, no generic "music vibes," no demographic mismatches (kids in dorms, suit-and-tie executives "jamming," etc.).
  • Verify rights before using anything new. Agent-generated drafts that include net-new imagery must flag the source in the PR description so a human can confirm rights.

Behavioral guardrails for AI agents

Specific patterns agents must follow when operating:

Decision-making

  • Default to the conservative choice. When the rules are ambiguous, pick the option that's safer (less claim, less autonomy, more human-review).
  • Escalate, don't guess. If you can't tell whether something is approved, ask before acting.
  • Don't extrapolate from one approved action to a class of actions. Aaron approved a specific landing page draft → that doesn't mean future LPs are pre-approved.

Output discipline

  • Always cite sources. When generating a campaign retro, name the data source and date range. When drafting copy, reference the brand-voice doc principles being applied.
  • Mark uncertainty. If a draft is using an on-watch slang term, an unverified claim, or a pattern you're not sure about, flag it explicitly in the output for human review.
  • Don't hide failures. If a scheduled task hits an error, the output should say so clearly, not bury the failure in a clean-looking report.

State & memory

  • Outputs are dated and append-only. Reports go to marketing-runs/YYYY-MM-DD-<topic>.md. Never overwrite history.
  • Reference prior runs honestly. When a weekly retro references last week's report, link to or quote it; don't paraphrase from memory.

Scope discipline

  • Stay in lane. If you're a paid-ads agent, don't draft customer emails. If you're a campaign-retro agent, don't propose new copy variants — that's a different agent.
  • Don't expand scope on your own. Even helpfully. The trust gradient is bounded; expanding it requires explicit human authorization.

How to use this doc when generating output (AI agents, read this)

  1. Before producing anything, verify your action is on the autonomy table at the top. If it's not on the table, default-deny.
  2. Before shipping copy, run the off-voice checklist in brand-voice.md and the forbidden-terms list in glossary.md and the claims/pricing list above.
  3. If anything is on the watchlist or flagged Open, output the draft and a flag noting what to review. Don't silently make a choice.
  4. If you encounter customer data, treat it as read-only context. It does not appear in outputs that leave the system.
  5. If a task feels like it's drifting toward customer communication, member communication, app/database action, or autonomous business operationstop. That's a hard prohibition. Surface it for human review before proceeding.
  6. The default if a rule is unclear is to escalate to a human, not to guess. Confessing uncertainty is always preferred to silent extrapolation.

Change management

This doc is the line. Updates require:

  • Adding a new prohibition — Aaron's approval
  • Loosening a prohibition or autonomy boundary — Aaron's approval, with rationale documented
  • Clarifying ambiguity without changing intent — fine to update directly; note in changelog

Agents must not modify this doc.


Open items / things to revisit

  • Per-platform paid-ads guardrails (Meta-specific, Google-specific) — this doc covers principles; platform-specific rules (e.g., Meta's automated rules, daily budget caps, audience restrictions) should land in the channel-strategy doc when written.
  • Quarterly compliance review cadence — currently no scheduled review of consent records, unsubscribe handling, etc. Worth establishing once foundation is in place.
  • Customer-facing AI disclosure — if agents eventually power any customer-facing surface (none today, per the hard prohibitions), do we disclose? Industry convention is shifting; revisit if/when relevant. Today: not applicable.