mParticle vs Jitsu

Agent access

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

   weight 2 · round to Jitsu
   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

   Jitsu✓fullprobed8/10

   A direct probe confirms llms.txt is live and served (HTTP 200) at https://docs.jitsu.com/llms.txt with a proper summary of Jitsu, and Jitsu also documents an MCP server for agent-driven pipeline management, showing genuine agent-oriented documentation surfaces. Missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully, and no broader agent-facing docs index beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.jitsu.com/llms.txt # Jitsu > Jitsu is an open-source data integration platform and a self-hostable…”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [probe] “official MCP server documented at https://jitsu.com/docs/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   proof ↗⚑ flag

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

   weight 2 · round to Jitsu
   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

   Jitsu✓fullprobed8/10

   Jitsu offers a jitsu-cli that scaffolds, tests, and deploys pipeline Functions from CI (jitsu-cli init/deploy), an HTTP API for backend/headless data sending, and an MCP server that explicitly documents authenticating via a personal API key (instead of browser flow) for CI/headless environments. Combined, these show clear support for headless/CI automation. missing for 10: no independent third-party CI pipeline example or case study showing jitsu-cli actually run inside a CI system end-to-end, and no evidence of a full OpenAPI/REST spec for scripting beyond the documented HTTP ingestion API.

   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [claimed-docs] “In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [probe] “official CLI documented at https://jitsu.com/docs/jitsu-cli”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to Jitsu
   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

   Jitsu✓fullprobed8/10

   Jitsu documents a dedicated jitsu-cli that manages workspace config objects and runs a Functions dev workflow, with init/deploy commands to scaffold and ship TypeScript projects, corroborated by both docs and GitHub README content. This is a genuine official CLI, not just a script wrapper, making it usable in agentic/CI workflows (e.g., alongside the MCP server for AI-agent pipeline management). Missing for 10: independent hands-on reviews of jitsu-cli specifically (community evidence discusses the platform broadly but not the CLI), and no detail on full command surface beyond init/deploy.

   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [claimed-docs] “jitsu-cli is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and ru…”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [github] “jitsu-cli init scaffolds a TypeScript project with tests, and jitsu-cli deploy ships it to your workspace.”
   • [github] “build and deploy them from your own repo with the Jitsu CLI — `jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli dep…”
   • [probe] “official CLI documented at https://jitsu.com/docs/jitsu-cli”

   proof ↗⚑ flag

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

   weight 3 · round to mParticle
   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

   Jitsu~partialprobed6/10

   Jitsu documents an HTTP API for sending event data (jitsu-docs-2) and a first-party MCP server that lets AI agents manage pipelines, destinations, streams, and functions (jitsu-docs-19, jitsu-probe-3, jitsu-probe-rt-1 confirms it's live), plus a CLI for workspace config (jitsu-docs-13, jitsu-gh-1). However, there is no unified, documented OpenAPI/REST spec for full product control — probes for openapi/swagger endpoints all 404 (jitsu-probe-2), so 'driving the product' is split across a data-ingestion API, a separate MCP protocol, and a CLI rather than one cohesive public API. Missing for 10: a single documented OpenAPI/REST management API covering full product configuration, and independent hands-on confirmation of programmatic control beyond data ingestion.

   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [probe] “official MCP server documented at https://jitsu.com/docs/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”
   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”

   proof ↗⚑ flag

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

   weight 2 · round to Jitsu
   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

   Jitsu~partialprobed4/10

   Jitsu supports personal API keys for headless/CI authentication and mentions 'named user API tokens with expiration' plus OAuth-protected MCP server access, suggesting some credential issuance controls, but there is no explicit documentation of scoped/least-privilege permission levels (e.g., read-only vs write, per-resource scopes) for these tokens or agent credentials. missing for 10: explicit scope/permission granularity for API tokens, documentation of least-privilege roles for agent-issued keys, independent confirmation of scoping enforcement.

   • [claimed-docs] “Audit log (SOC2-oriented) with account-activity alerts, plus named user API tokens with expiration.”
   • [claimed-docs] “In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to mParticle
   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

   Jitsu~partialprobed6/10

   Jitsu ships an official JS/Segment-compatible SDK (@jitsu/js, confirmed installable via npm in jitsu-probe-rt-2), an HTTP API, and a jitsu-cli for functions/config, which covers 'official SDK' for AI-native integration builders. However, coverage is thin for broader agentic/AI-native SDK usage: no dedicated server-side SDKs beyond HTTP API, no OpenAPI spec (404s in jitsu-probe-2), and community feedback notes higher implementation friction versus competitors like Segment (jitsu-comm-6, jitsu-comm-7). missing for 10: published OpenAPI/REST SDK spec, broader multi-language official SDKs beyond JS/HTTP, independent hands-on validation of SDK ease-of-use matching docs claims.

   • [claimed-docs] “Jitsu javascript integration is 100% compatible with Segment API.”
   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [probe] “official CLI documented at https://jitsu.com/docs/jitsu-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu is really self-hostable from source — a keyless shallow clone of jitsucom/jitsu landed the MIT LI…”
   • [community] “You've got most major ads sources that I care about, but it seems that there is a higher bar to implementation. Segment lets me just plug in…”
   • [community] “Functions are an underrated and highly powerful feature of Segment... It doesn't seem present here and that would hold a customer such as my…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   Jitsu—none0/10

   Evidence shows Jitsu can *receive* data via webhook (e.g., a Segment webhook destination sending data into Jitsu) and can deliver events to various destinations, but there is no evidence of an outbound webhook subscription mechanism that lets an AI-native consumer subscribe to Jitsu's own event stream. The MCP server evidence covers pipeline management, not webhook-based event subscription.

   • [claimed-docs] “Set up a webhook destination in Segment and send data to Jitsu and get it into your DB in real-time.”
   • [claimed-docs] “Tired of waiting 12 hours until your data is loaded to your warehouse? Set up a webhook destination in Segment and send data to Jitsu and ge…”
   • [github] “Delivery to destinations — ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and dozens of SaaS tools, streamed or micro-batched…”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to mParticle
   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

   Jitsu—none0/10

   Jitsu's AI-related evidence is limited to an MCP server that lets external AI agents configure the pipeline (create destinations, streams, edit functions) — this is agentic control of infrastructure, not the product generating insights or suggestions from the data itself. No mention of built-in generative analytics, natural-language querying, anomaly detection, or AI-derived recommendations surfaced to the user inside Jitsu.

   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [claimed-docs] “In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”

   proof ↗⚑ flag

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

   weight 2 · round to Jitsu
   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

   Jitsu~partialclaimed6/10

   Jitsu ships several mechanisms that run autonomously once configured: Functions process every incoming event without manual intervention (jitsu-docs-3, jitsu-docs-25, jitsu-docs-31), Connector syncs pull data on a schedule via Kubernetes CronJobs (jitsu-docs-41, jitsu-gh-3), and a dead-letter queue with a reprocessing worker retries failed deliveries automatically (jitsu-docs-16). These qualify as background automations that run without ongoing human action. Missing for 10: explicit scheduling/trigger configuration UI for non-self-hosted users, independent hands-on confirmation that these automations reliably run unattended over time, and clarity on how sync frequency/cadence is user-configurable.

   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “Filter, transform, and enrich events with TypeScript functions before they land.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [github] “Connector syncs — pull data *into* your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”

   proof ↗⚑ flag

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

   weight 3 · round to mParticle
   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

   Jitsu—none0/10

   Jitsu documents an MCP server that lets external AI agents control the pipeline (create destinations, edit functions, etc.), but this is the reverse of the story — it makes Jitsu controllable BY agents, not a built-in assistant users delegate tasks to within Jitsu's own UI. No evidence of an in-product AI assistant/copilot feature exists in the pack.

   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Jitsu
   mParticle~partialclaimed4/10

   Marketing copy claims a natural-language interface for building audiences ('Describe the audience, journey, or growth goal... mParticle understands the customer data behind it, suggests the logic to use'), which is a genuine NL-command capability, but it's scoped only to audience/segment creation rather than general product operation, and is unsupported by technical docs, screenshots, or independent corroboration. Missing for 10: technical documentation of the NL interface, evidence it covers broader product operations beyond audience building, and independent/hands-on verification.

   • [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

   Jitsu✓fullprobed8/10

   Jitsu documents and runtime-verifies a first-party MCP server that lets AI agents manage the pipeline directly—creating destinations, wiring streams, inspecting Live Events, and editing Functions—which is the mechanism for natural-language/agentic operation, plus a documented headless auth path for CI use. Missing for 10: independent/hands-on evidence of actual natural-language command sessions in production and more detail on the breadth of commands the MCP server understands beyond the listed pipeline actions.

   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [claimed-docs] “In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead”
   • [probe] “official MCP server documented at https://jitsu.com/docs/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   Jitsu—none0/10

   No evidence of an interactive API reference with runnable examples; only static HTTP API docs mentioning sending data via HTTP, and probes for OpenAPI/Swagger specs at Jitsu's docs domain all returned 404s.

   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Jitsu—none0/10

   A direct probe for OpenAPI/Swagger spec files at all standard locations returned 404s, and no evidence pack item documents a downloadable machine-readable API spec; only an llms.txt was found which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”

   proof ↗⚑ flag

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

   weight 1 · round to Jitsu
   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

   Jitsu~partialclaimed5/10

   Jitsu offers a functions debugger that runs on sample data (jitsu-docs-38) and a zero-config development Helm chart for spinning up the full architecture on Minikube (jitsu-docs-15), both of which let a user test pipeline logic without touching production data. However, there's no explicit documented 'sandbox environment' or staging/prod data-isolation feature, and no AI-agent-specific guidance on using these dev tools safely. Missing for 10: explicit sandbox/staging environment concept, documented separation of test vs production data stores, and AI-agent-oriented sandbox testing workflow.

   • [claimed-docs] “Jitsu comes with a functions debugger/editor that allows to run function on a sample data”
   • [claimed-docs] “Development Helm chart: deploy the full architecture to Minikube with zero configuration.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Jitsu—none0/10

   No evidence of API versioning scheme (e.g., v1/v2 endpoints) or any documented deprecation policy for Jitsu's HTTP API, MCP server, or CLI; the openapi.json probe returned 404s and no changelog entry references versioning/deprecation commitments. Missing for 10: documented API version scheme, explicit deprecation policy/notice process, evidence of backward-compatibility guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”
   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”

   proof ↗⚑ 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 drawn
   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

   Jitsu~partialprobed4/10

   Jitsu documents a real MCP server (jitsu-docs-19, confirmed live via jitsu-probe-rt-1) that lets agents manage pipeline objects — destinations, streams, functions, live events — and Profile Builder/warehouse query capabilities (jitsu-docs-11/12/34) exist for building customer profiles from event data. However, there is no documented API/MCP action specifically for creating or activating 'audiences' (segments for marketing activation) — the MCP scope is pipeline configuration, not audience management, and profile generation is not shown as agent-callable end to end. Missing for 10: explicit audience/segment creation endpoint, an 'activate audience' API or MCP tool, and evidence an agent can query already-built customer profiles/audiences via API without dashboard.

   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “`ctx.getWarehouse` - warehouse API to query your data warehouses”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”

   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 Jitsu
   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

   Jitsu✓fullprobed8/10

   Jitsu explicitly documents a hosted MCP server letting AI agents create destinations, wire streams, inspect Live Events, and edit Functions, with API-key auth for headless/CI use — and a runtime probe confirms the MCP endpoint is live and enforces OAuth/API-key auth as documented. This directly matches the story's ask for agent-driven pipeline management via MCP. Missing for 10: independent hands-on validation of an agent actually performing pipeline edits end-to-end, and a general REST/OpenAPI spec (probe found no OpenAPI endpoint) that would complement the MCP path.

   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [claimed-docs] “In CI and other headless environments the browser flow can't run. There you authenticate with a personal API key instead”
   • [probe] “official MCP server documented at https://jitsu.com/docs/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   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 mParticle
   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

   Jitsu—none0/10

   Jitsu documents destinations (incl. SaaS ad tools), streaming/micro-batched delivery, and a Profile Builder that computes customer profiles from events/traits — but there is no evidence of an audience/segment-membership construct that continuously syncs entering/exiting members to ad platforms specifically. A community reviewer even notes ad-platform destinations require more manual work than Segment's plug-and-play audience sync (jitsu-comm-6).

   • [github] “Delivery to destinations — ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and dozens of SaaS tools, streamed or micro-batched…”
   • [claimed-docs] “Send data to one of those destinations with Jitsu. Learn more about destination on docs website”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “Profile Builder generates profiles based on the traits object in identify events. You can also define custom logic for profile generation us…”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”
   • [community] “You've got most major ads sources that I care about, but it seems that there is a higher bar to implementation. Segment lets me just plug in…”

   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 mParticle
   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

   Jitsu—none0/10

   Jitsu's evidence shows a 'Profile Builder' that generates customer profiles from traits/events, but this is developer-driven (JS functions) and warehouse/SQL-oriented, not a marketer-facing visual audience builder with no-SQL segment creation or size-before-activation preview. Docs even show raw SQL as the querying mechanism (jitsu-docs-43), the opposite of a no-SQL builder. No evidence of a visual campaign/audience UI or size estimation feature anywhere in the pack.

   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “You can also define custom logic for profile generation using a JavaScript function, allowing you to leverage up to a year’s worth of user e…”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”
   • [claimed-docs] “select * from events where context_page_path = '/signup' and timestamp > now() - interval '1 day'”

   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 to mParticle
   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

   Jitsu~partialclaimed3/10

   Jitsu's Profile Builder lets you compute custom traits via a JavaScript function against up to a year of event history, which covers 'computed traits' in principle, but there is no evidence of any built-in predictive scoring (LTV, churn, purchase propensity) or ML capability — this would require the marketer to hand-roll such logic themselves, and no example or feature is documented for it. missing for 10: built-in predictive/ML scoring models, documented LTV/churn/propensity outputs, and evidence these scores flow into targeting/audience activation.

   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “You can also define custom logic for profile generation using a JavaScript function, allowing you to leverage up to a year’s worth of user e…”
   • [claimed-docs] “Profile Builder generates profiles based on the traits object in identify events. You can also define custom logic for profile generation us…”
   • [claimed-docs] “allowing you to leverage up to a year’s worth of user events data.”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”

   proof ↗⚑ flag

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

   weight 2 · round to mParticle
   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

   Jitsu~partialclaimed4/10

   Jitsu supports batching of event delivery, deduplication of repeated sends, and connector syncs that pull large volumes of data into a warehouse, plus a CLI that manages multiple workspace config objects — all of which imply some bulk/batch data handling. However, there is no explicit bulk-operation API or CLI command for acting on many discrete items (e.g., bulk edit/delete of profiles, destinations, or events) beyond individual config management. Missing for 10: a documented bulk API/CLI command operating on many items at once, evidence of batch profile/record updates, and independent confirmation of bulk workflows in practice.

   • [claimed-docs] “Sub-second speed of data delivery to your warehouse. Optional batching is also supported”
   • [claimed-docs] “Send same data as many times as you want. Jitsu will deduplicate it for you”
   • [github] “Connector syncs — pull data *into* your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [github] “jitsu-cli init scaffolds a TypeScript project with tests, and jitsu-cli deploy ships it to your workspace.”

   proof ↗⚑ flag

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

   weight 3 · round to Jitsu
   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

   Jitsu~partialcommunity6/10

   Jitsu Functions let users write custom JS/TypeScript logic that runs automatically on every event to filter, transform, or enrich it before delivery, and Profile Builder supports custom JS logic on identify events — both qualify as rule-based automatic actions triggered by events. However, this is scoped to data-pipeline transformations rather than general-purpose conditional workflows (e.g., alerts, multi-step triggers, external API calls beyond enrichment), and an early community review noted functions were seen as less mature/absent compared to Segment's equivalent feature. Missing for 10: evidence of broader conditional/multi-action rule chains beyond filter/transform/enrich, and independent hands-on confirmation of Functions' reliability in production.

   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination. These functions, written in JavaScript, provide variou…”
   • [claimed-docs] “Jitsu comes with a functions debugger/editor that allows to run function on a sample data”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “You can also define custom logic for profile generation using a JavaScript function, allowing you to leverage up to a year’s worth of user e…”
   • [community] “Functions are an underrated and highly powerful feature of Segment... It doesn't seem present here and that would hold a customer such as my…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Jitsu
   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

   Jitsu~partialclaimed4/10

   Jitsu's self-hosting docs mention that connector syncs run as Kubernetes CronJobs, implying a recurring scheduling mechanism for data pulls, but there is no evidence of a user- or AI-agent-facing API/UI to define, view, or manage custom recurring jobs/workflows beyond this infrastructure detail. Missing for 10: explicit scheduling API/config surface, AI-agent-driven schedule creation via MCP, and any documentation of configurable intervals or workflow orchestration beyond connector syncs.

   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [github] “Connector syncs — pull data *into* your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [github] “Connector syncs — pull data into your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”

   proof ↗⚑ flag

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

   weight 1 · round to Jitsu
   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

   Jitsu~partialclaimed4/10

   Jitsu's CLI workflow (`jitsu-cli init`/`deploy` from your own repo) implies git-based versioning of Functions, and the audit log with account-activity alerts supports review, while the dead-letter queue lets failed events be replayed. However, there is no documented built-in UI for viewing version history or rolling back a Function/pipeline to a prior state — versioning relies on the user's own repo, not a native Jitsu feature. Missing for 10: native version history/diff view for Functions, an explicit one-click rollback mechanism for pipeline configs, and audit-trail linkage between config changes and rollbacks.

   • [github] “build and deploy them from your own repo with the Jitsu CLI — `jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli dep…”
   • [claimed-docs] “Audit log (SOC2-oriented) with account-activity alerts, plus named user API tokens with expiration.”
   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”
   • [claimed-docs] “jitsu-cli is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and ru…”

   proof ↗⚑ flag

Destinations

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

   weight 3 · round to mParticle
   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

   Jitsu~partialcommunity6/10

   Jitsu documents delivery to major warehouses (ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3/GCS) plus 'dozens of SaaS tools' and a public destinations catalog page, with per-event filtering/transform/enrichment via Functions and per-source-to-destination connection control (jitsu-docs-30, jitsu-gh-2, jitsu-docs-45, jitsu-docs-3/25/31). However, hands-on community feedback flags a narrower/more effortful integration catalog than competitors like Segment and calls out missing granular per-event transformation power at the time of review (jitsu-comm-6, jitsu-comm-7), and no evidence quantifies catalog size or shows per-destination field-mapping docs beyond generic Functions. Missing for 10: a large documented catalog comparable to Segment/Fivetran scale, explicit per-destination field-mapping configuration docs, and independent confirmation that filtering/mapping works smoothly at scale.

   • [github] “Delivery to destinations — ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and dozens of SaaS tools, streamed or micro-batched…”
   • [claimed-docs] “Send data to one of those destinations with Jitsu. Learn more about destination on docs website”
   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “Filter, transform, and enrich events with TypeScript functions before they land.”
   • [claimed-docs] “You can control which events become active by choosing not to connect a source to a destination or by using a Jitsu Function to filter out u…”
   • [community] “You've got most major ads sources that I care about, but it seems that there is a higher bar to implementation. Segment lets me just plug in…”
   • [community] “Functions are an underrated and highly powerful feature of Segment... It doesn't seem present here and that would hold a customer such as my…”

   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 Jitsu
   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

   Jitsu✓fullprobed8/10

   Jitsu documents an HTTP ingestion API for server-to-server sending [jitsu-docs-2], with delivery guarantees such as deduplication, buffering to Kafka during warehouse downtime, and sub-second/batched delivery [jitsu-docs-7, jitsu-docs-8, jitsu-docs-9], plus a dead-letter queue with reprocessing for failed events [jitsu-docs-16]. Security/auth is covered via TLS/AES-256 encryption, SOC2 compliance, and named API tokens with expiration [jitsu-docs-22, jitsu-docs-23, jitsu-docs-17]. Missing for 10: a formal OpenAPI/API reference spec (probe found only 404s for openapi.json endpoints) and explicit documentation of per-request authentication mechanics for the HTTP ingestion endpoint itself.

   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “Sub-second speed of data delivery to your warehouse. Optional batching is also supported”
   • [claimed-docs] “Put your data warehouse in a maintenance mode? Jitsu will keep your data in a Kafka and deliver it once the warehouse is back online”
   • [claimed-docs] “Send same data as many times as you want. Jitsu will deduplicate it for you”
   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”
   • [claimed-docs] “Audit log (SOC2-oriented) with account-activity alerts, plus named user API tokens with expiration.”
   • [claimed-docs] “All customer data is encrypted at rest with AES-256 and in transit via TLS.”
   • [claimed-docs] “Jitsu is SOC 2 compliant, demonstrating our commitment to maintaining the highest standards of security and data protection.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”

   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 mParticle
   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

   Jitsu~partialclaimed6/10

   Jitsu documents a JS SDK that is '100% compatible with Segment API' (implying track/identify/page methods), a React integration, and an HTTP API for server-side event sends, plus identity-stitching and traits-based identify handling — covering web and server collection with a documented spec-like interface. However, there is no evidence of official mobile SDKs (iOS/Android) or a standalone published tracking-spec document beyond the Segment-compatibility claim. Missing for 10: dedicated mobile SDKs, explicit documented track/identify/page API reference (vs. inferred Segment compatibility), independent hands-on confirmation of SDK behavior across platforms.

   • [claimed-docs] “Jitsu javascript integration is 100% compatible with Segment API.”
   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “Once the user identity is known, Jitsu automatically amends all previous records associated with this user based on anonymous cookie-based i…”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “Jitsu javascript integration is 100% compatible with Segment API. In addition to that we have React integration”
   • [claimed-docs] “select * from events where context_page_path = '/signup' and timestamp > now() - interval '1 day'”

   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
   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

   Jitsu~partialcommunity5/10

   Jitsu explicitly advertises Airbyte-compatible 'Connector syncs' that pull data into the warehouse from third-party sources, directly matching the story, but this is only a single GitHub README line without documentation depth on which apps/feeds are supported. A community commenter also notes Jitsu has a 'higher bar to implementation' for pulling ad-platform data compared to Segment, suggesting real friction in practice. Missing for 10: detailed docs/connector catalog, first-party walkthrough of connector setup, and stronger independent corroboration that third-party pulls work smoothly.

   • [github] “Connector syncs — pull data *into* your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [github] “Connector syncs — pull data into your warehouse from third-party sources (Airbyte-compatible connectors).”
   • [community] “You've got most major ads sources that I care about, but it seems that there is a higher bar to implementation. Segment lets me just plug in…”

   proof ↗⚑ flag

Profiles

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

   weight 2 · round to mParticle
   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

   Jitsu~partialprobed5/10

   Jitsu documents a Profile Builder that generates unified customer profiles (traits, event history up to a year) stored in the warehouse, and profiles are queryable via SQL since they land in the customer's own warehouse tables, plus a Functions API (ctx.getWarehouse) to query warehouse data. However, there is no documented dedicated 'Profile API' or profile store/endpoint — access is only via the underlying warehouse SQL, and no OpenAPI/API reference for profiles was found (openapi probes 404). missing for 10: a documented profile-specific query API or SDK, dedicated identifier-resolution endpoints, independent/hands-on confirmation of profile querying beyond vendor docs.

   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “You can also define custom logic for profile generation using a JavaScript function, allowing you to leverage up to a year’s worth of user e…”
   • [claimed-docs] “Profile Builder generates profiles based on the traits object in identify events. You can also define custom logic for profile generation us…”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”
   • [claimed-docs] “`ctx.getWarehouse` - warehouse API to query your data warehouses”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”

   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 to mParticle
   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

   Jitsu~partialclaimed5/10

   Jitsu documents automatic identity stitching that amends prior anonymous records once a user is identified via cookie-based ID, and Profile Builder allows custom JS logic for profile generation, which gives some configurability. However there is no documented cross-device merging mechanism (only cookie-based, single-device) and no explicit documented rule set for identity resolution beyond the default cookie linkage. Missing for 10: cross-device identity linkage evidence, explicit documented/configurable rules for merging identities (e.g. via user ID mapping across devices), independent verification of stitching accuracy.

   • [claimed-docs] “Once the user identity is known, Jitsu automatically amends all previous records associated with this user based on anonymous cookie-based i…”
   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “You can also define custom logic for profile generation using a JavaScript function, allowing you to leverage up to a year’s worth of user e…”
   • [claimed-docs] “Profile Builder generates profiles based on the traits object in identify events. You can also define custom logic for profile generation us…”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”

   proof ↗⚑ flag

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

   weight 2 · round to Jitsu
   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

   Jitsu~partialprobed6/10

   Jitsu exposes substantial programmatic control beyond just data ingestion: an HTTP API for sending events, an official jitsu-cli for managing destinations/streams/connections and running the Functions dev workflow, and a first-party MCP server that lets AI agents create destinations, wire streams, inspect Live Events, and edit Functions — covering much of what the UI does. However, a direct probe for a public OpenAPI/REST management spec came back 404 on all candidate paths, suggesting no single comprehensive API surface documented for all UI actions (e.g., security/audit settings, billing, account admin). Missing for 10: a documented general-purpose REST/OpenAPI management API covering every UI screen (not just CLI/MCP-mediated actions), and independent confirmation that CLI/MCP truly reach full UI parity.

   • [claimed-docs] “You can use HTTP API to send data to Jitsu. This is useful if you want to send data from your backend.”
   • [claimed-docs] “`jitsu-cli` is the command-line interface for Jitsu. It manages workspace configuration objects (destinations, streams, connections, …) and …”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [claimed-docs] “Jitsu runs an MCP server, so AI agents can manage your pipeline directly: create destinations, wire up streams, inspect Live Events, and edi…”
   • [probe] “official MCP server documented at https://jitsu.com/docs/mcp”
   • [probe] “official CLI documented at https://jitsu.com/docs/jitsu-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.jitsu.com/openapi.json, https://docs.jitsu.com/swagger.json, https://docs.jitsu.com/api…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu's hosted MCP server ('Jitsu runs an MCP server, so AI agents can manage your pipeline directly: c…”

   proof ↗⚑ flag

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

   weight 3 · round to Jitsu
   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

   Jitsu~partialprobed6/10

   Jitsu is open-source and self-hostable (MIT license, Kubernetes/Helm/docker-compose deployments), and data lands directly in your own warehouse (ClickHouse, BigQuery, Snowflake, Postgres, S3) in standard formats, which supports data portability and exit. However, there is no explicit documented 'export all your data and leave' workflow, no bulk export/backup tool, and no discussion of exporting configuration/pipeline definitions or profiles data in an open interchange format beyond what lives in the warehouse. missing for 10: an explicit data-export/backup feature or docs describing full data portability/migration-out process, evidence on exporting Profile Builder or Function configs, independent confirmation of a clean full-data exit path.

   • [claimed-docs] “Run Jitsu yourself on Kubernetes with Helm, fully under your control.”
   • [claimed-docs] “Make your data warehouse the single source of truth for your data.”
   • [claimed-docs] “Make your data warehouse the single source of truth for your data. Jitsu is tailor-made for delivering the data to data warehouses as fast a…”
   • [github] “Delivery to destinations — ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and dozens of SaaS tools, streamed or micro-batched…”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu is really self-hostable from source — a keyless shallow clone of jitsucom/jitsu landed the MIT LI…”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”

   proof ↗⚑ flag

Observability

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

   weight 2 · round to Jitsu
   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

   Jitsu~partialclaimed7/10

   Jitsu's Live Events view provides a debugger showing function logs, warehouse batch statuses, streaming delivery results, and dead-lettered events, with a dead-letter queue and reprocessing worker for failed deliveries, and this data can now be exported to an external monitoring stack near real-time (Datadog, Grafana Cloud, New Relic, Elastic via OTLP). However, native alerting is limited to SOC2-oriented account-activity audit alerts, not specific per-destination delivery-failure alert rules/thresholds built into Jitsu itself. Missing for 10: first-party alerting/paging on delivery failures within Jitsu, independent/hands-on confirmation of the debugger UI in practice, and per-destination metrics dashboards beyond changelog claims.

   • [claimed-docs] “Everything you can see in Live Events — function logs, warehouse batch statuses, streaming delivery results, and dead-lettered events — can …”
   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”
   • [claimed-docs] “Records are delivered as OpenTelemetry (OTLP) log records over HTTP, so they work with Datadog, Grafana Cloud, New Relic, Elastic, or any Op…”
   • [claimed-docs] “Audit log (SOC2-oriented) with account-activity alerts, plus named user API tokens with expiration.”
   • [claimed-docs] “Jitsu comes with a functions debugger/editor that allows to run function on a sample data”

   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
   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

   Jitsu—none0/10

   No evidence anywhere in the pack describes consent capture, consent-category mapping, opt-out enforcement, or CMP/consent-signal propagation to destinations. Jitsu's Functions can filter events generically, but nothing documents this being used for consent enforcement, and no privacy/consent-specific feature is mentioned—only unrelated security/compliance items (SOC2, DPA, encryption).

   ⚑ flag

Deletion

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

   weight 2 · round to mParticle
   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

   Jitsu—none0/10

   No evidence of a documented feature for processing GDPR/CCPA user deletion or suppression requests and propagating them to connected destinations; only general security/DPA compliance mentions exist, not a deletion workflow. Missing for 10: any documented delete/suppress user API, per-user erasure workflow, or downstream forwarding of deletion requests to destinations.

   • [claimed-docs] “All customer data is encrypted at rest with AES-256 and in transit via TLS.”
   • [claimed-docs] “Jitsu is SOC 2 compliant, demonstrating our commitment to maintaining the highest standards of security and data protection.”
   • [claimed-docs] “You can access DPA (Data Processing Agreement) + SCC (Standard Contractual Clause) using this link”

   proof ↗⚑ flag

Pii controls

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

   weight 2 · round to mParticle
   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

   Jitsu~partialclaimed4/10

   Jitsu's Functions feature lets you write TypeScript/JavaScript to filter, transform, and enrich events before they reach a destination, and you can choose not to connect a source to a destination — this could be used to implement custom hashing/masking/field-filtering logic, giving privacy leads a mechanism for PII control. However, there's no dedicated, documented PII-specific feature (built-in hashing/masking primitives, a privacy policy UI, or per-destination redaction rules) — it's a general-purpose transform layer requiring custom code rather than a purpose-built privacy/consent control. missing for 10: built-in hashing/masking functions marketed for PII, per-destination privacy policy configuration, explicit field-level anonymization documentation or examples.

   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “Filter, transform, and enrich events with TypeScript functions before they land.”
   • [claimed-docs] “You can control which events become active by choosing not to connect a source to a destination or by using a Jitsu Function to filter out u…”
   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination. These functions, written in JavaScript, provide variou…”

   proof ↗⚑ flag

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

   weight 2 · round to Jitsu
   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

   Jitsu~partialprobed5/10

   Jitsu can be fully self-hosted on your own Kubernetes/infrastructure (jitsu-docs-14, jitsu-docs-41, confirmed self-hostable in jitsu-probe-rt-2), which lets a user choose exactly where data is stored, and it offers DPA/SCC for compliance (jitsu-docs-44). However there's no documented region-selection feature for the hosted/cloud offering itself (e.g., 'choose EU vs US region' toggle) — self-hosting is the only mechanism for residency control. Missing for 10: explicit hosted-cloud region/residency picker, documentation of where hosted Jitsu Cloud data lives by default, and independent confirmation of residency guarantees beyond self-hosting.

   • [claimed-docs] “Run Jitsu yourself on Kubernetes with Helm, fully under your control.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [claimed-docs] “You can access DPA (Data Processing Agreement) + SCC (Standard Contractual Clause) using this link”
   • [probe] “PROBE runtime (recorded 2026-09-08): Jitsu is really self-hostable from source — a keyless shallow clone of jitsucom/jitsu landed the MIT LI…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   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

   Jitsu~partialclaimed4/10

   Jitsu offers self-hosting (full data ownership) and mentions DPA/SCC + SOC2 compliance, which implies some control over where/how data is stored, but there is no explicit retention-policy setting or data-deletion API/feature documented anywhere in the pack. Missing for 10: documented retention window controls, a delete/erase-user-data API or UI action, and any GDPR-style right-to-be-forgotten workflow.

   • [claimed-docs] “Run Jitsu yourself on Kubernetes with Helm, fully under your control.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [claimed-docs] “You can access DPA (Data Processing Agreement) + SCC (Standard Contractual Clause) using this link”
   • [claimed-docs] “Jitsu is SOC 2 compliant, demonstrating our commitment to maintaining the highest standards of security and data protection.”
   • [claimed-docs] “All customer data is encrypted at rest with AES-256 and in transit via TLS.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Jitsu—none0/10

   The evidence pack covers Jitsu's self-hosting, security/compliance, and data-pipeline features extensively, but contains no mention of an opt-out flag, setting, or documentation for disabling Jitsu's own product/CLI usage telemetry sent back to Jitsu Inc. Self-hosting (jitsu-docs-14, jitsu-docs-41) addresses customer analytics data sovereignty, not the product's own telemetry practices.

   • [claimed-docs] “Run Jitsu yourself on Kubernetes with Helm, fully under your control.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [claimed-docs] “All customer data is encrypted at rest with AES-256 and in transit via TLS.”
   • [claimed-docs] “Jitsu is SOC 2 compliant, demonstrating our commitment to maintaining the highest standards of security and data protection.”

   proof ↗⚑ 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 to mParticle
   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

   Jitsu~partialclaimed3/10

   Jitsu's dead-letter queue with a reprocessing worker lets failed events be replayed rather than lost, covering the 'pipeline breaks' half of the story, but there's no evidence of a mechanism to replay/backfill previously archived events into a newly added destination. missing for 10: documented backfill/replay tooling for historical events into new destinations, evidence of re-streaming warehouse-stored events, independent confirmation of DLQ reprocessing in practice.

   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”
   • [claimed-docs] “Everything you can see in Live Events — function logs, warehouse batch statuses, streaming delivery results, and dead-lettered events — can …”

   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
   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

   Jitsu~partialclaimed4/10

   Jitsu's Functions can filter, block, or transform events before they reach a destination, and a dead-letter queue captures failed events for reprocessing instead of silent loss — these are the building blocks a data engineer could use to implement custom validation. However, there is no documented tracking-plan/schema-enforcement feature (e.g., defining an event schema and auto-flagging/quarantining violations) — it would require building custom Function logic. Missing for 10: native schema/tracking-plan definition, automatic validation against that schema, and dedicated quarantine flagging distinct from generic DLQ failure handling.

   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “You can control which events become active by choosing not to connect a source to a destination or by using a Jitsu Function to filter out u…”
   • [claimed-docs] “Dead-letter queue with a reprocessing worker: failed events can be replayed instead of lost.”
   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination. These functions, written in JavaScript, provide variou…”

   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 Jitsu
   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

   Jitsu✓fullclaimed8/10

   Jitsu Functions are extensively documented as an in-pipeline transformation layer: filter/transform/enrich events in JavaScript/TypeScript before delivery, with a dev CLI workflow (jitsu-cli init/deploy), a functions debugger/editor to test on sample data, and pricing docs confirming you can filter events via Functions rather than routing rules. Missing for 10: independent hands-on validation of Functions in production (the only community feedback found is an old HN comment claiming Functions were absent at launch, which predates current docs and isn't a concrete recent contradiction) and no case-study evidence of complex enrichment logic in the wild.

   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination... Filter... Transform... Enrich”
   • [claimed-docs] “Modify, filter or augment events before it is stored in your warehouse with Jitsu Functions.”
   • [claimed-docs] “Filter, transform, and enrich events with TypeScript functions before they land.”
   • [claimed-docs] “Functions are designed to process data in Jitsu before it is sent to the destination. These functions, written in JavaScript, provide variou…”
   • [claimed-docs] “Jitsu comes with a functions debugger/editor that allows to run function on a sample data”
   • [claimed-docs] “You can control which events become active by choosing not to connect a source to a destination or by using a Jitsu Function to filter out u…”
   • [github] “`jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli deploy` ships it to your workspace.”
   • [github] “jitsu-cli init scaffolds a TypeScript project with tests, and jitsu-cli deploy ships it to your workspace.”
   • [github] “build and deploy them from your own repo with the Jitsu CLI — `jitsu-cli init` scaffolds a TypeScript project with tests, and `jitsu-cli dep…”
   • [claimed-docs] “`ctx.getWarehouse` - warehouse API to query your data warehouses”

   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 mParticle
   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

   Jitsu—none0/10

   Jitsu's Profile Builder explicitly builds profiles from events data sent *to* Jitsu ('Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu'), not from pre-existing warehouse tables — the opposite of a warehouse-native, no-re-collection model. The only warehouse-read capability shown is `ctx.getWarehouse` inside Functions, which is far short of defining models/audiences on existing tables and activating them via reverse ETL. Missing for 10: any evidence of modeling on pre-existing warehouse tables, an audience-builder UI over arbitrary warehouse schemas, or activation/sync-back without first ingesting data through Jitsu's own collection pipeline.

   • [claimed-docs] “Profile Builder generates profiles based on the `traits` object in `identify` events.”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”
   • [claimed-docs] “`ctx.getWarehouse` - warehouse API to query your data warehouses”

   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 Jitsu
   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

   Jitsu✓fullclaimed9/10

   Jitsu explicitly delivers events (and Profiles) to warehouses/lakes including Snowflake, BigQuery, ClickHouse, Redshift, Postgres, S3, GCS, with both real-time streaming and optional batching, dedup, auto-schema creation, and self-hosting options that give engineers full control over the delivery cadence and infrastructure. GitHub and docs corroborate the destination list and delivery modes, and self-hosting via Helm/Kubernetes reinforces 'own warehouse' control. Missing for 10: independent/hands-on confirmation of exact scheduling granularity (batch interval configuration specifics) and clearer documentation on how 'schedule I control' maps to concrete batch/cron settings.

   • [claimed-docs] “Sub-second speed of data delivery to your warehouse. Optional batching is also supported”
   • [claimed-docs] “Put your data warehouse in a maintenance mode? Jitsu will keep your data in a Kafka and deliver it once the warehouse is back online”
   • [claimed-docs] “Send same data as many times as you want. Jitsu will deduplicate it for you”
   • [claimed-docs] “Jitsu will automatically create tables and columns in your warehouse based on the data you send”
   • [github] “Delivery to destinations — ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and dozens of SaaS tools, streamed or micro-batched…”
   • [claimed-docs] “Make your data warehouse the single source of truth for your data.”
   • [claimed-docs] “Make your data warehouse the single source of truth for your data. Jitsu is tailor-made for delivering the data to data warehouses as fast a…”
   • [claimed-docs] “Run Jitsu yourself on Kubernetes with Helm, fully under your control.”
   • [claimed-docs] “A feature-complete Jitsu deployment requires a Kubernetes cluster: functions and profile builders run in dedicated function-server deploymen…”
   • [claimed-docs] “Profiles are customer records stored in your warehouse, based on the events data you send to Jitsu.”

   proof ↗⚑ flag