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/moorfrom $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_idfor 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_attributionsjoined to revenue tables. - For real conversion attribution, use the DB.
conversion_attributionsjoined 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/) andgetUnsubscribeHeaders()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.
Paid ads & data
- 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/andapps/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)
- Before producing anything, verify your action is on the autonomy table at the top. If it's not on the table, default-deny.
- Before shipping copy, run the off-voice checklist in
brand-voice.mdand the forbidden-terms list inglossary.mdand the claims/pricing list above. - 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.
- If you encounter customer data, treat it as read-only context. It does not appear in outputs that leave the system.
- If a task feels like it's drifting toward customer communication, member communication, app/database action, or autonomous business operation — stop. That's a hard prohibition. Surface it for human review before proceeding.
- 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.
Related docs
docs/marketing/brand-voice.md— voice principles, tone, vocabulary shelf-lifedocs/marketing/glossary.md— shared vocabulary, settled vs. open termsdocs/marketing/icp.md— Ideal Customer Profile- (forthcoming)
docs/marketing/positioning.md— what we displace - (forthcoming)
docs/marketing/channels.md— channel strategy, paid ads operational rules