Stampede is a graph database. Forty-four entities across eight layers, one hundred and seventy-six named relationships, three hundred and seventy-four fields. Customer, Organization and Venue are the spine; every other entity attaches via an edge with its own properties.
The choice was deliberate. Hospitality is dense with cross-references — bookings to orders, guests to venues, gift cards to senders, reviews to keywords. Modelled as a relational schema with foreign keys, the queries are slow and the joins are expensive. Modelled as a graph, every cross-reference is constant-time and every relationship carries its own state.
Derived fields are nodes, not views
The seven AI-derived fields — ChurnRisk, LifetimeValue, LoyaltyScore, CustomerInfluence, CampaignResponder, WifiProfile, VenueIntelligence — are first-class nodes attached to the Customer or Venue node. Each carries a confidence score and a derivation chain naming every source signal that produced it.
That choice trades storage for explainability. When a stakeholder asks "why is this guest at high churn risk", the answer is in the derivation chain, not in a model weight.
Exports & integrations
Subject-access exports run on demand for any Customer. Bulk exports run weekly to a venue-supplied destination (CSV to S3 or BigQuery dataset by request).
Webhook integrations fire on a defined set of edge events — visit landed, campaign opened, review filed. The webhook payload is the affected sub-graph, not the full record.
Start at /docs/reference/schema for the canonical entity reference and /docs/guest-profile/relationships for the edge model.