Twilio Segment vs mParticle

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Twilio Segment—none0/10

   No evidence of an llms.txt file or agent-oriented documentation; a direct probe for markdown-based docs (segment.com/docs/.md) returned HTTP 404, confirming absence rather than just lack of mention.

   • [probe] “PROBE docs-md: HTTP 404 at https://segment.com/docs/.md”

   proof ↗⚑ flag

   mParticle—none0/10

   No evidence of an llms.txt file or agent-oriented documentation format; all citations point to standard human-facing docs pages with no mention of AI-agent discoverability tooling. missing for 10: llms.txt file, agent-oriented doc structure, any mention of AI-agent/LLM crawling support.

   ⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed6/10

   Segment ships a documented, token-authenticated Public API and a server-side Node SDK (analytics-node) that can perform CRUD and event tracking without any UI, and runtime probes confirm both endpoints are live and functable outside a browser context, which supports scripted/CI usage. However, there is no vendor documentation or example specifically addressing CI pipelines, headless test/automation workflows, or non-interactive workspace provisioning at scale. Missing for 10: explicit CI/CD integration guides, headless automation examples, and evidence of usage in automated pipelines beyond basic API/SDK capability.

   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge.”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”
   • [claimed-docs] “analytics.track("Order Completed", { orderId: "12345", revenue: 99.99, });”

   proof ↗⚑ flag

   mParticle~partialprobed5/10

   mParticle exposes multiple HTTP APIs (server-to-server Events API, Warehouse Sync API, Platform Audiences API) that can be invoked programmatically without a UI, and the probe confirms the events API is live, auth-gated, and the SDK installs headlessly via npm — enabling scripted/automated data operations suitable for CI-like pipelines. However, there is no evidence of a dedicated CLI, infrastructure-as-code tooling, or documented CI/CD integration patterns specifically for automation workflows. Missing for 10: a CLI or IaC tool, explicit CI/CD pipeline examples, and independent hands-on confirmation of full headless workflows beyond event ingestion.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Real-time API to drive user personalization”
   • [claimed-docs] “Audiences”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round drawn
   Twilio Segment—none0/10

   No evidence of an official Segment CLI anywhere in the evidence pack; Segment offers SDKs, a Public API, and Functions but nothing described as a CLI for AI-native workflows. missing for 10: any mention of an official CLI tool, its commands, or AI-native workflow integration.

   ⚑ flag

   mParticle—none0/10

   No evidence of an official CLI tool; only SDKs, REST/HTTP APIs, and web dashboard workflows are documented. missing for 10: any mention of an official mParticle CLI, its installation, command reference, or usage examples.

   ⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Twilio Segment✓fullprobed8/10

   Segment ships a well-documented Public API with CRUD operations across Sources, Destinations, Warehouses, and Tracking Plans, an OpenAPI spec, authentication/rate-limit/pagination docs, and official SDKs; runtime probes confirm both the Public API and tracking ingest endpoints are live and properly auth-gated. This is a mature, documented, programmatically-drivable surface suitable for AI-native automation. Missing for 10: no explicit mention of an official MCP server or AI-agent-specific tooling/examples built on top of the API.

   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle✓fullprobed8/10

   mParticle documents extensive public APIs (Events API, Warehouse Sync API, Platform API for audiences, Client SDKs) and a probe confirms the server-to-server events API is live and auth-gated as documented, with the official SDK installable via npm. missing for 10: independent third-party developer accounts of building full integrations via the API beyond the single probe, and no explicit API reference/versioning/SLA documentation cited.

   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Client SDKs”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

5. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed5/10

   Segment's Public API documentation explicitly references creating API tokens with defined 'Scope, Permissions and security' sections, and runtime probes confirm the API is cleanly auth-gated (401 without a token), indicating token-based, presumably scoped credential issuance exists. However, there's no evidence of agent-specific credential issuance, fine-grained least-privilege permission levels, or guidance for scoping tokens specifically for AI-agent use cases. Missing for 10: agent-specific credential/token guidance, detailed enumeration of scope granularity (e.g., read-only vs specific resource scopes), and any first-party or community confirmation of least-privilege token workflows in agentic contexts.

   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”

   proof ↗⚑ flag

   mParticle—none0/10

   Evidence only shows basic key/secret authentication gating mParticle's events API (401 on keyless POST), with no mention of scoped, least-privilege, or agent-specific credential issuance mechanisms.

   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”
   • [claimed-docs] “Warehouse Sync API Overview”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullprobed8/10

   Segment ships official SDKs (e.g., analytics.js, @segment/analytics-node) and a documented Public API with OpenAPI spec, CRUD operations, auth, rate limits, and pagination — confirmed live via runtime probes showing the SDK installs keylessly and the API is properly auth-gated. missing for 10: no evidence of AI-agent-specific SDK tooling (e.g., function-calling schemas, MCP server, or LLM-oriented client) beyond the general-purpose SDKs.

   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle✓fullprobed7/10

   mParticle publishes official client SDKs and a documented events API (docs-17, docs-1/2), and a live runtime probe confirms the @mparticle/web-sdk is installable from npm and the server-to-server events API is auth-gated and functioning as documented (mparticle-probe-rt-1). This shows a real, working official SDK/API surface a developer (AI-native or otherwise) can build against. Missing for 10: independent/hands-on corroboration beyond a single probe, and no detail on breadth of language/platform SDK coverage or AI-specific SDK tooling.

   • [claimed-docs] “Client SDKs”
   • [claimed-docs] “Send your first event to mParticle”
   • [claimed-docs] “Send events directly to mParticle”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Twilio Segment—none0/10

   The evidence pack describes Segment's Sources/Destinations model, Functions (custom JS destinations), and the Public/Profile APIs, but none of the entries explicitly document a webhook-subscription mechanism for outbound event notifications; Functions could theoretically be used to build one, but that's not the same as a documented webhook-subscribe capability. Missing for evidence: explicit documentation of a 'Webhooks' destination or event-subscription API, sample webhook payload/signature verification, or setup docs.

   ⚑ flag

   mParticle—none0/10

   mParticle's evidence covers event ingestion, audiences, integrations, and outbound partner connections, but nothing describes a webhook subscription mechanism for consuming events out of mParticle. Missing for 10: any documented webhook endpoint registration, event subscription API, or push-notification mechanism for external/AI consumers.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to mParticle
   Twilio Segment~partialclaimed3/10

   Segment's pricing page claims 'Build AI-powered audiences from a complete customer view,' suggesting some AI-driven audience/insight capability, but no docs elaborate on what AI-generated insights or suggestions actually look like, how they surface in-product, or independent corroboration of this feature working. Missing for 10: detailed documentation of AI insight generation, in-product UI examples, and independent/hands-on validation of AI-powered audience suggestions.

   • [claimed-docs] “Build AI‑powered audiences from a complete customer view”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle's marketing docs describe a natural-language audience-building feature where you 'describe the audience, journey, or growth goal' and the product 'suggests the logic to use,' plus churn/value scoring — both are AI-generated suggestion capabilities inside the product. However, this is vendor-only marketing copy with no technical documentation, UI walkthrough, or independent/hands-on corroboration of how these AI suggestions actually work or perform. Missing for 10: independent or hands-on verification, technical docs on the underlying models, broader coverage of AI insights beyond audience-building.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Twilio Segment~partialclaimed5/10

   Segment supports background automations such as Audiences (auto-computed and synced from event/trait data), Functions (custom code that runs unattended to move data), and Reverse ETL (scheduled warehouse syncs), all of which execute autonomously once configured. However, these are rule-based data-pipeline automations rather than AI-driven agentic workflows, and there is no evidence of AI-native orchestration, decision-making, or agent-triggered automation. Missing for 10: evidence of AI/agent-driven automation logic, hands-on validation of autonomous run reliability, and any AI-native automation-builder tooling.

   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle supports background automations such as audience computation/activation to connected outputs, warehouse sync ingestion on schedules, and consent-based forwarding rules that run without manual intervention once configured. However, there is no evidence of AI-agentic or autonomously self-directed automation (e.g., natural-language-triggered workflows executing independently) beyond a described 'describe the audience... mParticle suggests logic' feature that is marketing copy without technical detail. missing for 10: technical documentation of autonomous/agentic triggers, evidence of AI-driven automation execution (not just audience/segment sync), independent corroboration of these automations running reliably in production.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to mParticle
   Twilio Segment—none0/10

   No evidence of a built-in AI assistant that users can delegate tasks to within Segment; docs mention 'AI-powered audiences' as a feature output, not an interactive assistant, and there's no chat/agent interface described.

   • [claimed-docs] “Build AI‑powered audiences from a complete customer view”

   proof ↗⚑ flag

   mParticle~partialclaimed3/10

   mParticle marketing mentions a natural-language feature where a user can 'describe the audience, journey, or growth goal' and mParticle suggests logic to activate it, which is a narrow AI-assisted capability rather than a general-purpose built-in assistant for delegating tasks. Missing for 10: evidence of a general-purpose conversational assistant, documentation of its scope/capabilities beyond audience building, and any independent/hands-on corroboration of it working.

   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed7/10

   Segment publishes an interactive Public API reference (docs.segmentapis.com) with a downloadable OpenAPI spec, 'Create a test request', and 'Install and use an SDK' sections, and runtime probes confirm the underlying API endpoints are live and respond with structured errors matching docs. This supports an AI-native user exploring a live, runnable API reference, though the pack lacks direct hands-on confirmation of executing the 'test request' feature itself. missing for 10: independent hands-on verification of the 'Create a test request' interactive flow, evidence of AI-specific tooling (e.g. OpenAPI-to-agent integration) beyond the spec download.

   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence pack lists many docs pages and API references but contains no mention of an interactive API reference with runnable/try-it-now examples (e.g., embedded Swagger/Postman consoles or live code sandboxes). Absence of evidence for this applicable capability yields 'none'.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullprobed8/10

   Segment's Public API reference explicitly offers a downloadable OpenAPI specification ('Download OpenAPI specification: Download'), and the API is confirmed live via runtime probe. Missing for 10: independent third-party confirmation of the spec's completeness/versioning beyond vendor docs, and no explicit mention of machine-readable spec for other APIs (e.g., tracking/Profile API).

   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence pack documents multiple mParticle APIs (HTTP events API, Warehouse Sync API, Platform Audiences API) but contains no mention of a downloadable OpenAPI/Swagger spec or any machine-readable API definition file. As a platform with extensive APIs, this axis clearly applies, but no evidence shows the capability exists.

   ⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Twilio Segment—none0/10

   No evidence pack item describes a dedicated sandbox/test workspace or environment isolated from production data; the docs only cover live API endpoints, tracking calls, and workspace CRUD without any sandbox/test-mode distinction. missing for 10: dedicated sandbox/test environment docs, guidance on isolating test events from production data, any sandbox API or flag.

   ⚑ flag

   mParticle—none0/10

   No evidence pack items mention a sandbox, staging, test environment, or non-production workspace for mParticle; the docs and probes describe production APIs (auth-gated events API) and SDK installation but nothing about isolated test data flows. This is a plausible axis for a CDP platform (workspaces/sandboxes are common), so absence of evidence yields 'none' rather than 'na'. missing for 10: any mention of a sandbox/test workspace, non-production API keys, or a documented way to isolate test events from production data.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullprobed7/10

   Segment's Public API docs explicitly include a semantic version number (73.3.0), an OpenAPI spec download, and a dedicated 'Versioning' section covering 'Accessing versions' and 'Backwards-incompatible or breaking changes,' which directly documents a deprecation/versioning policy; the live API also enforces token auth as documented (segment-probe-rt-1). Missing for 10: the actual deprecation policy text/timelines, changelog history, and independent/community confirmation that the policy is honored in practice.

   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence pack shows API references (events API, Warehouse Sync API, Audiences API) but no mention of API versioning scheme or a documented deprecation policy anywhere in the docs or probes. Missing for 10: explicit API version numbers/headers, a published deprecation/sunset policy, changelog or migration guide practices.

   ⚑ flag

Agent audiences

1. ai-native userAn agent can query customer data and create or activate audiences end to end through documented APIs or MCP — no dashboard in the loop

   weight 3 · round to Twilio Segment
   Twilio Segment~partialprobed5/10

   Segment documents strong programmatic access for querying customer data (Profile API for reading user/account profiles) and a Public API for CRUD on workspace resources, plus reverse ETL/audience-sync docs, all confirmed live via runtime probes. However, the evidence never documents an API path for programmatically *creating* or activating Audiences (Audiences/Engage are described via UI-centric building blocks like traits/computed traits, not an audience-creation endpoint), and there is no MCP server or agent-native interface mentioned anywhere in the pack. missing for 10: documented API/MCP for creating and activating audiences end-to-end, evidence of an official MCP server, independent confirmation that audience creation is dashboard-free.

   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the external_ids, traits, and events that make up a user's journ…”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle has documented platform APIs for audiences (docs-19), composable audiences (docs-20), and Warehouse Sync API for ingesting/querying data (docs-x4), suggesting some end-to-end audience creation via API is possible. However, mParticle's own docs describe connecting an audience to an activation output as requiring dashboard steps ('Navigate to Data Platform > Setup > Directory, and click the card for your audience partner of choice' — docs-x2), directly contradicting a no-dashboard activation flow, and there is no mention of an MCP server or agent-native interface anywhere in the pack. Missing for 10: an MCP server or agent-tool endpoint, API-only activation (bypassing the documented dashboard step), and any hands-on/independent confirmation of a full agent-driven query-to-activation loop.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”

   proof ↗⚑ flag

Agent pipeline

1. ai-native userAn agent can manage the pipeline itself — create sources and destinations, wire streams, inspect deliveries — through a documented API or MCP server

   weight 3 · round to Twilio Segment
   Twilio Segment~partialprobed6/10

   Segment's documented Public API supports full CRUD on Sources, Destinations, Warehouses, and Tracking Plans, and a runtime probe confirms it is live and auth-gated, giving an AI agent a genuine programmatic path to build/manage pipelines; the Profile API also lets an agent inspect resolved profiles/deliveries. However, there is no evidence of a documented or first-party MCP server, and no evidence of API endpoints specifically for inspecting delivery/event logs (only profile queries and general CRUD are documented) — missing for 10: an official MCP server, and documented delivery/event-log inspection endpoints beyond the Profile API.

   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge.”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle documents real management APIs (Platform Audiences API, Warehouse Sync API, HTTP events API) and an Integrations directory, so an agent could plausibly automate parts of the pipeline, but the docs explicitly describe connecting an audience to an output as a manual UI action ('Navigate to Data Platform > Setup > Directory, and click the card for your audience partner') rather than an API call, and there is no mention of an MCP server or agent-oriented control plane. Missing for 10: an MCP server, documented API endpoints for creating/wiring destinations and inspecting delivery status, and any hands-on evidence of agent-driven pipeline configuration.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”

   proof ↗⚑ flag

Ai assist

1. ai-native userDescribe an audience in natural language and AI builds the segment definition for review, grounded in my actual schema

   weight 2 · round to mParticle
   Twilio Segment~partialclaimed3/10

   Segment's pricing page markets 'Build AI-powered audiences from a complete customer view' (segment-docs-37), suggesting some AI-assisted audience building exists, and Audiences are built from tracked events/traits/computed traits within the actual schema (segment-docs-9, segment-docs-38). However, there is no documentation describing a natural-language interface, an AI-generated segment definition for human review, or how schema grounding works in that flow. Missing for 10: docs/screenshots of the NL prompt-to-segment workflow, evidence of a review/edit step before activation, and confirmation the AI reads the live schema rather than generic templates.

   • [claimed-docs] “Build AI‑powered audiences from a complete customer view”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle's marketing copy explicitly promises the described capability ('Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn intent into revenue-driving activation'), matching the natural-language-to-segment-definition story, and Composable Audiences docs show audience definitions are schema-grounded. However, this is only a marketing tagline with no supporting product documentation, UI walkthrough, or independent/hands-on verification of how the AI-generated segment is presented for review or how grounding in the actual schema works. Missing for 10: detailed docs/tutorial on the natural-language audience builder workflow, evidence of a review/edit step before segment creation, and independent or hands-on confirmation that it works as advertised.

   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Audiences”

   proof ↗⚑ flag

Ai decisioning

1. ai-native userAI decisioning agents pick messages, timing, and channels per customer autonomously within guardrails I set, with measurable lift

   weight 2 · round drawn
   Twilio Segment—none0/10

   Segment/Engage documentation covers audience building, identity resolution, and 'AI-powered audiences' as a pricing tagline, but there is no evidence of autonomous AI decisioning agents that select message, timing, and channel per customer within guardrails, nor any measurable lift reporting for such agentic decisions.

   • [claimed-docs] “Build AI‑powered audiences from a complete customer view”
   • [claimed-docs] “Powered by real-time data, Twilio Engage is a customizable personalization platform with which you can build, enrich, and activate Audiences…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”

   proof ↗⚑ flag

   mParticle—none0/10

   mParticle's evidence shows predictive audience scoring and natural-language audience creation (docs-15, docs-16) but nothing describing autonomous agents selecting messages, timing, or channels per customer, nor any measurable lift reporting tied to such decisioning — this is a CDP/audience-activation tool, not a decisioning/orchestration engine.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

Activation

1. marketerAudiences sync to ad platforms and engagement tools continuously, with membership entering and exiting in near-real-time

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullclaimed7/10

   Segment's Engage/Audiences product is documented to build audiences from real-time tracking events and traits and sync them continuously to hundreds of ad/engagement destinations, powered by real-time identity resolution ('Powered by real-time data, Twilio Engage', 'Audiences let you group users... sync Audiences to hundreds of Destinations'). This directly matches the marketer story of continuous audience sync with dynamic membership. missing for 10: explicit documentation/evidence of near-real-time membership entry/exit mechanics (e.g. incremental diff syncing) and independent/hands-on confirmation that ad-platform syncs actually update membership continuously rather than on a batch schedule.

   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “Powered by real-time data, Twilio Engage is a customizable personalization platform with which you can build, enrich, and activate Audiences…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Engage uses Segment Identity Resolution to take event data from across devices and channels and intelligently merge it into complete user- o…”
   • [claimed-docs] “Identity Resolution allows you to understand a user's interaction across web, mobile, server, and third-party partner touch-points in real t…”

   proof ↗⚑ flag

   mParticle~partialclaimed6/10

   mParticle's Audiences and Composable Audiences docs describe building audiences and connecting them to activation outputs (ad platforms, marketing tools) via one-click integrations, and Composable Audiences is positioned for near-real-time segment updates from warehouse data. However, the evidence doesn't explicitly confirm continuous/near-real-time sync cadence for entry/exit membership across all outputs, nor independent confirmation of sync latency in production. missing for 10: documented sync frequency/latency guarantees, independent/hands-on confirmation of near-real-time membership updates propagating to ad platforms, and clarity on which outputs support continuous vs batch sync.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Grow undersized or saturated audiences from your strongest customer behaviors, increasing addressable reach without defaulting to broad targ…”

   proof ↗⚑ flag

Audiences

1. marketerBuild audiences from traits and behavior in a visual builder — no SQL required — and see estimated size before activating

   weight 3 · round to Twilio Segment
   Twilio Segment~partialclaimed5/10

   Docs confirm Segment/Engage lets marketers build Audiences from tracking events, traits, and computed traits, syncing to destinations (segment-docs-9, 32, 38, 23), which implies a no-code audience-building experience. However, there is no explicit mention of a visual drag-and-drop builder UI or of showing estimated audience size before activation. Missing for 10: explicit evidence of the visual/no-SQL builder interface and audience size estimation feature.

   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Powered by real-time data, Twilio Engage is a customizable personalization platform with which you can build, enrich, and activate Audiences…”
   • [claimed-docs] “Engage uses Segment Identity Resolution to take event data from across devices and channels and intelligently merge it into complete user- o…”

   proof ↗⚑ flag

   mParticle~partialclaimed3/10

   Docs confirm audience segmentation and 'Composable Audiences' functionality exists (mparticle-docs-19, mparticle-docs-20, mparticle-docs-7) and audiences can be connected to activation outputs (mparticle-docs-x2), but nothing describes a no-SQL visual builder UI or an estimated-audience-size preview before activation. missing for 10: explicit evidence of a drag-and-drop/visual audience builder interface, confirmation that no SQL is required, and any feature showing estimated audience size prior to activation.

   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Engage customer cohorts”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”

   proof ↗⚑ flag

Traits

1. marketerComputed traits and predictive scores (LTV, churn or purchase propensity) are calculated on profiles and usable in targeting

   weight 2 · round drawn
   Twilio Segment~partialclaimed5/10

   Docs confirm computed traits can be built from tracking events and traits and used to build Audiences synced to destinations for targeting (segment-docs-9, segment-docs-38, segment-docs-32). However, there's only a vague pricing-page mention of 'AI-powered audiences' (segment-docs-37) with no concrete documentation of predictive scoring models like LTV, churn, or purchase propensity computed on profiles. Missing for 10: dedicated docs/feature describing predictive scoring (LTV, churn, purchase propensity) computation and how such scores are surfaced/activated in targeting, independent corroboration of predictive features working.

   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “Build AI‑powered audiences from a complete customer view”
   • [claimed-docs] “Powered by real-time data, Twilio Engage is a customizable personalization platform with which you can build, enrich, and activate Audiences…”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle's marketing pages explicitly claim scoring of churn/conversion/value ('Score likelihood to churn, convert, or grow in value, then activate audiences') and growing audiences from strongest behaviors, and Composable Audiences/Audiences API docs show how such traits could be used for targeting, but there is no first-party technical documentation describing how LTV/churn/propensity scores are computed, no worked example of a score becoming a usable trait, and no independent or hands-on corroboration. missing for 10: technical docs on the predictive-scoring model/methodology, a concrete example of a computed trait/score feeding an audience, and independent verification that these scores work as advertised.

   • [claimed-docs] “Score likelihood to churn, convert, or grow in value, then activate audiences before risk or opportunity passes.”
   • [claimed-docs] “Grow undersized or saturated audiences from your strongest customer behaviors, increasing addressable reach without defaulting to broad targ…”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use”
   • [claimed-docs] “Composable Audiences”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed6/10

   Segment supports bulk-style operations through its Public API (CRUD across Sources, Destinations, Warehouses, Tracking Plans, with documented rate limits/pagination), Reverse ETL for syncing bulk warehouse data to destinations, and the Profile API for querying entire user/account objects programmatically — all of which let an AI-native user or script operate across many items at once. However, evidence never shows a dedicated bulk/batch endpoint (e.g., bulk import/export) or explicit agent/AI-native tooling for large-scale operations, only general CRUD + rate-limit docs. Missing for 10: explicit bulk/batch API endpoints, documented batch size limits or throughput guarantees, and any AI-agent-specific bulk workflow examples.

   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data.”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle's Warehouse Sync API and Platform APIs (Audiences, Consent Filters, Data Privacy Controls) support bulk data ingestion and management across many users/events, which is the closest evidence to bulk operations, but there is no explicit documentation of a batch/bulk event API, rate limits, or multi-item CRUD operations tailored for programmatic/AI-native bulk use. Missing for 10: explicit bulk/batch endpoint documentation, batch size limits, and examples of bulk create/update/delete operations across items (e.g., audiences, users, events) in a single call.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Twilio Segment~partialclaimed5/10

   Segment's Audiences/computed traits can be built from events and traits and then synced automatically to destinations, which approximates rule-based triggering of downstream actions, and Functions allow custom event-driven transforms/sends. However, there is no documented explicit rules engine (e.g., 'if event X then do Y') or workflow/journey builder for conditional multi-step automation. Missing for 10: an explicit conditional automation/workflow engine (e.g., Journeys), documented trigger syntax for arbitrary if/then rules, and independent evidence of real-time rule-based action execution.

   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “Audiences let you group users or accounts based on event behavior and traits that Segment tracks.”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle supports conditional forwarding rules (e.g., 'do not forward if CCPA opt-out present') and audience-to-output connections that activate when audience membership criteria are met, which are rule-like automations triggered by data events. However, there's no evidence of a general-purpose rule/workflow engine for arbitrary event-triggered actions beyond consent-based forwarding and audience activation. Missing for 10: a documented general automation/rules engine (if-this-then-that style), evidence of custom action triggers beyond forwarding/audience activation, and independent confirmation of this capability working in practice.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “Composable Audiences”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Twilio Segment—none0/10

   Segment's docs describe Reverse ETL, Functions, and Audiences as internally-scheduled sync/compute jobs, but there is no evidence of an API or interface letting an AI-native user programmatically create or manage arbitrary recurring jobs/workflows. The Public API only covers CRUD on sources/destinations/tracking plans, not job scheduling. Missing for 10: any documented scheduling API, cron-like job creation, or workflow orchestration surface for AI agents.

   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence pack covers event ingestion, identity resolution, audiences, warehouse sync, and privacy controls, but nothing describes scheduling recurring jobs, workflows, or automated cadences (e.g., cron-like triggers for audience refresh or warehouse sync jobs) that an AI-native user could configure or invoke.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Twilio Segment—none0/10

   While Segment's Public API supports CRUD operations on resources like Tracking Plans, Sources, and Destinations, and the API docs mention API versioning (for backwards-compatible changes), there is no evidence of version history, review workflows, or rollback capabilities for Segment's automations (e.g., Functions, Tracking Plans, Audiences) themselves.

   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”

   proof ↗⚑ flag

   mParticle—none0/10

   No evidence in the pack discusses versioning, review workflows, or rollback of automations, audiences, or data pipelines; evidence covers event ingestion, identity resolution, audiences, integrations, and compliance controls only. This is a fair axis for a CDP with audience/workflow automation, but nothing shows version history, review/approval, or rollback capability.

   ⚑ flag

Destinations

1. data engineerRoute events to a large catalog of documented destination integrations with per-destination mapping and filtering

   weight 3 · round to Twilio Segment
   Twilio Segment✓fullprobed8/10

   Segment documents routing events to 700+ destinations via a documented Connections catalog, with Functions for custom destinations, a Spec for consistent data formatting, and a Public API for managing sources/destinations/warehouses/tracking plans; runtime probes confirm the Public API and ingest endpoints are live and functioning as documented. Missing for 10: explicit documentation/evidence of per-destination field mapping UI and filtering rules (e.g., event/property-level filters per destination) beyond general catalog and API references, and independent hands-on validation of the mapping/filtering workflow itself.

   • [claimed-docs] “Send customer data to 700+ apps”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs.”
   • [claimed-docs] “If you implement Segment using these formats, it's simple to translate your data to downstream tools.”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle~partialcommunity7/10

   mParticle documents an integrations directory ('Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks') and shows how to connect audience outputs via the Directory, plus per-destination filtering via Consent Filters and Data Privacy Controls forwarding rules (e.g., 'Do not forward if CCPA Data sale opt out is present'). Community testimony corroborates real-world fan-out to '10 other analytics providers'. However, evidence lacks a documented catalog size/list of destinations or explicit per-destination field-mapping documentation beyond Warehouse Sync's mapping guide. Missing for 10: a documented catalog count/list of destination integrations, and detailed per-destination event/field mapping docs beyond warehouse ingestion.

   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Consent Filters”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [community] “Now we have mParticle, so we can send data only to mParticle and then send it onwards to possibly 10 other analytics providers... Almost the…”

   proof ↗⚑ flag

Ingest

1. data engineerSend events server-to-server through a documented HTTP ingestion API with authentication and delivery guarantees

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed7/10

   Segment's HTTP Tracking API (api.segment.io) is documented and confirmed live with write-key authentication (returns structured 400 on invalid key), and a server-side Node SDK exists for programmatic server-to-server sends; the Segment Spec formalizes the payload format. However, explicit documentation of delivery guarantees (retry policies, at-least-once semantics, batching/queueing behavior) is not present in the evidence pack. Missing for 10: documented delivery-guarantee/retry semantics for the ingestion API, and independent verification of server-side batching reliability.

   • [claimed-docs] “analytics.track("Order Completed", { orderId: "12345", revenue: 99.99, });”
   • [claimed-docs] “analytics.track("Order Completed", { orderId: "12345", revenue: 99.99 });”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs. If…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”

   proof ↗⚑ flag

   mParticle~partialprobed6/10

   mParticle documents a server-to-server HTTP events API ("Send events directly to mParticle") and a live probe confirms it is auth-gated (401 without keys), matching documented key/secret basic auth - directly supporting server-to-server ingestion with authentication. Missing for 10: explicit documentation of delivery guarantees (retry semantics, at-least-once delivery, batching/queueing behavior) for the endpoint, and independent non-vendor confirmation of reliability under load.

   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Send your first event to mParticle”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

Sdks

1. data engineerCollect events from web, mobile, and server apps through official SDKs that implement a documented tracking spec (track, identify, page)

   weight 3 · round to Twilio Segment
   Twilio Segment✓fullprobed8/10

   Segment's docs describe a documented tracking spec (track, identify, page) applied consistently across libraries and APIs, with code examples (analytics.track) and confirmation that the ingest API is live and the official SDK installs and works. This directly matches the story of collecting events via official SDKs implementing a documented spec. Missing for 10: explicit mobile/server SDK-specific documentation snippets and independent third-party corroboration beyond Segment's own docs/probes.

   • [claimed-docs] “analytics.track("Order Completed", { orderId: "12345", revenue: 99.99, });”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs.”
   • [claimed-docs] “If you implement Segment using these formats, it's simple to translate your data to downstream tools.”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs. If…”
   • [claimed-docs] “Track once, send everywhere.”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”

   proof ↗⚑ flag

   mParticle~partialprobed7/10

   mParticle documents client SDKs, a server-to-server events API, and event-sending guides, and a runtime probe confirms the API is live and the web SDK installs and exports init — covering web, mobile, and server ingestion paths. However, the evidence never explicitly names a documented spec of track/identify/page-style methods (only generic 'send your first event' and IDSync identity docs), so full parity with that canonical spec isn't shown. Missing for 10: explicit SDK method documentation for track/identify/page calls, and independent hands-on confirmation across mobile SDKs specifically.

   • [claimed-docs] “Send your first event to mParticle”
   • [claimed-docs] “Send events directly to mParticle”
   • [claimed-docs] “Client SDKs”
   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

Sources

1. data engineerPull customer data in from third-party cloud apps and feeds — not just my own instrumented apps

   weight 1 · round to mParticle
   Twilio Segment~partialclaimed6/10

   Segment's docs state it can 'capture data from any source' and offers Functions to build custom sources for bringing in new types of data, plus Reverse ETL to pull data from warehouses into destinations, supporting ingestion beyond directly-instrumented apps. However, the evidence never explicitly names a catalog of prebuilt 'Cloud App' source connectors (e.g., Salesforce, Stripe, Zendesk feeds) or shows a hands-on example of pulling third-party cloud app data, relying instead on generic marketing claims. Missing for 10: explicit cloud-app source catalog documentation, a concrete third-party feed ingestion example, and independent/hands-on corroboration of this specific capability.

   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”
   • [claimed-docs] “Capture data from any source, enforce quality with schemas, unify customer identity, and send it to hundreds of tools”
   • [claimed-docs] “Send customer data to 700+ apps”

   proof ↗⚑ flag

   mParticle~partialprobed7/10

   mParticle's Warehouse Sync API explicitly ingests data from third-party cloud warehouses (Snowflake, Redshift, BigQuery, Databricks) into mParticle, and its Integrations directory implies broad connectivity beyond self-instrumented apps, with the runtime probe confirming the events/API endpoints are live and auth-gated. However, evidence is warehouse-centric rather than showing inbound feeds from other cloud apps (e.g., CRM, ad platforms, SaaS tools) as data sources. Missing for 10: documented inbound 'feeds' from non-warehouse SaaS/cloud apps, and independent/hands-on confirmation of Warehouse Sync working end-to-end.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

Profiles

1. data engineerQuery unified customer profiles — traits, identifiers, event history — through a documented profile API or store

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullprobed8/10

   Segment's Profile API is explicitly documented to query the entire user/account object programmatically, including traits, external_ids (identifiers), and events (history), directly matching the story; the Public API is separately documented with CRUD, auth, and a live runtime probe confirming it's a real, auth-gated endpoint. Identity Resolution/Identity Graph docs corroborate unified profile construction feeding this API. Missing for 10: independent (non-vendor) hands-on validation specifically of the Profile API's query behavior/response shape, and no evidence of query limits or SLAs.

   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”
   • [claimed-docs] “You can use this API to: * **Build an in-app recommendation** engine to show users or accounts the last five products they viewed but did…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the external_ids, traits, and events that make up a user's journ…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data.”
   • [claimed-docs] “The Identity Graph merges the complete history of each customer into a single profile, no matter where they interact with your business.”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”

   proof ↗⚑ flag

   mParticle~partialclaimed6/10

   mParticle documents IDSync as the identity-resolution framework producing a unified customer view (mparticle-docs-x1, docs-9), a 'Real-time API to drive user personalization' (docs-4) that implies profile querying, and a Warehouse Sync API/store that syncs mParticle data (including profiles) into Snowflake/Redshift/BigQuery/Databricks (mparticle-docs-x4, docs-18), giving a documented store-based path to unified profile data. However, no evidence pack item shows a concrete 'Profile API' schema or example query returning traits/identifiers/event history in one documented endpoint, so the specific query mechanics remain unconfirmed. Missing for 10: explicit Profile API reference docs with request/response schema, hands-on example querying traits+identifiers+event history together, independent developer corroboration of the API's completeness.

   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Real-time API to drive user personalization”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Get a complete view of your users”

   proof ↗⚑ flag

Stitching

1. data engineerAnonymous and known activity stitches into one customer profile across devices, with documented and configurable identity-resolution rules

   weight 3 · round drawn
   Twilio Segment✓fullclaimed8/10

   Segment documents an Identity Resolution / ID Graph that merges cookie IDs, device IDs, emails, and custom external IDs across web, mobile, server, and third-party touch-points into a single profile in real time, with Engage/Audiences and Profile API built on top for querying resolved profiles. Configurability of ID resolution rules is implied via external_ids/traits/spec but not deeply detailed with concrete rule-configuration examples. Missing for 10: hands-on/independent validation of identity stitching accuracy, and more granular documentation on customizing merge/precedence rules.

   • [claimed-docs] “Identity Resolution allows you to understand a user's interaction across web, mobile, server, and third-party partner touch-points in real t…”
   • [claimed-docs] “The Identity Graph merges the complete history of each customer into a single profile, no matter where they interact with your business.”
   • [claimed-docs] “Identity Resolution allows you to understand a user's interaction across web, mobile, server, and third-party partner touch-points in real t…”
   • [claimed-docs] “Engage uses [Segment Identity Resolution] to take event data from across devices and channels and intelligently merge it into complete user-…”
   • [claimed-docs] “Engage uses Segment Identity Resolution to take event data from across devices and channels and intelligently merge it into complete user- o…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”
   • [claimed-docs] “You can use this API to: * **Build an in-app recommendation** engine to show users or accounts the last five products they viewed but did…”

   proof ↗⚑ flag

   mParticle✓fullclaimed8/10

   mParticle documents IDSync explicitly as its identity-resolution framework for unifying known and anonymous user identities across apps/devices, with dedicated docs on managing identities, data quality enforcement, and a 'complete view of users' guide, indicating configurable identity rules are a first-party, documented capability. Missing for 10: independent/hands-on validation of identity-stitching configuration rules in practice and detail on rule customization options beyond doc titles.

   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Manage user identities with IDSync”
   • [claimed-docs] “Get a complete view of your users”
   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Twilio Segment
   Twilio Segment~partialprobed6/10

   Segment's Public API supports full CRUD over workspace resources (Sources, Destinations, Warehouses, Tracking Plans) and there's a live, auth-gated Profile API and tracking ingest API, confirmed by both docs and runtime probes. However, the UI also covers configuration areas like Audiences/Engage building, Privacy Portal/consent management, and Functions editing that aren't clearly shown to be fully API-manageable, and there's no evidence of a comprehensive 1:1 API-to-UI parity claim. Missing for 10: explicit parity documentation or evidence for Audience-building, Engage personalization, Functions creation, and Privacy Portal workflows being fully API-accessible, plus independent confirmation beyond vendor docs.

   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge.”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “Segment Public API (73.3.0) — Download OpenAPI specification: Download. The Segment Public API helps you manage your Segment Workspaces and …”
   • [claimed-docs] “The Public API reference documents Authentication (Scope, Permissions and security, Authenticating requests — Create an API token), Rate Lim…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”
   • [probe] “PROBE runtime (recorded 2026-09-08): the tracking ingest endpoint is live and self-describing — a keyless empty POST to https://api.segment.…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”

   proof ↗⚑ flag

   mParticle~partialprobed5/10

   mParticle exposes substantial API surface for core CDP workflows: event ingestion (events API), Warehouse Sync API, Audiences API, platform APIs, and IDSync are all documented and a probe confirms the events API is live and auth-gated. However, several UI-driven capabilities (data quality enforcement/dashboards, consent filter configuration, audience-output connection wizard, data privacy control panels) are described only as UI/dashboard flows in docs without clear evidence of full parity via API. missing for 10: explicit API coverage for data quality management UI, consent filter/privacy control configuration via API, audience-to-output connection via API rather than UI directory clicks, and independent confirmation that all UI actions have API equivalents.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”
   • [claimed-docs] “IDSync is mParticle's identity resolution framework, enabling you to create a unified view of your customers, with improved data governance,…”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [probe] “PROBE runtime (recorded 2026-09-08): mParticle's server-to-server events API is live and auth-gated — a keyless POST to https://s2s.mparticl…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Twilio Segment
   Twilio Segment~partialprobed6/10

   Segment documents mechanisms that support data portability in open formats — Data Storage Destinations to warehouses/S3/GCS, a Profile API for programmatic read access, and a Public API for CRUD on workspace resources — which together let a user extract their raw and profile data. However, there is no explicit 'export everything and leave' workflow, account-closure data dump, or documented guarantee against lock-in for a full departure scenario. Missing for 10: an explicit full-account/bulk export or 'leave the platform' feature, documented data formats/standards for portability, and independent confirmation that a full export actually works end-to-end.

   • [claimed-docs] “Segment offers several [Data Storage Destinations](/docs/segment/connections/storage/catalog "Data Storage Destinations") to help you store …”
   • [claimed-docs] “Segment offers several [Data Storage Destinations] to help you store your raw Segment data, including: Data Warehouses ... AWS S3 ... Google…”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data, including: Data Warehouses”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data. You can query the entire user or account o…”
   • [claimed-docs] “You can query the entire user or account object programmatically, including the `external_ids`, `traits`, and `events` that make up a user's…”
   • [claimed-docs] “The Segment Profile API provides a single API to read user-level and account-level customer data.”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Segment's Public API is live and cleanly auth-gated — a keyless GET https://api.segmentapis.com/sources…”

   proof ↗⚑ flag

   mParticle—none0/10

   mParticle documents APIs for sending data in and forwarding it to partner integrations (docs-11, docs-x2) and a Warehouse Sync feature, but the evidence shows Warehouse Sync only ingests data from a customer's warehouse into mParticle (docs-x4), not a comprehensive open-format export/backup of all stored customer data for leaving the platform. No evidence pack item documents a full data-export or account-portability mechanism.

   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”

   proof ↗⚑ flag

Observability

1. data engineerWatch events flow live and diagnose delivery failures per destination — debugger views, delivery metrics, and alerting

   weight 2 · round drawn
   Twilio Segment—none0/10

   Evidence covers Segment's sources/destinations, identity resolution, reverse ETL, and API/schema features, but nothing addresses live event debugging, per-destination delivery metrics/success-failure dashboards, or alerting on delivery failures. Missing for 10: any mention of a live event debugger view, delivery success/error rate metrics per destination, and alerting/notification configuration for pipeline failures.

   ⚑ flag

   mParticle—none0/10

   The evidence pack lists mParticle's data-quality docs and various integration/audience features but contains no mention of a live event debugger, per-destination delivery metrics, or alerting — the specific observability tooling the story asks for is absent from docs or community evidence.

   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

Consent

1. privacy leadUser consent is captured and enforced across destinations — opt-outs and consent categories are honored downstream automatically

   weight 3 · round to mParticle
   Twilio Segment~partialclaimed6/10

   Segment documents a dedicated Consent Management feature that captures end-user consent preferences and a Privacy Portal for regulatory compliance (GDPR/CCPA/HIPAA), and states it recommends Consent Management to enforce preferences related to cookies/data collection. However, evidence does not detail how consent categories map to specific destinations or confirm automatic enforcement across all 700+ downstream integrations, nor is there independent/hands-on verification of enforcement behavior. Missing for 10: technical detail on per-destination consent enforcement mechanics, evidence of opt-out actually blocking data flow to specific tools, and independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment recommends using Consent Management to enforce end-user preferences related to cookies and data collection consent”
   • [claimed-docs] “Detect and classify customer data The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”
   • [claimed-docs] “they set consent preferences, or make decisions about the types of data they want you to collect, use, and share”
   • [claimed-docs] “When an end user visits your web or mobile app, they set **consent preferences**, or make decisions about the types of data they want you to…”

   proof ↗⚑ flag

   mParticle✓fullclaimed8/10

   mParticle's Data Privacy Controls docs describe consent state (GDPR and CCPA opt-out) that can be attached to forwarding rules to block data flow to specific downstream destinations, and dedicated Consent Filters and compliance docs reinforce this as a first-class capability. Missing for 10: independent/hands-on validation that opt-outs are actually honored end-to-end across real destination partners, and detail on default vs opt-in enforcement per integration.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Consent Filters”
   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”

   proof ↗⚑ flag

Deletion

1. privacy leadProcess user deletion and suppression requests (GDPR/CCPA) and have them forwarded to connected destinations

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullclaimed8/10

   Segment's Privacy Portal explicitly supports GDPR/CCPA compliance workflows, including detecting/classifying customer data and streamlining privacy regulation responses, and Segment documents user deletion/suppression capabilities as part of its privacy tooling that propagate through its connected destinations infrastructure (which spans hundreds of tools). Missing for 10: no explicit documentation snippet showing the deletion/suppression request forwarded to destinations mechanism in detail, and no independent/hands-on verification of end-to-end deletion propagation to third-party destinations.

   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Detect and classify customer data The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”
   • [claimed-docs] “Send customer data to 700+ apps”

   proof ↗⚑ flag

   mParticle~partialclaimed6/10

   mParticle documents GDPR/CCPA compliance tooling — consent state management, consent filters, and forwarding rules like 'do not forward if CCPA data sale opt-out is present' — which supports suppression enforcement to downstream destinations. However, the evidence never explicitly names a Data Subject Request/deletion API workflow that processes and forwards actual user deletion requests to connected destinations, only consent-based suppression filtering. Missing for 10: explicit documentation of a deletion/erasure request workflow (not just opt-out/consent suppression), and independent confirmation that deletion requests actually propagate to third-party destinations.

   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Consent Filters”

   proof ↗⚑ flag

Pii controls

1. privacy leadControl PII flow per destination — hashing, masking, and field-level filtering of sensitive attributes

   weight 2 · round drawn
   Twilio Segment~partialclaimed5/10

   Segment provides a Privacy Portal, consent management, and general privacy/compliance tooling (GDPR/CCPA/HIPAA references) plus a Tracking Plan/Spec for data governance, but the evidence does not document per-destination controls like field-level hashing, masking, or selective filtering of sensitive attributes before data reaches specific destinations. Missing for 10: explicit documentation of per-destination PII transformation rules (hashing/masking configuration), field-level filtering UI or API, and independent/hands-on confirmation that these controls work as described.

   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment recommends using Consent Management to enforce end-user preferences related to cookies and data collection consent”
   • [claimed-docs] “Detect and classify customer data The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”
   • [claimed-docs] “they set consent preferences, or make decisions about the types of data they want you to collect, use, and share”
   • [claimed-docs] “When an end user visits your web or mobile app, they set **consent preferences**, or make decisions about the types of data they want you to…”

   proof ↗⚑ flag

   mParticle~partialclaimed5/10

   mParticle documents Data Privacy Controls with consent-based forwarding rules per destination (e.g., block forwarding to a partner if CCPA opt-out is present) and a general data transformation layer ('Transform data as it enters and leaves mParticle'), which together enable some per-destination control over sensitive data flow. However, there is no direct documentation shown for field-level hashing, masking, or granular PII filtering of specific attributes per destination — the evidence covers consent gating and generic transformation, not explicit hash/mask controls. Missing for 10: explicit field-level hashing/masking docs, granular attribute-level filtering examples, and independent/hands-on confirmation of these controls in practice.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”
   • [claimed-docs] “Transform data as it enters and leaves mParticle”
   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Consent Filters”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Twilio Segment—none0/10

   The evidence pack covers privacy tools, consent management, and generic data storage destinations, but nothing addresses regional/residency choice for where Segment processes or stores data. Missing for 10: explicit documentation of EU/regional workspace options, data residency controls, or geographic storage selection.

   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”
   • [claimed-docs] “Segment offers several [Data Storage Destinations](/docs/segment/connections/storage/catalog "Data Storage Destinations") to help you store …”
   • [claimed-docs] “Segment offers several [Data Storage Destinations] to help you store your raw Segment data, including: Data Warehouses ... AWS S3 ... Google…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence pack covers GDPR/CCPA consent controls and data privacy tooling but contains no mention of selectable data storage regions, data residency zones, or geographic hosting options. This is a fair axis for a CDP handling customer data, but no evidence supports it.

   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Twilio Segment
   Twilio Segment✓fullclaimed8/10

   Segment provides a dedicated Privacy Portal with data subject request/deletion tooling, consent management to control collection, CRUD API access (including delete operations) across resources, and compliance framing for GDPR/CCPA/HIPAA, giving users control over retention and deletion of customer data. missing for 10: no independent/hands-on evidence of an actual deletion workflow being executed, and no detail on data retention period configuration specifics.

   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Detect and classify customer data The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”
   • [claimed-docs] “Segment recommends using Consent Management to enforce end-user preferences related to cookies and data collection consent”
   • [claimed-docs] “they set consent preferences, or make decisions about the types of data they want you to collect, use, and share”
   • [claimed-docs] “When an end user visits your web or mobile app, they set **consent preferences**, or make decisions about the types of data they want you to…”
   • [claimed-docs] “The Segment Public API helps you manage your Segment workspaces and its resources. You can use the API to perform CRUD (create, read, update…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge.”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle documents GDPR/CCPA compliance and Data Privacy Controls (consent state, opt-out forwarding rules) which imply some data-governance capability, but the evidence pack never shows explicit retention-period settings or a documented deletion/right-to-be-forgotten API/workflow. Missing for 10: explicit data retention configuration docs, explicit deletion/erasure API or workflow, independent confirmation of deletion behavior.

   • [claimed-docs] “Ensure compliance with GDPR, CCPA, and your privacy policies”
   • [claimed-docs] “Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls... Consent state powers both GDPR con…”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round to Twilio Segment
   Twilio Segment~partialclaimed4/10

   Segment ships Consent Management and a Privacy Portal that let end users set preferences to opt out of data collection/tracking, and supports GDPR/CCPA/HIPAA compliance, which partially maps to a telemetry opt-out capability. However, this addresses opting out end-users of data tracked *through* Segment by its customers, not an AI-native developer opting out of Segment's own product usage telemetry — no evidence addresses that specific angle. Missing for 10: explicit opt-out mechanism for Segment's own usage/telemetry collection about the product itself, and any AI-agent-specific consent flow or documentation.

   • [claimed-docs] “Segment recommends using Consent Management to enforce end-user preferences related to cookies and data collection consent”
   • [claimed-docs] “they set consent preferences, or make decisions about the types of data they want you to collect, use, and share”
   • [claimed-docs] “When an end user visits your web or mobile app, they set **consent preferences**, or make decisions about the types of data they want you to…”
   • [claimed-docs] “The Privacy Portal helps streamline your response to new privacy regulations.”
   • [claimed-docs] “Segment includes a suite of privacy tools to help your organization comply with regulations like the Health Insurance Portability and Accoun…”

   proof ↗⚑ flag

   mParticle—none0/10

   The evidence describes mParticle's consent/privacy features for its customers' end-user data (GDPR/CCPA opt-out, consent filters) but contains no mention of an AI-native user opting out of mParticle's own product telemetry or usage tracking of the tool itself.

   ⚑ flag

Replay

1. data engineerReplay archived events into a new destination or backfill history when a tool is added or a pipeline breaks

   weight 2 · round drawn
   Twilio Segment~partialclaimed4/10

   Segment's docs describe Data Storage Destinations that retain raw event data in warehouses/S3, plus Reverse ETL to sync warehouse data back out to third-party destinations — together these could support backfilling a newly added tool, but no evidence pack item explicitly describes a 'replay' feature for re-sending archived Segment events into a new destination or recovering from a broken pipeline. Missing for 10: explicit replay/backfill documentation, guidance on replaying archived events specifically (vs. general warehouse storage + Reverse ETL), and any hands-on/community confirmation that replay works as expected.

   • [claimed-docs] “Segment offers several [Data Storage Destinations](/docs/segment/connections/storage/catalog "Data Storage Destinations") to help you store …”
   • [claimed-docs] “Segment offers several [Data Storage Destinations] to help you store your raw Segment data, including: Data Warehouses ... AWS S3 ... Google…”
   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data, including: Data Warehouses”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle's Warehouse Sync API lets engineers ingest historical data from a data warehouse (Snowflake, Redshift, BigQuery, Databricks) back into mParticle, which could serve as a backfill mechanism when a new destination needs historical data, and new destinations can be connected via the Integrations directory. However, there is no documented dedicated 'replay archived events' feature or explicit backfill-on-destination-add workflow. Missing for 10: explicit event-replay/backfill documentation, retention/archival guarantees for raw events, and confirmation that replayed data forwards correctly to newly added destinations.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Once you have created an audience, you must connect it to an audience output where you can activate it. Visit our Integrations page and filt…”
   • [claimed-docs] “Warehouse Sync API Overview”

   proof ↗⚑ flag

Data quality

1. data engineerA tracking plan or schema is enforced — violating events get flagged, blocked, or quarantined instead of silently corrupting downstream data

   weight 2 · round drawn
   Twilio Segment~partialclaimed4/10

   Segment explicitly markets 'enforce quality with schemas' and exposes Tracking Plans as a manageable resource via its Public API, showing schema definition and management exist, but the evidence pack contains no detail on the actual violation-handling mechanics (e.g., blocking, flagging, or quarantining non-conforming events) that the story specifically asks about — that functionality (Protocols-style enforcement) is not documented here. missing for 10: concrete documentation of violation detection/blocking/quarantine behavior, independent confirmation that non-conforming events are actually stopped or flagged rather than passed through.

   • [claimed-docs] “Capture data from any source, enforce quality with schemas, unify customer identity, and send it to hundreds of tools — without building eac…”
   • [claimed-docs] “Capture data from any source, enforce quality with schemas, unify customer identity, and send it to hundreds of tools”
   • [claimed-docs] “You can use the API to perform CRUD (create, read, update, and delete) operations at no extra charge. This includes working with resources s…”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs.”
   • [claimed-docs] “The Segment Spec provides guidance on meaningful data to capture, and the best format for it, across all of Segment's libraries and APIs. If…”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle docs reference a data-quality enforcement feature ("View and enforce your data quality"), consistent with tracking-plan enforcement, but the evidence pack gives only a title with no detail on how violating events are flagged, blocked, or quarantined. Missing for 10: documentation of actual blocking/quarantine behavior, plan validation rules, examples of violation handling, and independent confirmation it works as described.

   • [claimed-docs] “View and enforce your data quality”

   proof ↗⚑ flag

Transformations

1. data engineerTransform, filter, and enrich events in-pipeline with custom code or functions before they reach destinations

   weight 2 · round to Twilio Segment
   Twilio Segment~partialclaimed6/10

   Segment Functions let engineers write custom JavaScript to transform, filter, and enrich events (both source and destination functions) directly in the pipeline before delivery, and Reverse ETL allows custom query-based transforms from warehouses. However, evidence doesn't detail advanced transformation capabilities like conditional filtering logic, chained transforms, or destination-level insert functions in depth, nor independent/hands-on validation of Functions in production use. Missing for 10: detailed docs/examples of filtering and enrichment logic within Functions, independent hands-on confirmation of Functions reliability, and coverage of destination insert-function transform chaining.

   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Functions let you create your own sources and destinations directly within your workspace to bring new types of data into Segment and send d…”
   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle documents a 'Transform data as it enters and leaves mParticle' capability, which aligns with in-pipeline transformation before forwarding to destinations, but the evidence pack only shows a title reference with no detail on custom code/function support, filtering logic, or enrichment specifics. missing for 10: documentation of custom code/JS-based transformation authoring, examples of filtering/enrichment logic, and independent/hands-on validation of the transformation feature working as described.

   • [claimed-docs] “Transform data as it enters and leaves mParticle”

   proof ↗⚑ flag

Composable

1. data engineerRun warehouse-native: define models and audiences on tables already in my warehouse and activate them without re-collecting the data (reverse ETL)

   weight 2 · round to Twilio Segment
   Twilio Segment~partialclaimed6/10

   Segment explicitly documents a Reverse ETL feature that extracts data from a warehouse via a user-provided query and syncs it to destinations without re-collecting via SDKs, matching the warehouse-native activation ask. However, the evidence shows Audiences are built primarily from tracking events/traits/computed traits (not natively from arbitrary warehouse tables/models), so the 'define models and audiences on warehouse tables' half of the story is not clearly supported. Missing for 10: audience/model definition directly on warehouse tables, warehouse-native modeling docs, and independent/hands-on corroboration of Reverse ETL working end-to-end.

   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**. You can then sync Audiences to hundreds of [Dest…”
   • [claimed-docs] “You can build Audiences from core **tracking events**, **traits**, and **computed traits**.”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle ships a documented Warehouse Sync feature (Snowflake, Redshift, BigQuery, Databricks) with a Warehouse Sync API and SQL reference, letting engineers pull warehouse tables into mParticle for audience/profile use [mparticle-docs-x4][mparticle-docs-18]. However this is ingestion, not warehouse-native activation — the docs explicitly describe it as syncing/copying data into mParticle rather than defining models and activating audiences directly on tables in place without re-collection, which is the core of the reverse-ETL/warehouse-native story. Missing for 10: evidence of querying/modeling directly on warehouse tables without copying data into mParticle, and activation flows that bypass ingestion entirely.

   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”
   • [claimed-docs] “Warehouse Sync API Overview”
   • [claimed-docs] “Audiences”

   proof ↗⚑ flag

Warehouse sync

1. data engineerRaw events and profiles land in my own warehouse or lake (Snowflake, BigQuery, ClickHouse, S3) on a schedule I control

   weight 3 · round to Twilio Segment
   Twilio Segment~partialclaimed6/10

   Segment supports warehouse/lake delivery via Data Storage Destinations (Snowflake, BigQuery, S3, etc.) and Reverse ETL for syncing back from warehouses, but these are destination-style syncs configured within Segment rather than a fully self-controlled, schedule-driven pipeline the data engineer independently manages. missing for 10: explicit ClickHouse support, details on sync scheduling/frequency control, and independent/hands-on confirmation that raw event and profile data lands reliably in the warehouse on a customer-defined schedule.

   • [claimed-docs] “Segment offers several [Data Storage Destinations](/docs/segment/connections/storage/catalog "Data Storage Destinations") to help you store …”
   • [claimed-docs] “Segment offers several [Data Storage Destinations] to help you store your raw Segment data, including: Data Warehouses ... AWS S3 ... Google…”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data”
   • [claimed-docs] “Segment offers several Data Storage Destinations to help you store your raw Segment data, including: Data Warehouses”
   • [claimed-docs] “Reverse ETL (Extract, Transform, Load) extracts data from a warehouse using a query you provide and syncs this warehouse data to your third …”

   proof ↗⚑ flag

   mParticle~partialclaimed4/10

   mParticle's integrations page generically claims connections to 'data warehousing solutions with just a few clicks' (mparticle-docs-11), suggesting some warehouse export capability, but the only detailed warehouse-related feature in evidence — Warehouse Sync — is documented as ingesting data FROM the customer's warehouse INTO mParticle (reverse direction), not exporting raw events/profiles OUT to a warehouse on a schedule the engineer controls (mparticle-docs-x4). No evidence names Snowflake/BigQuery/ClickHouse/S3 as scheduled export destinations for raw events/profiles, and ClickHouse is never mentioned at all. Missing for 10: documented outbound/export pipeline to specific warehouses, schedule/cadence control details, and any hands-on or independent confirmation of export working as claimed.

   • [claimed-docs] “Connect your customer data to the leading marketing, analytics, and data warehousing solutions with just a few clicks.”
   • [claimed-docs] “Warehouse Sync ingests data from your own warehouse into mParticle — documented setup flows cover Snowflake, Amazon Redshift, Google BigQuer…”

   proof ↗⚑ flag