Connect any data source

Connecting a data source in TrailGuide is pointing the system at the data you already have, wherever it lives, and letting it learn the shape, so you never build a bespoke integration for every new tool.

TrailGuide pulls from your warehouse (BigQuery, Postgres, and others), a product database, event streams, or a zero-copy data hub. It reads what is there, maps it to a shared vocabulary, and hands that to everything downstream. Bring your own warehouse, and the platform meets your data where it already sits.

Point it at your data

The first step is connection, not migration. You give TrailGuide access to a source and it introspects the schema: the tables that exist, the columns on each, and the types they hold. Nothing has to be copied into a proprietary store as a precondition, because the whole point is to read the data you already keep.

This is why any source is meant literally. A cloud warehouse, an operational Postgres, a stream of events, and a zero-copy hub are all just shapes to be read and understood. What changes between them is the mapping, not the machinery, so adding a second or third source later is the same short step as the first.

It learns the shape with a semantic model

Raw tables are not enough on their own, because every company names things differently. The step that makes the data usable is the semantic model: a mapping from your specific tables and columns to well-known roles the platform understands, such as a member, an event, a subscription, or a last-active timestamp.

Once a column is mapped to a role, everything above it can speak in plain concepts instead of your column names. A segment can ask for members active in the last 30 days without anyone hand-writing which table and which column that means.

{
  "member": { "table": "users", "id": "user_id" },
  "last_active": { "table": "sessions", "column": "started_at" },
  "subscription": { "table": "subs", "status": "state" }
}

That mapping is the semantic model in miniature: your names on the left, the roles the platform reasons about on the right.

Authored headlessly through MCP

You do not click through a wizard for any of this. The whole flow is a set of MCP tools, so you drive it in plain language from Claude or any client. There are tools to discover a schema, read a schema in detail, get the current semantic model, and set a new one.

• Discover schema: enumerate the tables and columns a source exposes.
• Read schema: inspect one table in detail, with its column types.
• Get semantic model: see the current mapping of tables to roles.
• Set semantic model: save or update how your data maps to roles.

Together they form a simple loop: discover what exists, read the parts that matter, get the current mapping, and set the mapping, all in conversation rather than through a form. A person and an agent walk the exact same loop.

Discover the schema on our warehouse connection, then map the
users and sessions tables to member and last_active, and show me
the semantic model you saved.

Because the flow is MCP-native, the mapping a person authors this way is the same mapping an agent can propose, review, or extend. It is not a bespoke connector built per tool. It is a reading of the data you already have.

Why this is the keystone

Every capability above the data depends on this one step. Segments, personalization, journeys, and sends only work if they run on your real data, described in terms the system understands. The semantic model is what makes that possible without a migration or a rebuild. Get the mapping right once and the same audiences, endpoints, and sends light up on your data without any further wiring.

It is also what makes the rest of the harness portable across companies. Once your sources are mapped, precise boolean audiences and everything downstream operate on your live data, and the whole team is working from one shared picture of who your members are.