1. Registered and attended are separate
Approved, pending and going are registered. Only a check-in (CHECKED_IN) is attended. Never mark a whole guest list attended, never report sign-ups as attendance, and never thank someone for attending on an RSVP alone.
2. Null is unknown, never zero
A missing value isnull with a named gap. Report it as unknown. A fact with no source is a gap, not a zero, an empty list or a guess.
3. Facts, not scores
heyBTW serves facts with a basis. It returns no score, tier, rank, weight or priority. Where rows have an order, the response names the rule (metadata.ordering), and position means that rule and nothing more. The user and the workflow decide what matters.
4. CRM data stays in the CRM
heyBTW stores references and join keys, never deal stage, owner or amount copied from the user’s own connector. There are two routes to a CRM:- The user’s own CRM connector in their client. It answers owner, deal and activity questions, joined to heyBTW on
emailandcompany_domain. It needs no setup in heyBTW. - A CRM connected inside heyBTW. It lets heyBTW compute pipeline attribution and follow-up status itself.
crm_context on every CRM-dependent response says which route applies. If heyBTW returns a gap because no CRM is connected inside it, say so. Never substitute a number of your own under heyBTW’s name.
5. heyBTW never sends, with two named exceptions
Through MCP, heyBTW never sends a message and never writes to a customer system. It sends only two things, each described by its tool and confirmed by the user first: a Luma invite send (activate_list) and a collab co-host invitation email (manage_collab_partners). heyBTW never adds guests to an event platform’s guest list. Every other send goes through the user’s own mail, Slack or CRM connector.
6. The event-history ladder
An event’s history reaches heyBTW one of three ways, best first:
Every import names what it did not bring in
import_gaps (partners, attendance, registration answers), each with the tool that fills it.
7. Nothing is attributed before the event day
An event that has not happened has no attributed pipeline. The open pipeline of the accounts registered for it is served under its own name,registered_account_pipeline, and is never reported as sourced, influenced or won.
8. A person’s location never comes from their company
Location is the person’s own city, with its source (imported_declared, registration, enrichment, event-derived). A company headquarters is never a person’s location, and an event city is where someone attended, not where they live. Distance is a band, never miles.
9. Per-person invite records only for targeted sends
A targeted invite is recorded per person, so heyBTW can say who was invited and what came of it. A mass send is recorded as a count.activate_list defaults to per-person records up to 2,500 recipients and a count above that (invite_log).
10. Relay what heyBTW says as written
When a coverage note says “tell the user … as written”, relay that sentence word for word. Read clock values (event_tense, days_until, event_window, pace) as served; never compute them yourself. End a workflow with the counts, then what could not be carried: unmatched people, refused tools, declined asks.
Connector routing in one line
heyBTW holds the record (who registered and attended, who brought them, partner overlap, Lists, observations, tasks). The user’s own connectors act (CRM lookups and writes, mail and Slack sends, calendar holds). A tool whose next step lives outside heyBTW says so in acarry block or a “Carry to:” line, naming the destination and the join key.