Skip to main content

No AI in customer-facing prose

The Hub uses AI extensively for operator support, natural-language reporting, and process interpretation. Internal engineering documentation — this bible, commit messages, code comments, error messages an operator sees, the operator's own conversations with Claude Code or the Support bubble — may name AI plainly.

In any prose a customer, vendor, or partner can read, AI is not mentioned.

The substitution​

"Our team" replaces any reference to AI in:

  • UI copy that customers see (receipts, the public website, customer-facing emails, SMS templates)
  • Marketing material
  • Partner-facing documentation
  • Sales conversations
  • Press releases
  • Vendor portals + B2B partner sites

The substitution is verbatim, not hand-wavy. "Our AI assistant generated this draft response" becomes "Our team drafted this response." "Powered by Claude" becomes nothing — no replacement is needed, because the customer doesn't need to know how it's powered.

What this is not​

  • Not a denial. AI is genuinely woven through the operator's tools. A denial — "no AI was involved" — would be incorrect.
  • Not a fear of disclosure. The audit chain records every AI call; transparency internally is unaffected.
  • Not an admission AI is inferior. It isn't.

Why​

Customers buying from a bike shop are buying a human shop's service. The shop's operator uses AI to be more capable — but the customer's relationship is with the operator, not the AI. Surfacing "an AI did this for you" reframes that relationship in a way that reduces trust, not increases it. The shop owner ran the support conversation, made the recommendation, answered the question — through tools they chose to use. The tool's nature is internal.

The same logic applies at the partner level. A vendor selling tires to Swicked relates to Swicked the business, not to Swicked-plus-Anthropic-and-OpenAI. The vendor's mental model of who they're dealing with stays clean.

This is consistent with how every other internal tool is treated. The Hub's customers don't see references to "Cloudflare Workers" on their receipts. They don't see "SQLite" in their service ticket notifications. The implementation stack is internal; the brand the customer transacts with is the shop. AI is a tool in that stack, treated identically.

What this is not blocking​

Any internal artifact may name AI plainly:

  • This bible (and every page in it)
  • Commit messages
  • Code comments and JSDoc
  • Internal admin screens (the Hub's operator surfaces)
  • Error messages an operator sees
  • The operator's own conversations with Claude Code or the AI Support bubble
  • Engineering docs, ADRs, runbooks
  • Internal Slack / chat
  • Hiring materials and engineering blog posts (engineering-team-facing only)

The constraint is the customer- or partner- facing surface. Drawing the line strictly at "could a customer or partner read this?" prevents the rule from over-reaching into engineering work.

Edge cases​

A few cases where the line gets tested:

  • A customer asks "did an AI write this?" — Answer honestly. Don't lie. The rule is about unprompted surfacing, not about denying when asked.
  • The shop owner wants to advertise "AI-powered" on their public site. — That's the shop's decision, not the Hub's. The shop can market themselves however they like; the Hub doesn't ship default copy that surfaces AI.
  • Legal or regulatory disclosure required (e.g. an automated-decision disclosure in some jurisdictions). — Compliance wins. Surface what the law requires, in the language the law requires.
  • An operator-facing surface that a customer occasionally peeks at (a tablet on the counter that's mostly operator but the customer can see). — Treat as customer-facing. The rule is conservative when ambiguous.

See also​