[ { "productId": "hightouch", "storyId": "agent-manages-pipeline", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch documents both an official MCP server (build audiences, manage syncs, design journeys, generate creatives, analyze performance) and a REST API explicitly covering syncs, models, sources, and destinations, plus a live authenticated API endpoint confirmed via probe. This directly satisfies the story of an agent managing the pipeline via API/MCP, including inspecting sync run outcomes/debugging.\n\nMissing for 10: explicit MCP-level source/destination creation (MCP docs emphasize audiences/syncs/journeys, not raw source/destination wiring), no discoverable OpenAPI spec, and no independent/hands-on evidence of an agent actually performing end-to-end pipeline management.", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-13", "hightouch-docs-27", "hightouch-docs-37", "hightouch-probe-4", "hightouch-probe-rt-1", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "agent-queries-activates-audiences", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch documents an official MCP server that lets an AI assistant directly create audiences, build syncs to activate them (e.g., to Braze), and even generate creatives — explicitly in natural language with no dashboard step described (hightouch-docs-10/11/12/31, hightouch-probe-4, hightouch-probe-rt-2). This is reinforced by a documented, auth-gated REST API covering syncs/models/sources/destinations (hightouch-docs-13, hightouch-probe-rt-1) for programmatic control beyond MCP. missing for 10: independent/hands-on verification that MCP-driven audience creation works end-to-end without any dashboard dependency, and clarity on whether initial schema/model setup (docs-1/24/35 imply UI-based schema config precedes audience building) can be fully done via MCP/API alone.", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-12", "hightouch-docs-13", "hightouch-probe-4", "hightouch-probe-rt-1", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A live llms.txt is confirmed at https://hightouch.com/llms.txt (HTTP 200), explicitly framing Hightouch as an 'Agentic Marketing Platform' and indexing its docs for agent consumption, corroborated by a runtime probe. This directly satisfies the story of pointing an agent at agent-oriented docs. Missing for 10: no docs.md/markdown-mirror endpoint (404) or OpenAPI spec discovery, which would round out full agent-native doc coverage.", "evidenceIds": [ "hightouch-probe-1", "hightouch-probe-rt-2", "hightouch-probe-2" ] }, { "productId": "hightouch", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch documents a 'built-in agent' to explore segments and analyze campaign performance in natural language (hightouch-docs-19) and an AI Decisioning feature that uses reinforcement learning to recommend messages/channel/timing (hightouch-docs-14), which are AI-generated insights/suggestions surfaced in-product. However, most evidence emphasizes agentic actions (building audiences, syncs, generating ad creatives) via MCP rather than analytical insights/recommendations presented directly in the UI, and there's no independent/hands-on corroboration of the insights quality. missing for 10: independent verification of the built-in agent's insight/recommendation quality, more detail on how insights are surfaced in-product (dashboards, reports) beyond brief doc mentions, and hands-on evidence of AI Decisioning's real-world recommendation accuracy.", "evidenceIds": [ "hightouch-docs-14", "hightouch-docs-19", "hightouch-docs-10", "hightouch-docs-11" ] }, { "productId": "hightouch", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch supports scheduled/triggered syncs and automated journeys that run continuously without manual intervention, plus AI Decisioning that uses reinforcement learning to autonomously choose message/channel/timing and measure outcomes, and CDC-based background data propagation — all core 'set it and forget it' automations. missing for 10: no evidence of autonomous multi-step agentic workflows beyond marketing ops (e.g., self-initiated remediation, cross-tool agent chains) and no independent hands-on confirmation of long-running autonomous behavior.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-14", "hightouch-docs-19", "hightouch-docs-20", "hightouch-docs-25", "hightouch-docs-26", "hightouch-docs-28" ] }, { "productId": "hightouch", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs explicitly mention a 'built-in agent' for exploring segments and analyzing campaign performance in natural language (hightouch-docs-19), and AI Decisioning uses reinforcement learning as an automated in-product agent (hightouch-docs-14). However, most of the detailed AI-assistant documentation (hightouch-docs-10/11/12/31, probe-4) actually describes the MCP server letting external AI assistants control Hightouch, not a dedicated in-app assistant UI with its own docs page. Missing for 10: a dedicated feature page describing the built-in assistant's UI/workflow, independent hands-on reports of using it, and detail on its scope/limitations.", "evidenceIds": [ "hightouch-docs-19", "hightouch-docs-14", "hightouch-docs-10" ] }, { "productId": "hightouch", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch exposes a REST API (auth-gated, verified live) for syncs/models/sources/destinations and supports Git Sync for programmatic resource management, both enabling scripted/CI-driven workflows. However, there's no dedicated CLI, no documented CI/CD pipeline examples, and syncs are primarily scheduled/triggered rather than designed for headless orchestration. missing for 10: official CLI tool, documented CI/CD integration examples or GitHub Actions templates, evidence of headless batch/automation runs outside the API, independent hands-on confirmation of CI usage.", "evidenceIds": [ "hightouch-docs-13", "hightouch-docs-32", "hightouch-docs-33", "hightouch-probe-rt-1", "hightouch-docs-3" ] }, { "productId": "hightouch", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All evidence describes Hightouch exposing its own MCP server so external AI assistants can call Hightouch's tools (server role), not Hightouch's built-in agent acting as an MCP client that can plug in and use other services' MCP servers/tools. No documentation or probe shows Hightouch's agent consuming third-party MCP servers.", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-19", "hightouch-probe-4", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Hightouch documents an official MCP server that connects AI assistants directly to its marketing stack, supporting audience creation, sync management, journey design, and creative generation via natural language, with RBAC scoping. This is corroborated by both docs and a runtime probe confirming the MCP docs page and agent-oriented llms.txt. Missing for 10: independent hands-on third-party review of the MCP server in actual use.", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-12", "hightouch-probe-4", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Hightouch documents a first-party MCP server enabling natural-language commands to build audiences, manage syncs, design journeys, and generate creatives (e.g. 'Create an audience... then create a sync to Braze'), plus a built-in in-product agent for exploring segments/analyzing campaigns in natural language. This is corroborated by an llms.txt describing Hightouch as an 'Agentic Marketing Platform' and runtime probes confirming the MCP docs and API exist. Missing for 10: independent/hands-on user reports specifically validating the MCP/agent natural-language workflows (only vendor docs and generic HN commentary on other features exist).", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-19", "hightouch-probe-4", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Hightouch's REST API, Git Sync, and MCP server for AI assistants, but no official CLI tool is mentioned anywhere in the docs, pricing, or community evidence. Since Hightouch is a developer-facing data platform where a CLI would be a plausible and expected offering, its absence constitutes 'none' rather than 'na'.", "evidenceIds": [ "hightouch-docs-13", "hightouch-docs-32", "hightouch-probe-3" ] }, { "productId": "hightouch", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Hightouch documents a REST API covering syncs, models, sources, and destinations with bearer-token authentication, and a runtime probe confirms the API is live and properly auth-gated. This gives AI-native users a real programmatic surface beyond the UI/MCP layer. Missing for 10: a discoverable OpenAPI/Swagger spec (probed and 404) and independent developer corroboration of API robustness.", "evidenceIds": [ "hightouch-docs-13", "hightouch-docs-33", "hightouch-probe-rt-1", "hightouch-probe-3" ] }, { "productId": "hightouch", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Hightouch supports bearer-token API keys for its REST API and permissions/RBAC/ownership boundaries, and MCP access is described as scoped to workspace RBAC, but there is no documented mechanism for issuing scoped, least-privilege, agent-specific credentials (e.g., per-agent API keys, granular scopes, or token minting for agents). missing for 10: dedicated scoped/least-privilege credential issuance for agents, documentation of API key scopes/permissions granularity, evidence of per-agent or short-lived token support.", "evidenceIds": [ "hightouch-docs-33", "hightouch-docs-34", "hightouch-docs-10", "hightouch-probe-rt-2", "hightouch-probe-rt-1" ] }, { "productId": "hightouch", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch documents official SDKs for browser, iOS, Android, Node.js plus an HTTP API for event ingestion, and a separate authenticated REST API for managing syncs/models/sources/destinations, giving AI-native builders multiple official, documented integration surfaces. Missing for 10: a publicly discoverable OpenAPI/swagger spec (probe shows 404s across candidate paths) and independent/hands-on developer corroboration of SDK reliability beyond vendor docs.", "evidenceIds": [ "hightouch-docs-6", "hightouch-docs-38", "hightouch-docs-13", "hightouch-docs-33", "hightouch-docs-41", "hightouch-probe-3", "hightouch-probe-rt-1" ] }, { "productId": "hightouch", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows sync alerts/notifications (docs-28) and a REST API (docs-13, docs-33) but no documentation of a webhook subscription mechanism for events; Hightouch Events (docs-5/6/7) is about ingesting customer behavior data, not emitting webhooks for system/sync events. No evidence of an outbound webhook API or subscription endpoint for AI agents to consume.", "evidenceIds": [ "hightouch-docs-28", "hightouch-docs-13", "hightouch-docs-5" ] }, { "productId": "hightouch", "storyId": "ai-decisioning-agents", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Hightouch documents an 'AI Decisioning' capability that uses reinforcement learning to recommend the best message, channel, and timing per customer and then measures outcomes, directly matching the core of this story. However, evidence is a single thin doc mention with no detail on configurable guardrails, no independent case studies or benchmarks proving measurable lift, and no hands-on validation. Missing for 10: documented guardrail/constraint configuration, quantified lift case studies, independent or customer corroboration of decisioning performance.", "evidenceIds": [ "hightouch-docs-14", "hightouch-docs-34" ] }, { "productId": "hightouch", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Hightouch documents a REST API with auth guidance (hightouch-docs-13, hightouch-docs-33) but there is no evidence of an interactive API reference with runnable examples — probes for openapi.json/swagger.json all returned 404 across every candidate path, and no docs mention a try-it console, Postman collection, or embedded API explorer.", "evidenceIds": [ "hightouch-docs-13", "hightouch-docs-33", "hightouch-probe-3" ] }, { "productId": "hightouch", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Hightouch has a REST API (hightouch-docs-13, hightouch-probe-rt-1) but explicit probes for an OpenAPI/Swagger spec at all standard paths returned 404 (hightouch-probe-3), and no docs page offers a downloadable machine-readable spec.", "evidenceIds": [ "hightouch-probe-3", "hightouch-docs-13" ] }, { "productId": "hightouch", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack of a sandbox/staging environment or test mode that isolates AI-native testing from production data; docs cover syncs, models, identity resolution, MCP, and API auth, but nothing about a non-production sandbox for testing.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence confirms Hightouch has a REST API (bearer-token auth, resources like syncs/models) but nothing in the docs pack mentions API versioning scheme (e.g., v1/v2) or any documented deprecation policy; OpenAPI spec discovery even failed (404s). missing for 10: any mention of API version numbers, changelog, or deprecation/sunset policy for the REST API or MCP server.", "evidenceIds": [ "hightouch-docs-13", "hightouch-docs-33", "hightouch-probe-3", "hightouch-probe-rt-1" ] }, { "productId": "hightouch", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch's core sync engine operates on whole models/audiences (bulk rows) on each run, and the platform explicitly supports batch event ingestion (\"Use the batch endpoint to submit multiple events... in a single request\") plus a REST API for programmatically managing syncs, models, sources, and destinations. However, evidence doesn't show explicit bulk-management API operations (e.g., batch-update many syncs/audiences in one call) — it only shows single-resource CRUD and batch data ingestion. Missing for 10: explicit bulk/batch API operations across multiple resources at once (not just event ingestion), and independent verification of large-scale bulk sync performance.", "evidenceIds": [ "hightouch-docs-39", "hightouch-docs-13", "hightouch-docs-27", "hightouch-docs-3", "hightouch-docs-32" ] }, { "productId": "hightouch", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch supports event-driven syncs (trigger on data change/CDC), sync alerts on failure, and journeys that react to customer behavior, which cover rule-based automation of actions on events; however these are framed around marketing/data-sync workflows rather than general-purpose event-condition-action rule definition for arbitrary AI-native automations. missing for 10: a documented general rules/conditions engine (if-this-then-that style) independent of syncs/journeys, evidence of arbitrary event types triggering arbitrary actions beyond syncing/audience creation, and independent/hands-on confirmation of trigger-based automation working reliably.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-20", "hightouch-docs-28", "hightouch-docs-25", "hightouch-docs-19" ] }, { "productId": "hightouch", "storyId": "automation-scheduled-jobs", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch syncs run on a defined schedule or trigger and can sync on a cadence or when data changes, and journeys can be built as automated workflows; the MCP server lets an AI assistant manage syncs (which include their schedules) and journeys in natural language. Missing for 10: an explicit worked example of an AI assistant creating or modifying a sync schedule via MCP/natural language (only audience/sync creation and ad generation are shown), and independent confirmation of AI-driven scheduling in practice.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-20", "hightouch-docs-19", "hightouch-docs-10", "hightouch-docs-11", "hightouch-probe-rt-2" ] }, { "productId": "hightouch", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Hightouch's Git Sync lets teams manage workspace resources (models, syncs, audiences) programmatically via git, and the platform separately supports approvals/ownership boundaries for review workflows, with a community comparison confirming 'git version control' as a differentiator. However, there is no explicit documentation of a rollback mechanism, version history UI, or how git-based changes propagate back to rollback a live automation. Missing for 10: explicit rollback/restore documentation, versioned change history in the UI, and independent confirmation that Git Sync supports full revert workflows for automations.", "evidenceIds": [ "hightouch-docs-32", "hightouch-docs-34", "hightouch-comm-5" ] }, { "productId": "hightouch", "storyId": "composable-warehouse-mode", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Hightouch's core model is warehouse-native: models are defined via SQL/dbt/BI queries directly on warehouse tables (docs-2, docs-23), audiences/Customer Studio build on top of these warehouse models (docs-19, docs-43), and syncs activate data to destinations on a schedule without re-collecting or storing it elsewhere (docs-20, docs-27, docs-26 CDC computed in-warehouse). Independent community testimony corroborates that syncs are declarative SQL-to-destination mappings and that Hightouch stores no data itself, keeping everything in the customer's own warehouse (hightouch-comm-2, hightouch-comm-3). Missing for 10: independent hands-on performance benchmarks proving no-recollection at scale, and no third-party audit of the 'no data stored' claim beyond company/community anecdote.", "evidenceIds": [ "hightouch-docs-2", "hightouch-docs-23", "hightouch-docs-19", "hightouch-docs-20", "hightouch-docs-27", "hightouch-docs-26", "hightouch-docs-43", "hightouch-comm-2", "hightouch-comm-3" ] }, { "productId": "hightouch", "storyId": "computed-predictive-traits", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Hightouch clearly supports computed traits: models can be built with SQL, dbt, or a visual builder and used directly in audience/journey targeting via Customer Studio, and Identity Resolution can produce a golden-record profile view. However, there is no evidence of a native predictive-scoring capability (LTV, churn, purchase propensity) computed by Hightouch itself — the closest feature, 'AI Decisioning,' is a reinforcement-learning message/channel/timing optimizer, not a per-profile predictive score usable as an audience filter attribute. Missing for 10: documentation of built-in ML models producing LTV/churn/propensity scores stored as profile attributes, and evidence these specific score types are selectable in audience-builder filters.", "evidenceIds": [ "hightouch-docs-23", "hightouch-docs-2", "hightouch-docs-8", "hightouch-docs-9", "hightouch-docs-14", "hightouch-docs-19", "hightouch-docs-24" ] }, { "productId": "hightouch", "storyId": "consent-enforcement", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack items mention consent management, opt-outs, consent categories, or any suppression/enforcement mechanism honored across destinations; Hightouch's docs focus on syncs, audiences, identity resolution, and events, none of which describe consent capture or enforcement.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "deletion-suppression-requests", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack describes Hightouch's audience-building, sync, identity resolution, and events capabilities, but contains no mention of deletion/suppression request workflows, DSAR/GDPR-CCPA processing, or forwarding erasure requests to destinations. This is a plausible capability for a CDP/reverse-ETL platform, so the axis applies, but no evidence supports it.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "delivery-observability", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch's docs confirm a sync-run debugger for checking runs and debugging rejected rows, plus configurable alerts when a run fails, and community evidence (comm-5) explicitly calls out 'live debugger, alerting' as differentiating developer-facing features versus competitors. However, there is no direct evidence of a live event-stream view (watching events flow in real time) or per-destination delivery metrics dashboards beyond the sync debugger and alerting. Missing for 10: live event flow visualization, per-destination delivery metrics/dashboards, and independent hands-on confirmation of debugger usability at scale.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-4", "hightouch-docs-28", "hightouch-docs-37", "hightouch-comm-5" ] }, { "productId": "hightouch", "storyId": "destination-catalog-breadth", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch's docs describe syncs that map one model to a destination object/list/table with per-destination field mapping, unlimited destination counts, scheduled/CDC-based delivery, and run-level debugging, and a HN co-founder interview independently confirms declarative field mapping plus a claim of 70+ deep integrations with visual audience filtering versus competitors. Missing for 10: a public, browsable catalog page listing/counting all supported destinations, and detailed docs on per-destination filtering syntax beyond audience-level filtering.", "evidenceIds": [ "hightouch-docs-27", "hightouch-docs-20", "hightouch-docs-18", "hightouch-docs-25", "hightouch-docs-28", "hightouch-comm-2", "hightouch-comm-5" ] }, { "productId": "hightouch", "storyId": "event-replay-backfill", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Hightouch's sync docs describe scheduled/triggered syncs, CDC, and run debugging, but there is no evidence of replaying archived events or backfilling historical data into a new destination when a pipeline breaks or a tool is added; Hightouch Events pipes live behavioral events into the warehouse, not archived-event replay. missing for 10: any mention of event/data replay, backfill mechanisms, historical resync into new destinations, or reprocessing archived data after pipeline failure.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-25", "hightouch-docs-26", "hightouch-docs-5" ] }, { "productId": "hightouch", "storyId": "identity-stitching", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch documents Identity Resolution linking cross-device/channel signals into a unified identity with a Golden Record built via survivorship rules, and describes unifying data across sources — directly addressing stitching known/anonymous activity into one profile. However, the docs shown don't detail configurable matching rules (e.g., deterministic vs probabilistic matching logic, field-level match keys) beyond survivorship for golden records, and there's no independent/hands-on validation of identity-resolution accuracy. Missing for 10: documentation of specific configurable match-rule types (deterministic/probabilistic, custom match keys), worked examples of anonymous-to-known stitching, and independent verification of resolution quality.", "evidenceIds": [ "hightouch-docs-8", "hightouch-docs-9", "hightouch-docs-22", "hightouch-docs-30", "hightouch-docs-42", "hightouch-docs-43", "hightouch-docs-40" ] }, { "productId": "hightouch", "storyId": "inline-event-transformations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Hightouch lets data engineers define models via SQL, dbt, or a visual builder (docs-2, docs-23), which supports filtering and transforming data before syncing to destinations, and CDC only sends changed rows (docs-25/36). However, there's no evidence of custom code/functions (e.g., JS/Python transform steps) applied in-pipeline for enrichment beyond SQL modeling, nor any dedicated transformation-step API distinct from model definition. Missing for 10: explicit custom-code/function transformation step, enrichment logic beyond SQL/dbt models, and independent verification of such capability.", "evidenceIds": [ "hightouch-docs-2", "hightouch-docs-23", "hightouch-docs-25", "hightouch-docs-36" ] }, { "productId": "hightouch", "storyId": "nl-audience-builder", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Hightouch's MCP server and built-in agent let users describe an audience in natural language (e.g. 'customers who added an item to cart but didn't complete a transaction') and have AI build the segment definition grounded in the actual warehouse schema/models, then present it for review before syncing (hightouch-docs-10, hightouch-docs-11, hightouch-docs-19, hightouch-probe-rt-2). missing for 10: independent/hands-on evidence (beyond vendor docs) confirming accuracy of schema grounding and an explicit UI review/approval step before the audience is finalized.", "evidenceIds": [ "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-19", "hightouch-probe-rt-2", "hightouch-probe-4" ] }, { "productId": "hightouch", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch documents a real REST API covering syncs, models, sources, and destinations (hightouch-docs-13, hightouch-probe-rt-1) and a separate MCP server that lets an AI assistant build audiences, journeys, syncs, and creatives in natural language (hightouch-docs-10/11/12, hightouch-probe-4). However, core UI-only features like audience/journey building are explicitly described as done in a 'no-code UI' (hightouch-docs-1/24/35), and the plain REST API guide never lists audience or journey endpoints, only syncs/models/sources/destinations — so parity between UI and raw API is not fully documented; the MCP path partially closes this gap but is a distinct conversational layer, not the generic API. Missing for 10: explicit REST API endpoints for audience/journey creation, and confirmation that MCP/API actions cover 100% of UI capabilities (e.g., Ad Studio, AI Decisioning) rather than a subset.", "evidenceIds": [ "hightouch-docs-1", "hightouch-docs-13", "hightouch-docs-10", "hightouch-docs-11", "hightouch-docs-24", "hightouch-probe-4", "hightouch-probe-rt-1" ] }, { "productId": "hightouch", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Hightouch's hybrid architecture keeps customer data in the user's own warehouse/S3 by default rather than inside Hightouch (hightouch-comm-3), which means the underlying data is inherently in open, customer-controlled formats and not locked in. Git Sync and the REST API also let workspace resources (models, syncs) be managed/exported programmatically (hightouch-docs-32, hightouch-docs-13). Missing for 10: explicit first-party documentation of a full data export flow/format, no dedicated 'export and leave' guide, and this evidence comes mainly from a community HN thread rather than official docs.", "evidenceIds": [ "hightouch-comm-3", "hightouch-docs-32", "hightouch-docs-13" ] }, { "productId": "hightouch", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack indicates Hightouch publishes its source code under any open license; all material describes a closed, hosted SaaS platform with commercial pricing tiers. The axis is fair for a data platform (open-core models exist in this space), but nothing here shows a public repo or license.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Hightouch is presented throughout as a hosted SaaS platform (workspace, pricing tiers, API auth) with no mention of self-hosting or on-premise deployment options anywhere in the evidence pack.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "pii-field-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Hightouch's sync engine, identity resolution, events, and permissions/RBAC (docs-34), but nowhere documents field-level hashing, masking, or PII-specific filtering controls scoped per destination. Since Hightouch moves warehouse data (including PII) to many destinations, this is a fair and plausible axis for a reverse-ETL/CDP product, but no capability is evidenced.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Hightouch's hybrid architecture stores no customer data in Hightouch itself—data stays in the customer's own warehouse/S3 bucket—which gives users effective control over where their data resides by choosing their own warehouse's region, and this underpins its use by regulated fintech/healthcare customers. However, there is no explicit documentation of a region-selection setting or residency options within Hightouch's own platform/control plane. Missing for 10: explicit region/residency configuration UI or docs, statements about where Hightouch's own metadata/control plane is hosted, and any multi-region deployment options.", "evidenceIds": [ "hightouch-comm-3" ] }, { "productId": "hightouch", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Hightouch is a customer data/reverse-ETL platform, not an AI model provider or training-data pipeline; there's no evidence it trains AI models on customer data at all, so an opt-out-of-AI-training control is a category error for this product type.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack has no documentation of data retention policies, deletion APIs, or AI-specific data lifecycle controls; the closest tangential fact is that Hightouch doesn't store customer data itself (hightouch-comm-3), but this doesn't describe any deletion/retention control mechanism for AI-native users.", "evidenceIds": [ "hightouch-comm-3" ] }, { "productId": "hightouch", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack content addresses telemetry/usage-tracking opt-out settings for Hightouch itself; all docs concern data sync, identity resolution, and API features unrelated to product telemetry controls.", "evidenceIds": [] }, { "productId": "hightouch", "storyId": "realtime-audience-activation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch supports syncing audiences to ad platforms/engagement tools on a schedule or trigger with CDC to only send new/changed/removed rows, which supports near-real-time membership changes, but syncs are still schedule/trigger-based batch jobs rather than a documented continuous streaming/real-time audience membership pipeline. missing for 10: explicit documentation of true real-time/streaming sync latency (e.g. sub-minute or event-triggered entry/exit), independent evidence of sync frequency/latency in production, and confirmation that ad platform destinations support such near-real-time updates rather than periodic batch syncs.", "evidenceIds": [ "hightouch-docs-3", "hightouch-docs-25", "hightouch-docs-26", "hightouch-docs-27", "hightouch-docs-20" ] }, { "productId": "hightouch", "storyId": "sdk-event-collection", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Hightouch Events documents official SDKs for browser, iOS, Android, and Node.js plus an HTTP API/batch endpoint for server-side ingestion, and explicitly defines a tracking spec with five event types (identify, track, page, screen, group), matching the story's core ask. missing for 10: independent/hands-on developer corroboration that the SDKs work as documented in production, and no visible changelog/version history proving spec stability over time.", "evidenceIds": [ "hightouch-docs-5", "hightouch-docs-6", "hightouch-docs-7", "hightouch-docs-29", "hightouch-docs-38", "hightouch-docs-39", "hightouch-docs-41" ] }, { "productId": "hightouch", "storyId": "server-ingest-http", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch documents an HTTP Tracking API for server-to-server event ingestion, including a batch endpoint and defined event types (identify, track, page, screen, group), which lands in the customer's warehouse. However, the evidence does not explicitly document authentication requirements or delivery guarantees (retries, idempotency, at-least-once semantics) specifically for this Events API — the bearer-token auth and run-level failure alerts/debugging described elsewhere apply to the general REST API and sync pipeline, not confirmed for the events collector itself. missing for 10: explicit auth mechanism for the HTTP Tracking/Events API, documented delivery/retry guarantees or acknowledgement semantics for event ingestion, and independent confirmation of reliability at scale.", "evidenceIds": [ "hightouch-docs-6", "hightouch-docs-7", "hightouch-docs-38", "hightouch-docs-39", "hightouch-docs-29", "hightouch-docs-41", "hightouch-docs-33" ] }, { "productId": "hightouch", "storyId": "third-party-source-feeds", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Hightouch's evidence describes a reverse-ETL/composable-CDP architecture: models are read FROM the warehouse and synced OUT to destinations (docs-2, docs-20, docs-27), and its only inbound 'ingestion' feature (Hightouch Events) explicitly covers only the customer's own instrumented websites/apps/backends via SDKs or HTTP API (docs-5, docs-6, docs-41) — the exact case the story excludes. There is no documented source connector for pulling data in from third-party cloud apps/feeds (e.g., Salesforce, Stripe, Zendesk) into the warehouse; 'sources' in the API refer to warehouses, not external SaaS ingestion.", "evidenceIds": [ "hightouch-docs-2", "hightouch-docs-5", "hightouch-docs-6", "hightouch-docs-41", "hightouch-docs-27", "hightouch-docs-20" ] }, { "productId": "hightouch", "storyId": "tracking-plan-enforcement", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Hightouch's Events feature mentions a 'schema' step and syncs that can flag 'rejected rows' at the destination side, but there is no evidence of tracking-plan validation, blocking, or quarantining of malformed/violating events at ingestion — the debugger references relate to sync/destination failures, not schema enforcement on incoming event data.", "evidenceIds": [ "hightouch-docs-24", "hightouch-docs-35", "hightouch-docs-4", "hightouch-docs-37", "hightouch-docs-29" ] }, { "productId": "hightouch", "storyId": "unified-profile-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hightouch's Identity Resolution builds a warehouse-resident Golden Record (traits, canonical identifiers) that docs explicitly say teams can 'query directly' or build models on (hightouch-docs-9, hightouch-docs-43), and its hybrid architecture keeps all profile data in the customer's own warehouse/store rather than a proprietary store (hightouch-comm-3). However, this satisfies the 'store' half of the story via SQL access to warehouse tables rather than a dedicated, documented Profile API for identifier/trait/event lookups — the REST API documented (hightouch-docs-13, hightouch-probe-rt-1) covers syncs/models/sources/destinations management, not profile/event retrieval by customer ID. Missing for 10: a first-party 'Profile API' endpoint (e.g., lookup-by-identifier returning traits+event history), explicit event-history query capability via API, and independent/hands-on confirmation of querying golden-record data through an API rather than raw SQL.", "evidenceIds": [ "hightouch-docs-8", "hightouch-docs-9", "hightouch-docs-43", "hightouch-docs-13", "hightouch-comm-3", "hightouch-probe-rt-1" ] }, { "productId": "hightouch", "storyId": "visual-audience-builder", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a no-code visual builder for audiences (Customer Studio) built on traits/behavior data, explicitly requiring no SQL from marketers, and models can also be built visually per hightouch-docs-23. However, none of the evidence mentions an audience size estimate/preview before activation. Missing for 10: explicit documentation or screenshot of estimated audience size display prior to activating a sync, and independent/hands-on confirmation of the visual builder UX.", "evidenceIds": [ "hightouch-docs-1", "hightouch-docs-24", "hightouch-docs-35", "hightouch-docs-19", "hightouch-docs-23" ] }, { "productId": "hightouch", "storyId": "warehouse-sync-raw", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Hightouch Events explicitly ingests raw behavioral events via SDKs, HTTP API, or streaming sources (Kafka/Pub/Sub) and stores them directly in the customer's own warehouse (Snowflake, BigQuery, etc.), and Identity Resolution builds unified 'golden record' profiles in that same warehouse — confirmed independently by an HN comment noting Hightouch's hybrid architecture stores no data itself, everything stays in the customer's warehouse/S3. Models are built with SQL/dbt directly against warehouse tables, keeping engineers in control of the data layer.\n\nmissing for 10: explicit documentation of a configurable ingestion schedule/cadence for raw event landing (docs mostly describe real-time streaming ingestion, not a data-engineer-set batch schedule), and independent hands-on validation of warehouse-landing reliability at scale.", "evidenceIds": [ "hightouch-docs-5", "hightouch-docs-6", "hightouch-docs-7", "hightouch-docs-38", "hightouch-docs-41", "hightouch-docs-8", "hightouch-docs-9", "hightouch-docs-23", "hightouch-comm-3" ] }, { "productId": "jitsu", "storyId": "agent-manages-pipeline", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-19", "jitsu-docs-20", "jitsu-probe-3", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agent-queries-activates-audiences", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-19", "jitsu-probe-rt-1", "jitsu-docs-11", "jitsu-docs-34", "jitsu-docs-39" ] }, { "productId": "jitsu", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-probe-1", "jitsu-docs-19", "jitsu-probe-3", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-19", "jitsu-docs-20", "jitsu-probe-rt-1", "jitsu-docs-11", "jitsu-docs-39" ] }, { "productId": "jitsu", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-31", "jitsu-docs-41", "jitsu-gh-3", "jitsu-docs-16" ] }, { "productId": "jitsu", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-19", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-13", "jitsu-gh-1", "jitsu-docs-20", "jitsu-docs-19", "jitsu-docs-2", "jitsu-probe-4", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Jitsu operates as an MCP *server* — 'Jitsu runs an MCP server, so AI agents can manage your pipeline directly' (jitsu-docs-19, jitsu-probe-rt-1) — which is the opposite role from what this story asks (Jitsu acting as an MCP *client* that plugs in and uses external MCP servers' tools). No evidence anywhere in the pack shows Jitsu consuming or connecting to third-party MCP servers to use their tools.", "evidenceIds": [ "jitsu-docs-19", "jitsu-probe-rt-1", "jitsu-probe-3" ] }, { "productId": "jitsu", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Jitsu documents and runs an official MCP server (jitsu.com/docs/mcp) letting AI agents manage pipelines — create destinations, wire streams, inspect Live Events, edit Functions — with both browser OAuth and API-key auth flows for headless use. A runtime probe confirms the hosted MCP endpoint is live and enforces OAuth (401 with WWW-Authenticate), corroborating the documented capability. Missing for 10: independent third-party hands-on review of the MCP integration beyond vendor docs/probe.", "evidenceIds": [ "jitsu-docs-19", "jitsu-docs-20", "jitsu-probe-3", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-19", "jitsu-docs-20", "jitsu-probe-3", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-13", "jitsu-docs-29", "jitsu-gh-1", "jitsu-gh-5", "jitsu-gh-6", "jitsu-probe-4" ] }, { "productId": "jitsu", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-2", "jitsu-docs-19", "jitsu-probe-3", "jitsu-probe-rt-1", "jitsu-docs-13", "jitsu-gh-1", "jitsu-probe-2" ] }, { "productId": "jitsu", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-17", "jitsu-docs-20", "jitsu-probe-rt-1", "jitsu-docs-19" ] }, { "productId": "jitsu", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-5", "jitsu-docs-2", "jitsu-docs-13", "jitsu-gh-1", "jitsu-probe-4", "jitsu-probe-2", "jitsu-probe-rt-2", "jitsu-comm-6", "jitsu-comm-7" ] }, { "productId": "jitsu", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-6", "jitsu-docs-40", "jitsu-gh-2", "jitsu-docs-19" ] }, { "productId": "jitsu", "storyId": "ai-decisioning-agents", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Jitsu is a data infrastructure/CDP pipeline tool (event collection, warehousing, profiles, functions) — it has no autonomous decisioning agents that pick messages, timing, or channels per customer, nor any campaign/lift measurement capability. This is a wrong-axis story for a data pipeline product, not an agent orchestration or engagement platform.", "evidenceIds": [] }, { "productId": "jitsu", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-2", "jitsu-probe-2" ] }, { "productId": "jitsu", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-probe-2" ] }, { "productId": "jitsu", "storyId": "api-sandbox", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-38", "jitsu-docs-15", "jitsu-docs-41" ] }, { "productId": "jitsu", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-probe-2", "jitsu-docs-2", "jitsu-docs-19" ] }, { "productId": "jitsu", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-7", "jitsu-docs-9", "jitsu-gh-3", "jitsu-docs-13", "jitsu-gh-5" ] }, { "productId": "jitsu", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-37", "jitsu-docs-38", "jitsu-docs-11", "jitsu-docs-12", "jitsu-comm-7" ] }, { "productId": "jitsu", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-41", "jitsu-gh-3", "jitsu-gh-4", "jitsu-docs-19" ] }, { "productId": "jitsu", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-gh-6", "jitsu-docs-17", "jitsu-docs-16", "jitsu-docs-29" ] }, { "productId": "jitsu", "storyId": "composable-warehouse-mode", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-11", "jitsu-docs-39", "jitsu-docs-34" ] }, { "productId": "jitsu", "storyId": "computed-predictive-traits", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-11", "jitsu-docs-12", "jitsu-docs-28", "jitsu-docs-33", "jitsu-docs-39" ] }, { "productId": "jitsu", "storyId": "consent-enforcement", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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).", "evidenceIds": [] }, { "productId": "jitsu", "storyId": "deletion-suppression-requests", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-22", "jitsu-docs-23", "jitsu-docs-44" ] }, { "productId": "jitsu", "storyId": "delivery-observability", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-36", "jitsu-docs-16", "jitsu-docs-18", "jitsu-docs-17", "jitsu-docs-38" ] }, { "productId": "jitsu", "storyId": "destination-catalog-breadth", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-gh-2", "jitsu-docs-30", "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-31", "jitsu-docs-45", "jitsu-comm-6", "jitsu-comm-7" ] }, { "productId": "jitsu", "storyId": "event-replay-backfill", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-16", "jitsu-docs-36" ] }, { "productId": "jitsu", "storyId": "identity-stitching", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-4", "jitsu-docs-11", "jitsu-docs-12", "jitsu-docs-28", "jitsu-docs-39" ] }, { "productId": "jitsu", "storyId": "inline-event-transformations", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-31", "jitsu-docs-37", "jitsu-docs-38", "jitsu-docs-45", "jitsu-gh-1", "jitsu-gh-5", "jitsu-gh-6", "jitsu-docs-34" ] }, { "productId": "jitsu", "storyId": "nl-audience-builder", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Jitsu is a CDP/data-pipeline infrastructure tool (event collection, warehouse delivery, profiles) rather than an audience/segmentation builder with natural-language AI segment generation; there is no audience-segment-building feature at all, so this is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "jitsu", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-2", "jitsu-docs-13", "jitsu-gh-1", "jitsu-docs-19", "jitsu-probe-3", "jitsu-probe-4", "jitsu-probe-2", "jitsu-probe-rt-1" ] }, { "productId": "jitsu", "storyId": "openness-full-export", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-14", "jitsu-docs-21", "jitsu-docs-35", "jitsu-gh-2", "jitsu-probe-rt-2", "jitsu-docs-41" ] }, { "productId": "jitsu", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Jitsu's GitHub repo is confirmed to include the MIT LICENSE file, and probes verify the repo is publicly cloneable with self-host source (docker-compose.yml, source code) — plus docs and community threads describe it as an 'open-source data integration platform.' Missing for 10: no explicit license-file citation from claimed-docs pages and no independent legal/community discussion confirming license terms beyond the probe.", "evidenceIds": [ "jitsu-probe-rt-2", "jitsu-probe-1", "jitsu-comm-2" ] }, { "productId": "jitsu", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Jitsu is explicitly open source with documented self-hosting via Docker Compose and a full Kubernetes/Helm deployment path, confirmed by GitHub repo, docs, and an independent runtime probe showing the MIT-licensed repo and docker-compose.yml are actually accessible and cloneable. Community feedback corroborates real-world self-hosted deployment (HN commenter deployed OSS version to BigQuery), though one reviewer notes the Helm/deploy experience is rougher than competitors like Rudderstack. missing for 10: independent audit of feature-complete self-hosted parity (docs note some features need full K8s cluster), broader third-party validation of Helm chart quality beyond one critical comment.", "evidenceIds": [ "jitsu-docs-14", "jitsu-docs-15", "jitsu-docs-41", "jitsu-probe-rt-2", "jitsu-comm-2", "jitsu-comm-3", "jitsu-probe-1" ] }, { "productId": "jitsu", "storyId": "pii-field-controls", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-31", "jitsu-docs-45", "jitsu-docs-37" ] }, { "productId": "jitsu", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-14", "jitsu-docs-41", "jitsu-docs-44", "jitsu-probe-rt-2" ] }, { "productId": "jitsu", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Jitsu's security page covers encryption, SOC2 compliance, and DPA/SCC agreements, but nothing in the evidence pack addresses whether customer event data is used to train AI models or how a user could opt out of such use.", "evidenceIds": [ "jitsu-docs-22", "jitsu-docs-23", "jitsu-docs-44" ] }, { "productId": "jitsu", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-14", "jitsu-docs-41", "jitsu-docs-44", "jitsu-docs-23", "jitsu-docs-22" ] }, { "productId": "jitsu", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-14", "jitsu-docs-41", "jitsu-docs-22", "jitsu-docs-23" ] }, { "productId": "jitsu", "storyId": "realtime-audience-activation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "jitsu-gh-2", "jitsu-docs-30", "jitsu-docs-11", "jitsu-docs-28", "jitsu-docs-39", "jitsu-comm-6" ] }, { "productId": "jitsu", "storyId": "sdk-event-collection", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-5", "jitsu-docs-2", "jitsu-docs-4", "jitsu-docs-11", "jitsu-docs-26", "jitsu-docs-43" ] }, { "productId": "jitsu", "storyId": "server-ingest-http", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-2", "jitsu-docs-7", "jitsu-docs-8", "jitsu-docs-9", "jitsu-docs-16", "jitsu-docs-17", "jitsu-docs-22", "jitsu-docs-23", "jitsu-probe-2" ] }, { "productId": "jitsu", "storyId": "third-party-source-feeds", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-gh-3", "jitsu-gh-4", "jitsu-comm-6" ] }, { "productId": "jitsu", "storyId": "tracking-plan-enforcement", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "jitsu-docs-3", "jitsu-docs-25", "jitsu-docs-45", "jitsu-docs-16", "jitsu-docs-37" ] }, { "productId": "jitsu", "storyId": "unified-profile-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-11", "jitsu-docs-12", "jitsu-docs-28", "jitsu-docs-39", "jitsu-docs-34", "jitsu-probe-2" ] }, { "productId": "jitsu", "storyId": "visual-audience-builder", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "jitsu-docs-11", "jitsu-docs-12", "jitsu-docs-39", "jitsu-docs-43" ] }, { "productId": "jitsu", "storyId": "warehouse-sync-raw", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "jitsu-docs-7", "jitsu-docs-8", "jitsu-docs-9", "jitsu-docs-10", "jitsu-gh-2", "jitsu-docs-21", "jitsu-docs-35", "jitsu-docs-14", "jitsu-docs-41", "jitsu-docs-39" ] }, { "productId": "mparticle", "storyId": "agent-manages-pipeline", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-18", "mparticle-docs-19", "mparticle-docs-x2", "mparticle-docs-x4", "mparticle-docs-11" ] }, { "productId": "mparticle", "storyId": "agent-queries-activates-audiences", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-19", "mparticle-docs-20", "mparticle-docs-x2", "mparticle-docs-x4" ] }, { "productId": "mparticle", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-15", "mparticle-docs-16", "mparticle-docs-22" ] }, { "productId": "mparticle", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-19", "mparticle-docs-20", "mparticle-docs-x2", "mparticle-docs-x3", "mparticle-docs-x4", "mparticle-docs-16" ] }, { "productId": "mparticle", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-16", "mparticle-docs-22" ] }, { "productId": "mparticle", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-18", "mparticle-docs-4", "mparticle-docs-19", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "mParticle is a customer data platform focused on data collection, identity resolution, and outbound integrations, not an AI agent or assistant that consumes tools via MCP; no evidence pack items relate to MCP server support.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "mParticle is a CDP/data platform, not an AI agent; no evidence exists of an official MCP server for AI agents to connect to, and this axis is about a fundamentally different capability than mParticle's data-integration APIs. Given the product is not itself an agent, absence of an official MCP server would normally be 'none', but nothing in the evidence pack even gestures at AI-agent connectivity via MCP, so the story doesn't map onto this data-infrastructure product's known offerings.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-16", "mparticle-docs-22" ] }, { "productId": "mparticle", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "mparticle-docs-2", "mparticle-docs-18", "mparticle-docs-19", "mparticle-docs-17", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-probe-rt-1", "mparticle-docs-18" ] }, { "productId": "mparticle", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-17", "mparticle-docs-1", "mparticle-docs-2", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "ai-decisioning-agents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "mParticle's evidence shows predictive audience scoring and natural-language audience creation (docs-15, docs-16) but nothing describing autonomous agents selecting messages, timing, or channels per customer, nor any measurable lift reporting tied to such decisioning — this is a CDP/audience-activation tool, not a decisioning/orchestration engine.", "evidenceIds": [ "mparticle-docs-15", "mparticle-docs-16", "mparticle-docs-22" ] }, { "productId": "mparticle", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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'.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x4", "mparticle-docs-18", "mparticle-docs-19", "mparticle-docs-x3" ] }, { "productId": "mparticle", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x3", "mparticle-docs-x2", "mparticle-docs-19", "mparticle-docs-20" ] }, { "productId": "mparticle", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "composable-warehouse-mode", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x4", "mparticle-docs-18", "mparticle-docs-19" ] }, { "productId": "mparticle", "storyId": "computed-predictive-traits", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-15", "mparticle-docs-13", "mparticle-docs-16", "mparticle-docs-20", "mparticle-docs-19", "mparticle-docs-22" ] }, { "productId": "mparticle", "storyId": "consent-enforcement", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x3", "mparticle-docs-21", "mparticle-docs-10" ] }, { "productId": "mparticle", "storyId": "deletion-suppression-requests", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-10", "mparticle-docs-x3", "mparticle-docs-21" ] }, { "productId": "mparticle", "storyId": "delivery-observability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-6" ] }, { "productId": "mparticle", "storyId": "destination-catalog-breadth", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-11", "mparticle-docs-x2", "mparticle-docs-21", "mparticle-docs-x3", "mparticle-docs-x4", "mparticle-comm-2" ] }, { "productId": "mparticle", "storyId": "event-replay-backfill", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x4", "mparticle-docs-x2", "mparticle-docs-18" ] }, { "productId": "mparticle", "storyId": "identity-stitching", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x1", "mparticle-docs-5", "mparticle-docs-9", "mparticle-docs-6" ] }, { "productId": "mparticle", "storyId": "inline-event-transformations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-8" ] }, { "productId": "mparticle", "storyId": "nl-audience-builder", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "mParticle's marketing copy explicitly promises the described capability ('Describe the audience, journey, or growth goal. mParticle understands the customer data behind it, suggests the logic to use, and helps turn intent into revenue-driving activation'), matching the natural-language-to-segment-definition story, and Composable Audiences docs show audience definitions are schema-grounded. However, this is only a marketing tagline with no supporting product documentation, UI walkthrough, or independent/hands-on verification of how the AI-generated segment is presented for review or how grounding in the actual schema works. Missing for 10: detailed docs/tutorial on the natural-language audience builder workflow, evidence of a review/edit step before segment creation, and independent or hands-on confirmation that it works as advertised.", "evidenceIds": [ "mparticle-docs-16", "mparticle-docs-22", "mparticle-docs-20", "mparticle-docs-19" ] }, { "productId": "mparticle", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-18", "mparticle-docs-19", "mparticle-docs-x1", "mparticle-docs-x4", "mparticle-docs-x2", "mparticle-docs-x3", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-18", "mparticle-docs-x4", "mparticle-docs-x2", "mparticle-docs-11" ] }, { "productId": "mparticle", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "mParticle is a closed-source commercial CDP/SaaS platform; there is no evidence of an open-license source release, and open-sourcing the core product is not an expected axis for this category of hosted data platform. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "mParticle is a SaaS customer data platform delivered exclusively as a hosted cloud service; there is no evidence of a self-hostable core product, and self-hosting is not a plausible axis for this managed SaaS category.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "pii-field-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x3", "mparticle-docs-8", "mparticle-docs-10", "mparticle-docs-21" ] }, { "productId": "mparticle", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x3" ] }, { "productId": "mparticle", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "mParticle is a customer data platform (CDP) for routing/managing user event data across marketing and analytics tools, not an AI model provider or AI assistant that trains models on user content; 'opt out of AI model training' is not a fair axis for this product category. Its privacy controls (consent, GDPR/CCPA) govern data forwarding to marketing partners, not model training.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-10", "mparticle-docs-x3" ] }, { "productId": "mparticle", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "mparticle", "storyId": "realtime-audience-activation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-19", "mparticle-docs-20", "mparticle-docs-x2", "mparticle-docs-13" ] }, { "productId": "mparticle", "storyId": "sdk-event-collection", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-1", "mparticle-docs-2", "mparticle-docs-17", "mparticle-docs-x1", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "server-ingest-http", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-2", "mparticle-docs-1", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "third-party-source-feeds", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x4", "mparticle-docs-18", "mparticle-docs-11", "mparticle-probe-rt-1" ] }, { "productId": "mparticle", "storyId": "tracking-plan-enforcement", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-6" ] }, { "productId": "mparticle", "storyId": "unified-profile-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-x1", "mparticle-docs-4", "mparticle-docs-x4", "mparticle-docs-18", "mparticle-docs-9" ] }, { "productId": "mparticle", "storyId": "visual-audience-builder", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "mparticle-docs-19", "mparticle-docs-20", "mparticle-docs-7", "mparticle-docs-x2" ] }, { "productId": "mparticle", "storyId": "warehouse-sync-raw", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "mparticle-docs-11", "mparticle-docs-x4" ] }, { "productId": "rudderstack", "storyId": "agent-manages-pipeline", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "RudderStack ships a documented, live hosted MCP server (confirmed via runtime OAuth probe) that lets AI clients like Claude/Cursor debug delivery errors, monitor pipelines, write/test transformations, and review tracking plans in natural language, plus a general REST API said to 'programmatically manage your RudderStack connections, transformations and other features.' However, the MCP capability list (docs-13,14,15,16,29,48,52,53) is explicit about inspecting deliveries, debugging, and transformations but never explicitly confirms agent-driven creation of sources/destinations or stream wiring, and no OpenAPI/spec was found (probe-3 all 404), leaving that part of the story thin. Missing for 10: explicit MCP/API evidence of creating sources/destinations and wiring streams, a discoverable OpenAPI spec, and independent hands-on confirmation of these write actions.", "evidenceIds": [ "rudderstack-docs-13", "rudderstack-docs-33", "rudderstack-docs-48", "rudderstack-docs-53", "rudderstack-probe-4", "rudderstack-probe-rt-1", "rudderstack-probe-3" ] }, { "productId": "rudderstack", "storyId": "agent-queries-activates-audiences", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "RudderStack's MCP server is explicitly scoped to operational/observability tasks—debugging delivery errors, monitoring pipelines, writing/testing transformations, reviewing tracking plans and audit logs (docs-13/14/15/16/48/52/53)—with no documented capability to query customer data or create/activate audiences via API or MCP. Audience building/activation (docs-6, docs-27, docs-38) is only described as a dashboard/product feature, not exposed through the documented API surface (docs-33, docs-47) or MCP tool list.", "evidenceIds": [ "rudderstack-docs-48", "rudderstack-docs-53", "rudderstack-docs-27", "rudderstack-docs-38", "rudderstack-docs-33" ] }, { "productId": "rudderstack", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A direct probe confirms llms.txt is live at https://www.rudderstack.com/llms.txt returning HTTP 200 with a descriptive summary, directly satisfying the story of pointing an agent at agent-oriented docs; this is further complemented by dedicated MCP docs for agentic access. Missing for 10: no evidence of full llms-full.txt or markdown-per-page docs (the .md probe 404s) and no independent/community corroboration of agents actually consuming llms.txt.", "evidenceIds": [ "rudderstack-probe-1", "rudderstack-docs-53", "rudderstack-probe-2" ] }, { "productId": "rudderstack", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack documents AI-powered features (Rudder AI Slack agent, RudderStack MCP) that let users interact with their workspace via natural language, including root-cause analysis, pipeline debugging, and one line stating AI chat interfaces let business teams 'analyze, segment, and activate data' without data-team bottlenecks. This gestures at AI-generated insights from data, but most MCP/AI documentation centers on operational tasks (debugging errors, writing transformations, detecting duplicate event names) rather than substantive data insights or suggestions about customer data itself. Missing for 10: dedicated analytics/insight-generation features (e.g., anomaly detection, trend summaries, predictive suggestions) with concrete examples or independent corroboration of AI-derived data insights.", "evidenceIds": [ "rudderstack-docs-51", "rudderstack-docs-44", "rudderstack-docs-13", "rudderstack-docs-48", "rudderstack-probe-rt-1" ] }, { "productId": "rudderstack", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "RudderStack's core pipeline features (event streaming, reverse ETL syncs, transformations, audience syncs) run continuously/automatically once configured, which is a form of background automation, and its MCP server/Rudder AI Slack agent let AI clients interact with the workspace. However, these AI features are described as interactive/on-demand (chat-based debugging, natural-language queries) rather than autonomous agents that trigger and run automations independently in the background. Missing for 10: evidence of AI-triggered autonomous workflows, scheduled/event-driven agent actions, or agent-initiated pipeline changes without human prompting.", "evidenceIds": [ "rudderstack-docs-11", "rudderstack-docs-44", "rudderstack-docs-48", "rudderstack-docs-53", "rudderstack-probe-rt-1", "rudderstack-docs-36", "rudderstack-docs-49" ] }, { "productId": "rudderstack", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "RudderStack documents 'Rudder AI', an AI-powered agent in Slack for managing/interacting with the workspace, plus AI/MCP features letting users delegate tasks in natural language (debug delivery errors, write/test transformations, review audit logs, detect duplicate events) with root-cause analysis and citations. This shows a genuine built-in AI assistant capability, though the MCP-based agentic features actually run through external clients (Claude, Cursor, etc.) rather than a fully self-contained in-product assistant, and there is no independent/hands-on confirmation of the Slack agent's real-world task delegation. missing for 10: independent/hands-on validation of Rudder AI in Slack actually completing delegated tasks, clarity on whether Slack agent operates fully in-product vs. relying on MCP/external LLM.", "evidenceIds": [ "rudderstack-docs-11", "rudderstack-docs-44", "rudderstack-docs-48", "rudderstack-docs-51", "rudderstack-docs-13", "rudderstack-docs-52", "rudderstack-probe-rt-1" ] }, { "productId": "rudderstack", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack's open-source server is a standalone, self-hosted system dependent only on PostgreSQL, and it exposes HTTP APIs plus a Node SDK that can be installed and invoked programmatically (confirmed via a keyless npm install/require test), which supports headless/scripted use in CI-like pipelines. However, there is no explicit documentation of a CLI, CI-specific setup, or automation/testing guidance for pipelines. Missing for 10: explicit CI/CD integration docs or examples, a dedicated CLI tool, and evidence of automated test/deploy workflows.", "evidenceIds": [ "rudderstack-docs-20", "rudderstack-docs-32", "rudderstack-docs-33", "rudderstack-docs-21", "rudderstack-probe-rt-2" ] }, { "productId": "rudderstack", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "All MCP-related evidence describes RudderStack exposing its OWN MCP server for external clients like Claude, Codex, or Cursor to connect to and use RudderStack's tools (docs-13/14/15/16/48/53, probe-4, probe-rt-1) — this is the server role, not the client role the story asks about. There is no evidence RudderStack itself can plug in and consume external MCP servers to extend its own AI features (e.g., Rudder AI in Slack) with third-party tools.", "evidenceIds": [ "rudderstack-docs-53", "rudderstack-docs-13", "rudderstack-docs-48", "rudderstack-probe-4", "rudderstack-probe-rt-1" ] }, { "productId": "rudderstack", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "RudderStack documents an official MCP server (rudderstack-mcp) that works with Claude, Codex, Cursor, and VS Code Copilot, enabling natural-language debugging, transformation writing, and tracking plan review, and a runtime probe confirms a live hosted MCP endpoint at mcp.rudderstack.com with proper OAuth-protected initialization. Missing for 10: independent third-party (non-vendor) hands-on validation of the MCP server's functionality beyond the probe check.", "evidenceIds": [ "rudderstack-docs-13", "rudderstack-docs-14", "rudderstack-docs-15", "rudderstack-docs-16", "rudderstack-docs-48", "rudderstack-docs-53", "rudderstack-probe-4", "rudderstack-probe-rt-1" ] }, { "productId": "rudderstack", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "RudderStack ships an official MCP server (and a Slack-based 'Rudder AI' agent) that lets users debug delivery errors, monitor pipelines, write/test transformations, and review audit logs 'all through natural language,' compatible with Claude, Cursor, Copilot, etc. A runtime probe confirms the hosted MCP endpoint is live and enforces OAuth as documented, corroborating the docs claims beyond marketing copy. Missing for 10: independent/hands-on user reports evaluating the natural-language experience itself (only vendor docs and a connectivity probe, no third-party usage account).", "evidenceIds": [ "rudderstack-docs-48", "rudderstack-docs-11", "rudderstack-docs-44", "rudderstack-docs-53", "rudderstack-probe-4", "rudderstack-probe-rt-1" ] }, { "productId": "rudderstack", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers RudderStack's SDKs, APIs, MCP server, and dashboards, but there is no mention of an official CLI tool for managing or interacting with RudderStack from the command line. missing for 10: any documentation or reference to an official CLI, its installation, or its command set.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "RudderStack documents a full public REST API (event ingestion, Pixel API for GET-based tracking, and management endpoints for transformations/libraries) explicitly aimed at programmatic control of connections, transformations, and other features, plus SDKs (Node, JS) confirmed installable/loadable via runtime probe. This is complemented by an official MCP server (mcp.rudderstack.com) that responds correctly to protocol probes, enabling AI agents to drive the product via natural language/API. Missing for 10: a published OpenAPI/swagger spec (probe found all candidate spec URLs 404) and independent third-party corroboration of the REST API's completeness beyond vendor docs.", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-22", "rudderstack-docs-33", "rudderstack-docs-47", "rudderstack-docs-54", "rudderstack-probe-3", "rudderstack-probe-rt-1", "rudderstack-probe-rt-2", "rudderstack-probe-4" ] }, { "productId": "rudderstack", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "RudderStack's hosted MCP server requires OAuth Bearer authentication (401 challenge with resource metadata) rather than being open, which implies some credentialed, per-client access control for agents connecting via Claude/Cursor/etc. However, there is no documentation of scoped or least-privilege permission tiers (e.g., read-only vs. write, workspace/action-level scopes) for these credentials — the pack only shows general API/token references (rudderstack-docs-33, rudderstack-docs-47) without any granular scoping mechanism described. Missing for 10: explicit documentation of scope/permission levels for API tokens or MCP OAuth grants, ability to restrict an agent to specific actions/resources, and any independent confirmation that scoping works as intended.", "evidenceIds": [ "rudderstack-probe-rt-1", "rudderstack-docs-53", "rudderstack-docs-33", "rudderstack-docs-47" ] }, { "productId": "rudderstack", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "RudderStack documents official SDKs (JavaScript, and Node.js confirmed via runtime probe install), a full API reference, and an official MCP server for AI-agent integration, with independent runtime confirmation of both the Node SDK package and the live MCP endpoint. missing for 10: independent third-party hands-on reviews of the SDKs themselves (beyond the npm install probe) and broader multi-language SDK evidence beyond JS/Node.", "evidenceIds": [ "rudderstack-docs-1", "rudderstack-docs-24", "rudderstack-docs-25", "rudderstack-docs-33", "rudderstack-docs-53", "rudderstack-probe-4", "rudderstack-probe-rt-1", "rudderstack-probe-rt-2" ] }, { "productId": "rudderstack", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item describes a webhook destination or webhook subscription mechanism for consuming RudderStack events; only generic references to '200+ third-party tools' and APIs are given, none naming webhooks specifically.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "ai-decisioning-agents", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "RudderStack is a customer data infrastructure/CDP pipeline tool (event collection, warehouse sync, audience activation, transformations) — not an autonomous AI decisioning/orchestration engine that picks messages, timing, and channels per customer with measurable lift. That capability belongs to a different product category (e.g., a journey orchestration or AI marketing decisioning engine); RudderStack's AI features (MCP, Rudder AI in Slack) are for pipeline debugging/data management, not customer-facing decisioning.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "RudderStack documents a static API reference page (rudderstack-docs-21, -33, -54) but nothing describes an interactive, runnable-example explorer; a direct probe for OpenAPI/Swagger specs at standard paths returned 404 across all candidates, suggesting no live interactive API console exists (rudderstack-probe-3).", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-33", "rudderstack-docs-54", "rudderstack-probe-3" ] }, { "productId": "rudderstack", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The probe explicitly checked for a machine-readable API spec at common locations (openapi.json, swagger.json, .well-known/openapi.json) and all returned 404, indicating no downloadable OpenAPI spec exists despite RudderStack having an API reference page.", "evidenceIds": [ "rudderstack-probe-3", "rudderstack-docs-33" ] }, { "productId": "rudderstack", "storyId": "api-sandbox", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack docs describe an Event Playground for sending sample events and testing data flow without instrumentation, and MCP-based transformation testing against sample events before deployment — both let a user validate behavior without live production traffic. However, there's no documented dedicated 'sandbox environment' or staging workspace separate from production, no mention of environment cloning, and the self-hosted OSS option (a possible sandbox route) isn't framed as a testing sandbox. Missing for 10: explicit sandbox/staging workspace concept, docs on isolating test data from production destinations, and independent confirmation these testing tools fully prevent production data exposure.", "evidenceIds": [ "rudderstack-docs-23", "rudderstack-docs-34", "rudderstack-docs-14", "rudderstack-docs-48", "rudderstack-docs-20" ] }, { "productId": "rudderstack", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents RudderStack's APIs, SDKs, and MCP server but contains no mention of API versioning scheme or a documented deprecation policy; the OpenAPI probe explicitly returned 404s, showing no discoverable formal API spec artifacts either.", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-33", "rudderstack-probe-3" ] }, { "productId": "rudderstack", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack details single-item API/MCP actions (send event, debug a delivery error, write one transformation, review one tracking plan) but never describes a bulk/batch operation mode where an AI agent could act across many items at once. No mention of batch APIs, bulk import/export endpoints, or multi-item MCP tool calls.", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-33", "rudderstack-docs-48", "rudderstack-docs-13", "rudderstack-docs-14" ] }, { "productId": "rudderstack", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack supports event-driven automation via Transformations (custom JS/Python code that runs automatically on incoming events to filter/enrich/reshape before reaching destinations), Tracking Plans that 'monitor and act on non-compliant event data', and Alerts for critical data issues — these act as rule-like triggers on events. However, there's no evidence of a general-purpose, user-defined 'if-this-then-that' rule builder with arbitrary conditions/actions beyond these fixed built-in mechanisms (transformations, audiences, consent, alerts). Missing for 10: an explicit rules/automation engine UI, documented conditional logic across arbitrary event types, and independent confirmation of custom trigger-action workflows beyond code-based transformations.", "evidenceIds": [ "rudderstack-docs-49", "rudderstack-docs-39", "rudderstack-docs-42", "rudderstack-docs-37", "rudderstack-docs-27" ] }, { "productId": "rudderstack", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "RudderStack is a customer data/event pipeline platform, not a workflow/job scheduling or orchestration tool; scheduling recurring jobs/workflows is outside its product category (its pipelines run on event streams/syncs, not user-defined cron-like jobs), so this axis is a category error rather than an unmet capability.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "RudderStack's Profiles feature uses version-controlled YAML for entity definitions, and its MCP-based AI features let users write/test transformation code before deploying and review audit logs — a partial nod to versioning/review, but there is no documented UI or feature for rolling back deployed automations/transformations to a prior version. Missing for 10: explicit rollback mechanism for transformations/pipelines, version history browsing, and independent confirmation these controls exist beyond Profiles YAML.", "evidenceIds": [ "rudderstack-docs-19", "rudderstack-docs-35", "rudderstack-docs-14", "rudderstack-docs-48" ] }, { "productId": "rudderstack", "storyId": "composable-warehouse-mode", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "RudderStack's Profiles feature lets engineers declare entities/attributes in version-controlled YAML directly against warehouse tables, generating warehouse-native SQL for identity resolution and feature aggregation, and its Audiences feature builds audiences on warehouse sources and activates them downstream without re-collecting event data, backed by dedicated Reverse ETL sources that sync from the warehouse/lake/DB. missing for 10: independent/hands-on corroboration of the warehouse-native reverse ETL workflow, and a concrete case study confirming no re-collection occurs in practice.", "evidenceIds": [ "rudderstack-docs-19", "rudderstack-docs-35", "rudderstack-docs-27", "rudderstack-docs-38", "rudderstack-docs-36", "rudderstack-docs-26" ] }, { "productId": "rudderstack", "storyId": "computed-predictive-traits", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack's Profiles feature lets marketers declare entities/attributes in YAML and automatically computes traits via feature aggregation and identity resolution (docs-19, docs-31, docs-35), and Audiences can be built on those warehouse profiles and activated to downstream tools (docs-27, docs-38). However, there is no evidence of built-in predictive modeling (LTV, churn, purchase propensity scores) — the docs only mention generic 'feature aggregation' and enrichment, not ML-based scoring outputs. Missing for 10: explicit predictive scoring models (LTV/churn/propensity) native to the product, and confirmation these scores can be directly used as targeting criteria in audience builders.", "evidenceIds": [ "rudderstack-docs-19", "rudderstack-docs-31", "rudderstack-docs-35", "rudderstack-docs-27", "rudderstack-docs-38" ] }, { "productId": "rudderstack", "storyId": "consent-enforcement", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "RudderStack's docs explicitly list a 'Consent Management' feature ('Capture consent and stay compliant with GDPR and CCPA'), indicating opt-in/opt-out consent capture is a documented product capability, and 'Tracking Plans' can monitor/act on non-compliant event data at the source. However, there is no detail on how consent categories map to specific destinations, no evidence of automatic per-destination suppression logic, and no independent or hands-on confirmation that opt-outs are actually honored downstream across the 200+ destinations. Missing for 10: technical documentation of consent-category-to-destination enforcement, hands-on/independent verification that opt-outs propagate correctly, and detail on supported consent frameworks (e.g., IAB TCF, OneTrust integration specifics).", "evidenceIds": [ "rudderstack-docs-8", "rudderstack-docs-40", "rudderstack-docs-7", "rudderstack-docs-39" ] }, { "productId": "rudderstack", "storyId": "deletion-suppression-requests", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows RudderStack's Consent Management feature captures consent for GDPR/CCPA and Tracking Plans can flag non-compliant events, but there is no mention of a user deletion/suppression request API or workflow that forwards those requests to connected destinations. This is a fair capability to expect from a CDP (peers like Segment offer a User Deletion API), so absence of evidence is 'none' rather than 'na'.", "evidenceIds": [ "rudderstack-docs-8", "rudderstack-docs-40", "rudderstack-docs-7", "rudderstack-docs-39" ] }, { "productId": "rudderstack", "storyId": "delivery-observability", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "RudderStack docs explicitly cite Live Events (near real-time source/destination event viewing), a Health Dashboard for pipeline metrics, Alerts for critical data issues, and MCP-powered destination delivery error investigation with root-cause analysis. These directly map to debugger views, delivery metrics, and alerting. Missing for 10: no independent/hands-on validation of the debugger UI itself or alerting reliability, and no detail on granularity of per-destination delivery metrics beyond marketing bullet points.", "evidenceIds": [ "rudderstack-docs-9", "rudderstack-docs-10", "rudderstack-docs-12", "rudderstack-docs-13", "rudderstack-docs-42", "rudderstack-docs-43", "rudderstack-docs-50", "rudderstack-docs-48" ] }, { "productId": "rudderstack", "storyId": "destination-catalog-breadth", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm 200+ documented destination integrations, plus per-destination transformation capability (filter, enrich, reshape events before delivery) and warehouse/event destination routing. Community testimonials corroborate real-world use for centralizing analytics routing across platforms. Missing for 10: a searchable/browsable destination catalog listing with explicit per-destination field-mapping UI documentation and independent hands-on verification of mapping/filtering granularity.", "evidenceIds": [ "rudderstack-docs-2", "rudderstack-docs-45", "rudderstack-docs-49", "rudderstack-docs-21", "rudderstack-comm-2" ] }, { "productId": "rudderstack", "storyId": "event-replay-backfill", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While RudderStack documents forwarding live events to destinations, syncing from warehouses, and reverse ETL, no evidence describes a mechanism to replay previously archived/ingested events into a newly added destination or backfill historical data after a pipeline outage. Reverse ETL (docs-4/docs-36) syncs current warehouse state, not archived event replay, so it doesn't satisfy the specific replay-portability need.", "evidenceIds": [ "rudderstack-docs-4", "rudderstack-docs-36", "rudderstack-docs-20" ] }, { "productId": "rudderstack", "storyId": "identity-stitching", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "RudderStack's 'Profiles' feature explicitly resolves identities and builds a customer 360 in the warehouse via version-controlled YAML that 'handles identity resolution, incremental computation, and feature aggregation automatically,' giving data engineers a documented, configurable rules-based approach to stitching known/anonymous activity into unified profiles. Missing for 10: independent/hands-on validation of cross-device stitching accuracy, deeper documentation on specific identity-resolution rule configuration (e.g., merge keys, precedence rules), and community corroboration of this specific capability.", "evidenceIds": [ "rudderstack-docs-5", "rudderstack-docs-19", "rudderstack-docs-26", "rudderstack-docs-31", "rudderstack-docs-35" ] }, { "productId": "rudderstack", "storyId": "inline-event-transformations", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "RudderStack's Transformations feature explicitly lets users filter, enrich, and reshape event data with custom JavaScript/Python code before it reaches destinations, and MCP tooling supports writing and testing transformation code against sample events. Missing for 10: independent hands-on verification of transformation code execution/testing beyond docs, and more detail on supported languages/runtime limits.", "evidenceIds": [ "rudderstack-docs-49", "rudderstack-docs-3", "rudderstack-docs-37", "rudderstack-docs-14", "rudderstack-docs-47" ] }, { "productId": "rudderstack", "storyId": "nl-audience-builder", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "RudderStack markets 'AI powered chat interfaces' that let business teams 'segment and activate data' (rudderstack-docs-51), which gestures at the story, but there's no documentation of a natural-language-to-segment-definition workflow, no mention of schema grounding, or a review step before activation. The MCP feature set (docs-13/14/15/16/48/52/53) covers tracking plans, transformations, and delivery debugging via natural language, but never audience/segment building. Missing for 10: concrete docs on an AI audience-builder tool, evidence it reads the actual schema, and a review/approval UX for generated segment definitions.", "evidenceIds": [ "rudderstack-docs-51", "rudderstack-docs-6", "rudderstack-docs-27", "rudderstack-docs-38" ] }, { "productId": "rudderstack", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack documents APIs for sending events (docs-21/22/54) and for managing connections, transformations, and libraries (docs-33/47), plus an MCP server that lets you debug pipelines, review tracking plans, and test transformations via natural language (docs-13/14/16/48). However, there's no evidence of a comprehensive OpenAPI spec or full CRUD parity for every UI feature (audiences, consent management, bot management, alerts) — the openapi probe returned 404s across candidate paths (rudderstack-probe-3), suggesting API coverage is narrower than the full UI surface. Missing for 10: documented API endpoints for audiences, consent management, alerts, and health dashboard equivalent to UI capabilities, and a public OpenAPI/swagger spec confirming full parity.", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-33", "rudderstack-docs-47", "rudderstack-docs-48", "rudderstack-probe-3", "rudderstack-probe-4" ] }, { "productId": "rudderstack", "storyId": "openness-full-export", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "RudderStack's architecture inherently supports data portability: it streams events to customer-owned warehouses (open formats via SQL) and offers a self-hostable open-source version depending only on PostgreSQL, plus APIs to manage connections/transformations. Community users cite 'total control of our data' as a reason to switch from Segment, reinforcing an open, no-lock-in stance. Missing for 10: no explicit documented bulk-export/data-portability feature or migration-out tooling, and no first-party statement guaranteeing full data extraction in open formats when leaving the platform.", "evidenceIds": [ "rudderstack-docs-20", "rudderstack-docs-32", "rudderstack-docs-4", "rudderstack-docs-33", "rudderstack-comm-2" ] }, { "productId": "rudderstack", "storyId": "openness-open-license", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Docs claim an 'open source version of RudderStack' (rudderstack-docs-20/32) dependent only on PostgreSQL, but community threads document that RudderStack moved away from a permissive/AGPLv3 license to the Elastic License (a source-available, not OSI-approved open license) specifically to block competitors like Hightouch from reusing the code, contradicting the 'open license' framing. Missing for 10: clear evidence of which specific license currently governs the source, and confirmation whether it meets standard open-source definitions (freedom to modify/redistribute commercially).", "evidenceIds": [ "rudderstack-docs-20", "rudderstack-docs-32", "rudderstack-comm-6", "rudderstack-comm-7" ] }, { "productId": "rudderstack", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly state the open-source version of RudderStack is a standalone system dependent only on PostgreSQL, confirming a self-hostable core product, and community comments corroborate real-world self-hosted/self-managed usage with 'total control of our data.' Missing for 10: detailed self-hosting deployment guide/infra requirements and independent verification of feature parity between OSS and cloud versions.", "evidenceIds": [ "rudderstack-docs-20", "rudderstack-docs-32", "rudderstack-comm-2", "rudderstack-comm-1" ] }, { "productId": "rudderstack", "storyId": "pii-field-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "RudderStack's Transformations feature (custom JS/Python) is documented to 'filter, enrich, and reshape event data before it reaches your destinations,' which could technically implement masking/hashing/field-level filtering per destination, and Tracking Plans/Consent Management address broader compliance. However, there is no explicit documentation of built-in PII hashing, masking, or field-level filtering controls — this would require custom transformation code rather than a native privacy-control feature. Missing for 10: dedicated PII hashing/masking UI or config, explicit field-level filtering per destination, documentation or example specifically addressing sensitive-attribute redaction, and independent confirmation of this use case.", "evidenceIds": [ "rudderstack-docs-49", "rudderstack-docs-37", "rudderstack-docs-39", "rudderstack-docs-40" ] }, { "productId": "rudderstack", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, regional hosting options, or geographic storage location controls for RudderStack Cloud; the pack covers open-source self-hosting (which implicitly allows control of location) but never states region selection or residency guarantees. Missing for 10: explicit region/residency selection features, documentation of hosting regions (EU/US), or compliance statements tying storage location to user choice.", "evidenceIds": [ "rudderstack-docs-20", "rudderstack-docs-32" ] }, { "productId": "rudderstack", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI-model training data usage, opt-outs, or any explicit privacy commitment about not using customer data to train AI models; consent management and compliance features (GDPR/CCPA) are mentioned but do not speak to AI training data use.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "RudderStack documents consent management and general GDPR/CCPA compliance capture, but there is no concrete documentation of data retention settings, deletion APIs, or right-to-be-forgotten workflows for AI-native users to control. Missing for 10: explicit data retention period controls, a documented deletion/erasure API or workflow, and any evidence of AI-agent access to trigger deletion.", "evidenceIds": [ "rudderstack-docs-8", "rudderstack-docs-40" ] }, { "productId": "rudderstack", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "This story concerns opting out of telemetry/usage tracking within an AI coding tool or agent product itself, but RudderStack is a customer data platform whose core purpose is collecting and routing event/telemetry data for its customers, not a product with its own developer-tool telemetry to opt out of. This is a category mismatch — the axis does not apply to RudderStack's product type.", "evidenceIds": [] }, { "productId": "rudderstack", "storyId": "realtime-audience-activation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "RudderStack documents building audiences (from warehouse or event sources) and activating them to downstream tools (rudderstack-docs-6, -27, -38), plus real-time/near-real-time event visibility (rudderstack-docs-10, -43), which supports continuous sync infrastructure. However, there is no explicit documentation of incremental/near-real-time membership updates (entry/exit) for audience sync specifically to ad platforms, nor evidence of sync frequency or refresh cadence for reverse-ETL audience activation. Missing for 10: explicit documentation of audience sync scheduling/frequency, confirmation of near-real-time membership add/remove semantics, and independent/hands-on validation of continuous audience activation to ad platforms.", "evidenceIds": [ "rudderstack-docs-6", "rudderstack-docs-27", "rudderstack-docs-38", "rudderstack-docs-10", "rudderstack-docs-43", "rudderstack-docs-4", "rudderstack-docs-36" ] }, { "productId": "rudderstack", "storyId": "sdk-event-collection", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "RudderStack documents a JavaScript SDK for web tracking, a Node SDK verified installable at runtime, and API/Pixel references for server-side track/identify/page-style event tracking, plus a standard event spec and Event Playground for testing. Community evidence corroborates real-world use replacing Segment for cross-platform analytics collection. missing for 10: explicit documented mobile SDK (iOS/Android) references and a single canonical spec page enumerating track/identify/page methods across all SDKs with independent hands-on confirmation for mobile/server SDKs.", "evidenceIds": [ "rudderstack-docs-1", "rudderstack-docs-21", "rudderstack-docs-22", "rudderstack-docs-23", "rudderstack-docs-25", "rudderstack-probe-rt-2", "rudderstack-comm-2" ] }, { "productId": "rudderstack", "storyId": "server-ingest-http", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "RudderStack documents an HTTP API for sending events server-to-source ([rudderstack-docs-21],[rudderstack-docs-33]) plus a Pixel/GET API and a Node SDK confirmed installable at runtime ([rudderstack-probe-rt-2]), implying server-to-server ingestion is supported. However, the evidence pack lacks explicit documentation of authentication mechanisms (write keys, tokens) for the HTTP ingestion endpoint, delivery-guarantee semantics (retries, at-least-once, dedup), or an OpenAPI/API reference confirming schema details — the openapi probe returned 404s. missing for 10: explicit auth/write-key documentation for the ingestion endpoint, documented delivery/retry guarantees, and a working OpenAPI spec or full API reference confirming these details.", "evidenceIds": [ "rudderstack-docs-21", "rudderstack-docs-33", "rudderstack-docs-54", "rudderstack-probe-rt-2", "rudderstack-probe-3" ] }, { "productId": "rudderstack", "storyId": "third-party-source-feeds", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "RudderStack documents 200+ cloud destination integrations plus Cloud/Reverse ETL sources that sync data from warehouses, data lakes, and databases (not just instrumented apps), and community reviews confirm real-world use consolidating analytics data from multiple platforms. missing for 10: an explicit list of supported third-party SaaS 'Cloud App' sources (e.g., Salesforce, Stripe) rather than just generic 'warehouse/lake/database' reverse ETL sources, and independent hands-on verification of a specific cloud-app source connector.", "evidenceIds": [ "rudderstack-docs-2", "rudderstack-docs-4", "rudderstack-docs-36", "rudderstack-docs-45", "rudderstack-comm-2", "rudderstack-comm-1" ] }, { "productId": "rudderstack", "storyId": "tracking-plan-enforcement", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "RudderStack's docs explicitly describe a 'Tracking Plans' feature that 'monitors and acts on non-compliant event data at the source' and lets you 'review Tracking Plans and their event schemas,' indicating schema enforcement is a first-party capability. However, the evidence never spells out the concrete enforcement mechanics (flag vs. block vs. quarantine) or shows a hands-on example of a violating event being stopped. Missing for 10: explicit documentation of block/quarantine behavior, a hands-on/community example of enforcement in action, and detail on how violations are surfaced to prevent downstream corruption.", "evidenceIds": [ "rudderstack-docs-7", "rudderstack-docs-39", "rudderstack-docs-16", "rudderstack-docs-52" ] }, { "productId": "rudderstack", "storyId": "unified-profile-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "RudderStack Profiles documents a warehouse-native 'store' — you declare entities/attributes in YAML and the system generates SQL that performs identity resolution and builds a customer 360 view, which data engineers can then query directly in the warehouse. However, there's no documented dedicated profile-query API (REST/GraphQL) for pulling traits, identifiers, or event history programmatically — the general RudderStack API docs cover event ingestion and connection management, not profile retrieval. Missing for 10: a first-party profile/traits query API or SDK method, explicit event-history retrieval endpoint, and independent confirmation of querying resolved profiles outside the warehouse.", "evidenceIds": [ "rudderstack-docs-19", "rudderstack-docs-35", "rudderstack-docs-26", "rudderstack-docs-31", "rudderstack-docs-33", "rudderstack-docs-21" ] }, { "productId": "rudderstack", "storyId": "visual-audience-builder", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm RudderStack has an 'Audiences' feature to build audiences on warehouse sources and activate them downstream, but nothing describes a visual, no-SQL builder or size-estimation-before-activation UX — in fact the closest technical detail (Profiles/YAML generating warehouse SQL) suggests a code-driven rather than pure drag-and-drop marketer experience. Missing for 10: evidence of a visual/no-code audience builder UI, confirmation that no SQL is needed, and any mention of estimated audience size shown before activation.", "evidenceIds": [ "rudderstack-docs-6", "rudderstack-docs-27", "rudderstack-docs-38", "rudderstack-docs-19", "rudderstack-docs-35" ] }, { "productId": "rudderstack", "storyId": "warehouse-sync-raw", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "RudderStack explicitly supports warehouse/lake destinations (Snowflake, BigQuery, ClickHouse, S3-type object storage) with automatic schema management, scheduled Reverse ETL syncs from warehouses, and Profiles building customer 360 via warehouse-native SQL, giving data engineers control over landing raw events/profiles in their own infra. Community feedback corroborates 'total control of our data' and one-place data routing, and the open-source self-hosted option reinforces warehouse-native control.\n\nmissing for 10: explicit named connector list/setup docs for Snowflake/BigQuery/ClickHouse/S3 destinations, and details on schedule/frequency configuration for warehouse syncs.", "evidenceIds": [ "rudderstack-docs-4", "rudderstack-docs-18", "rudderstack-docs-30", "rudderstack-docs-19", "rudderstack-docs-35", "rudderstack-docs-26", "rudderstack-docs-20", "rudderstack-comm-2" ] }, { "productId": "segment", "storyId": "agent-manages-pipeline", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment's documented Public API supports full CRUD on Sources, Destinations, Warehouses, and Tracking Plans, and a runtime probe confirms it is live and auth-gated, giving an AI agent a genuine programmatic path to build/manage pipelines; the Profile API also lets an agent inspect resolved profiles/deliveries. However, there is no evidence of a documented or first-party MCP server, and no evidence of API endpoints specifically for inspecting delivery/event logs (only profile queries and general CRUD are documented) — missing for 10: an official MCP server, and documented delivery/event-log inspection endpoints beyond the Profile API.", "evidenceIds": [ "segment-docs-4", "segment-docs-18", "segment-docs-29", "segment-docs-41", "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1", "segment-docs-10", "segment-docs-19" ] }, { "productId": "segment", "storyId": "agent-queries-activates-audiences", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Segment documents strong programmatic access for querying customer data (Profile API for reading user/account profiles) and a Public API for CRUD on workspace resources, plus reverse ETL/audience-sync docs, all confirmed live via runtime probes. However, the evidence never documents an API path for programmatically *creating* or activating Audiences (Audiences/Engage are described via UI-centric building blocks like traits/computed traits, not an audience-creation endpoint), and there is no MCP server or agent-native interface mentioned anywhere in the pack. missing for 10: documented API/MCP for creating and activating audiences end-to-end, evidence of an official MCP server, independent confirmation that audience creation is dashboard-free.", "evidenceIds": [ "segment-docs-10", "segment-docs-19", "segment-docs-31", "segment-docs-9", "segment-docs-32", "segment-docs-4", "segment-docs-18", "segment-probe-rt-1", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an llms.txt file or agent-oriented documentation; a direct probe for markdown-based docs (segment.com/docs/.md) returned HTTP 404, confirming absence rather than just lack of mention.", "evidenceIds": [ "segment-probe-1" ] }, { "productId": "segment", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Segment's pricing page claims 'Build AI-powered audiences from a complete customer view,' suggesting some AI-driven audience/insight capability, but no docs elaborate on what AI-generated insights or suggestions actually look like, how they surface in-product, or independent corroboration of this feature working. Missing for 10: detailed documentation of AI insight generation, in-product UI examples, and independent/hands-on validation of AI-powered audience suggestions.", "evidenceIds": [ "segment-docs-37" ] }, { "productId": "segment", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Segment supports background automations such as Audiences (auto-computed and synced from event/trait data), Functions (custom code that runs unattended to move data), and Reverse ETL (scheduled warehouse syncs), all of which execute autonomously once configured. However, these are rule-based data-pipeline automations rather than AI-driven agentic workflows, and there is no evidence of AI-native orchestration, decision-making, or agent-triggered automation. Missing for 10: evidence of AI/agent-driven automation logic, hands-on validation of autonomous run reliability, and any AI-native automation-builder tooling.", "evidenceIds": [ "segment-docs-9", "segment-docs-32", "segment-docs-38", "segment-docs-5", "segment-docs-30", "segment-docs-7" ] }, { "productId": "segment", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a built-in AI assistant that users can delegate tasks to within Segment; docs mention 'AI-powered audiences' as a feature output, not an interactive assistant, and there's no chat/agent interface described.", "evidenceIds": [ "segment-docs-37" ] }, { "productId": "segment", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment ships a documented, token-authenticated Public API and a server-side Node SDK (analytics-node) that can perform CRUD and event tracking without any UI, and runtime probes confirm both endpoints are live and functable outside a browser context, which supports scripted/CI usage. However, there is no vendor documentation or example specifically addressing CI pipelines, headless test/automation workflows, or non-interactive workspace provisioning at scale. Missing for 10: explicit CI/CD integration guides, headless automation examples, and evidence of usage in automated pipelines beyond basic API/SDK capability.", "evidenceIds": [ "segment-docs-4", "segment-docs-18", "segment-docs-29", "segment-probe-rt-1", "segment-probe-rt-2", "segment-docs-2" ] }, { "productId": "segment", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Segment is a customer data platform (CDP) for collecting, unifying, and routing customer data to destinations, not an AI agent or MCP client role; the evidence pack contains no mention of MCP servers or plugging in agent tools. This axis is a category error for this type of product.", "evidenceIds": [] }, { "productId": "segment", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official MCP server for Segment; documentation covers REST/Public API, SDKs, and destinations but nothing about MCP integration for AI agents.", "evidenceIds": [] }, { "productId": "segment", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Segment is a customer data platform with APIs and SDKs, not an agent or chat interface intended to be operated via natural-language commands; no evidence pack item mentions an NL command interface. This is a category mismatch for the product's role rather than a missing feature.", "evidenceIds": [] }, { "productId": "segment", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official Segment CLI anywhere in the evidence pack; Segment offers SDKs, a Public API, and Functions but nothing described as a CLI for AI-native workflows. missing for 10: any mention of an official CLI tool, its commands, or AI-native workflow integration.", "evidenceIds": [] }, { "productId": "segment", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment ships a well-documented Public API with CRUD operations across Sources, Destinations, Warehouses, and Tracking Plans, an OpenAPI spec, authentication/rate-limit/pagination docs, and official SDKs; runtime probes confirm both the Public API and tracking ingest endpoints are live and properly auth-gated. This is a mature, documented, programmatically-drivable surface suitable for AI-native automation. Missing for 10: no explicit mention of an official MCP server or AI-agent-specific tooling/examples built on top of the API.", "evidenceIds": [ "segment-docs-4", "segment-docs-18", "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Segment's Public API documentation explicitly references creating API tokens with defined 'Scope, Permissions and security' sections, and runtime probes confirm the API is cleanly auth-gated (401 without a token), indicating token-based, presumably scoped credential issuance exists. However, there's no evidence of agent-specific credential issuance, fine-grained least-privilege permission levels, or guidance for scoping tokens specifically for AI-agent use cases. Missing for 10: agent-specific credential/token guidance, detailed enumeration of scope granularity (e.g., read-only vs specific resource scopes), and any first-party or community confirmation of least-privilege token workflows in agentic contexts.", "evidenceIds": [ "segment-docs-x2", "segment-probe-rt-1" ] }, { "productId": "segment", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment ships official SDKs (e.g., analytics.js, @segment/analytics-node) and a documented Public API with OpenAPI spec, CRUD operations, auth, rate limits, and pagination — confirmed live via runtime probes showing the SDK installs keylessly and the API is properly auth-gated. missing for 10: no evidence of AI-agent-specific SDK tooling (e.g., function-calling schemas, MCP server, or LLM-oriented client) beyond the general-purpose SDKs.", "evidenceIds": [ "segment-docs-4", "segment-docs-18", "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Segment's Sources/Destinations model, Functions (custom JS destinations), and the Public/Profile APIs, but none of the entries explicitly document a webhook-subscription mechanism for outbound event notifications; Functions could theoretically be used to build one, but that's not the same as a documented webhook-subscribe capability. Missing for evidence: explicit documentation of a 'Webhooks' destination or event-subscription API, sample webhook payload/signature verification, or setup docs.", "evidenceIds": [] }, { "productId": "segment", "storyId": "ai-decisioning-agents", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Segment/Engage documentation covers audience building, identity resolution, and 'AI-powered audiences' as a pricing tagline, but there is no evidence of autonomous AI decisioning agents that select message, timing, and channel per customer within guardrails, nor any measurable lift reporting for such agentic decisions.", "evidenceIds": [ "segment-docs-37", "segment-docs-23", "segment-docs-32" ] }, { "productId": "segment", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Segment publishes an interactive Public API reference (docs.segmentapis.com) with a downloadable OpenAPI spec, 'Create a test request', and 'Install and use an SDK' sections, and runtime probes confirm the underlying API endpoints are live and respond with structured errors matching docs. This supports an AI-native user exploring a live, runnable API reference, though the pack lacks direct hands-on confirmation of executing the 'test request' feature itself. missing for 10: independent hands-on verification of the 'Create a test request' interactive flow, evidence of AI-specific tooling (e.g. OpenAPI-to-agent integration) beyond the spec download.", "evidenceIds": [ "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment's Public API reference explicitly offers a downloadable OpenAPI specification ('Download OpenAPI specification: Download'), and the API is confirmed live via runtime probe. Missing for 10: independent third-party confirmation of the spec's completeness/versioning beyond vendor docs, and no explicit mention of machine-readable spec for other APIs (e.g., tracking/Profile API).", "evidenceIds": [ "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1" ] }, { "productId": "segment", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item describes a dedicated sandbox/test workspace or environment isolated from production data; the docs only cover live API endpoints, tracking calls, and workspace CRUD without any sandbox/test-mode distinction. missing for 10: dedicated sandbox/test environment docs, guidance on isolating test events from production data, any sandbox API or flag.", "evidenceIds": [] }, { "productId": "segment", "storyId": "api-versioning-policy", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Segment's Public API docs explicitly include a semantic version number (73.3.0), an OpenAPI spec download, and a dedicated 'Versioning' section covering 'Accessing versions' and 'Backwards-incompatible or breaking changes,' which directly documents a deprecation/versioning policy; the live API also enforces token auth as documented (segment-probe-rt-1). Missing for 10: the actual deprecation policy text/timelines, changelog history, and independent/community confirmation that the policy is honored in practice.", "evidenceIds": [ "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1" ] }, { "productId": "segment", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment supports bulk-style operations through its Public API (CRUD across Sources, Destinations, Warehouses, Tracking Plans, with documented rate limits/pagination), Reverse ETL for syncing bulk warehouse data to destinations, and the Profile API for querying entire user/account objects programmatically — all of which let an AI-native user or script operate across many items at once. However, evidence never shows a dedicated bulk/batch endpoint (e.g., bulk import/export) or explicit agent/AI-native tooling for large-scale operations, only general CRUD + rate-limit docs. Missing for 10: explicit bulk/batch API endpoints, documented batch size limits or throughput guarantees, and any AI-agent-specific bulk workflow examples.", "evidenceIds": [ "segment-docs-7", "segment-docs-4", "segment-docs-18", "segment-docs-x2", "segment-docs-44", "segment-probe-rt-1" ] }, { "productId": "segment", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Segment's Audiences/computed traits can be built from events and traits and then synced automatically to destinations, which approximates rule-based triggering of downstream actions, and Functions allow custom event-driven transforms/sends. However, there is no documented explicit rules engine (e.g., 'if event X then do Y') or workflow/journey builder for conditional multi-step automation. Missing for 10: an explicit conditional automation/workflow engine (e.g., Journeys), documented trigger syntax for arbitrary if/then rules, and independent evidence of real-time rule-based action execution.", "evidenceIds": [ "segment-docs-9", "segment-docs-32", "segment-docs-38", "segment-docs-5", "segment-docs-30" ] }, { "productId": "segment", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Segment's docs describe Reverse ETL, Functions, and Audiences as internally-scheduled sync/compute jobs, but there is no evidence of an API or interface letting an AI-native user programmatically create or manage arbitrary recurring jobs/workflows. The Public API only covers CRUD on sources/destinations/tracking plans, not job scheduling. Missing for 10: any documented scheduling API, cron-like job creation, or workflow orchestration surface for AI agents.", "evidenceIds": [ "segment-docs-7", "segment-docs-9", "segment-docs-4", "segment-docs-18" ] }, { "productId": "segment", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "While Segment's Public API supports CRUD operations on resources like Tracking Plans, Sources, and Destinations, and the API docs mention API versioning (for backwards-compatible changes), there is no evidence of version history, review workflows, or rollback capabilities for Segment's automations (e.g., Functions, Tracking Plans, Audiences) themselves.", "evidenceIds": [ "segment-docs-18", "segment-docs-x2", "segment-docs-5" ] }, { "productId": "segment", "storyId": "composable-warehouse-mode", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment explicitly documents a Reverse ETL feature that extracts data from a warehouse via a user-provided query and syncs it to destinations without re-collecting via SDKs, matching the warehouse-native activation ask. However, the evidence shows Audiences are built primarily from tracking events/traits/computed traits (not natively from arbitrary warehouse tables/models), so the 'define models and audiences on warehouse tables' half of the story is not clearly supported. Missing for 10: audience/model definition directly on warehouse tables, warehouse-native modeling docs, and independent/hands-on corroboration of Reverse ETL working end-to-end.", "evidenceIds": [ "segment-docs-7", "segment-docs-9", "segment-docs-38" ] }, { "productId": "segment", "storyId": "computed-predictive-traits", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm computed traits can be built from tracking events and traits and used to build Audiences synced to destinations for targeting (segment-docs-9, segment-docs-38, segment-docs-32). However, there's only a vague pricing-page mention of 'AI-powered audiences' (segment-docs-37) with no concrete documentation of predictive scoring models like LTV, churn, or purchase propensity computed on profiles. Missing for 10: dedicated docs/feature describing predictive scoring (LTV, churn, purchase propensity) computation and how such scores are surfaced/activated in targeting, independent corroboration of predictive features working.", "evidenceIds": [ "segment-docs-9", "segment-docs-38", "segment-docs-32", "segment-docs-37", "segment-docs-23" ] }, { "productId": "segment", "storyId": "consent-enforcement", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment documents a dedicated Consent Management feature that captures end-user consent preferences and a Privacy Portal for regulatory compliance (GDPR/CCPA/HIPAA), and states it recommends Consent Management to enforce preferences related to cookies/data collection. However, evidence does not detail how consent categories map to specific destinations or confirm automatic enforcement across all 700+ downstream integrations, nor is there independent/hands-on verification of enforcement behavior. Missing for 10: technical detail on per-destination consent enforcement mechanics, evidence of opt-out actually blocking data flow to specific tools, and independent/hands-on confirmation beyond vendor docs.", "evidenceIds": [ "segment-docs-11", "segment-docs-12", "segment-docs-17", "segment-docs-25", "segment-docs-33", "segment-docs-40" ] }, { "productId": "segment", "storyId": "deletion-suppression-requests", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Segment's Privacy Portal explicitly supports GDPR/CCPA compliance workflows, including detecting/classifying customer data and streamlining privacy regulation responses, and Segment documents user deletion/suppression capabilities as part of its privacy tooling that propagate through its connected destinations infrastructure (which spans hundreds of tools). Missing for 10: no explicit documentation snippet showing the deletion/suppression request forwarded to destinations mechanism in detail, and no independent/hands-on verification of end-to-end deletion propagation to third-party destinations.", "evidenceIds": [ "segment-docs-11", "segment-docs-17", "segment-docs-25", "segment-docs-6" ] }, { "productId": "segment", "storyId": "delivery-observability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers Segment's sources/destinations, identity resolution, reverse ETL, and API/schema features, but nothing addresses live event debugging, per-destination delivery metrics/success-failure dashboards, or alerting on delivery failures. Missing for 10: any mention of a live event debugger view, delivery success/error rate metrics per destination, and alerting/notification configuration for pipeline failures.", "evidenceIds": [] }, { "productId": "segment", "storyId": "destination-catalog-breadth", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment documents routing events to 700+ destinations via a documented Connections catalog, with Functions for custom destinations, a Spec for consistent data formatting, and a Public API for managing sources/destinations/warehouses/tracking plans; runtime probes confirm the Public API and ingest endpoints are live and functioning as documented. Missing for 10: explicit documentation/evidence of per-destination field mapping UI and filtering rules (e.g., event/property-level filters per destination) beyond general catalog and API references, and independent hands-on validation of the mapping/filtering workflow itself.", "evidenceIds": [ "segment-docs-6", "segment-docs-3", "segment-docs-15", "segment-docs-5", "segment-docs-4", "segment-docs-18", "segment-probe-rt-1", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "event-replay-backfill", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Segment's docs describe Data Storage Destinations that retain raw event data in warehouses/S3, plus Reverse ETL to sync warehouse data back out to third-party destinations — together these could support backfilling a newly added tool, but no evidence pack item explicitly describes a 'replay' feature for re-sending archived Segment events into a new destination or recovering from a broken pipeline. Missing for 10: explicit replay/backfill documentation, guidance on replaying archived events specifically (vs. general warehouse storage + Reverse ETL), and any hands-on/community confirmation that replay works as expected.", "evidenceIds": [ "segment-docs-13", "segment-docs-20", "segment-docs-7", "segment-docs-34", "segment-docs-42" ] }, { "productId": "segment", "storyId": "identity-stitching", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Segment documents an Identity Resolution / ID Graph that merges cookie IDs, device IDs, emails, and custom external IDs across web, mobile, server, and third-party touch-points into a single profile in real time, with Engage/Audiences and Profile API built on top for querying resolved profiles. Configurability of ID resolution rules is implied via external_ids/traits/spec but not deeply detailed with concrete rule-configuration examples. Missing for 10: hands-on/independent validation of identity stitching accuracy, and more granular documentation on customizing merge/precedence rules.", "evidenceIds": [ "segment-docs-8", "segment-docs-24", "segment-docs-43", "segment-docs-16", "segment-docs-39", "segment-docs-10", "segment-docs-19", "segment-docs-22" ] }, { "productId": "segment", "storyId": "inline-event-transformations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment Functions let engineers write custom JavaScript to transform, filter, and enrich events (both source and destination functions) directly in the pipeline before delivery, and Reverse ETL allows custom query-based transforms from warehouses. However, evidence doesn't detail advanced transformation capabilities like conditional filtering logic, chained transforms, or destination-level insert functions in depth, nor independent/hands-on validation of Functions in production use. Missing for 10: detailed docs/examples of filtering and enrichment logic within Functions, independent hands-on confirmation of Functions reliability, and coverage of destination insert-function transform chaining.", "evidenceIds": [ "segment-docs-5", "segment-docs-30", "segment-docs-7" ] }, { "productId": "segment", "storyId": "nl-audience-builder", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Segment's pricing page markets 'Build AI-powered audiences from a complete customer view' (segment-docs-37), suggesting some AI-assisted audience building exists, and Audiences are built from tracked events/traits/computed traits within the actual schema (segment-docs-9, segment-docs-38). However, there is no documentation describing a natural-language interface, an AI-generated segment definition for human review, or how schema grounding works in that flow. Missing for 10: docs/screenshots of the NL prompt-to-segment workflow, evidence of a review/edit step before activation, and confirmation the AI reads the live schema rather than generic templates.", "evidenceIds": [ "segment-docs-37", "segment-docs-9", "segment-docs-38", "segment-docs-32" ] }, { "productId": "segment", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment's Public API supports full CRUD over workspace resources (Sources, Destinations, Warehouses, Tracking Plans) and there's a live, auth-gated Profile API and tracking ingest API, confirmed by both docs and runtime probes. However, the UI also covers configuration areas like Audiences/Engage building, Privacy Portal/consent management, and Functions editing that aren't clearly shown to be fully API-manageable, and there's no evidence of a comprehensive 1:1 API-to-UI parity claim. Missing for 10: explicit parity documentation or evidence for Audience-building, Engage personalization, Functions creation, and Privacy Portal workflows being fully API-accessible, plus independent confirmation beyond vendor docs.", "evidenceIds": [ "segment-docs-4", "segment-docs-18", "segment-docs-29", "segment-docs-41", "segment-docs-x1", "segment-docs-x2", "segment-probe-rt-1", "segment-probe-rt-2", "segment-docs-10", "segment-docs-19" ] }, { "productId": "segment", "storyId": "openness-full-export", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment documents mechanisms that support data portability in open formats — Data Storage Destinations to warehouses/S3/GCS, a Profile API for programmatic read access, and a Public API for CRUD on workspace resources — which together let a user extract their raw and profile data. However, there is no explicit 'export everything and leave' workflow, account-closure data dump, or documented guarantee against lock-in for a full departure scenario. Missing for 10: an explicit full-account/bulk export or 'leave the platform' feature, documented data formats/standards for portability, and independent confirmation that a full export actually works end-to-end.", "evidenceIds": [ "segment-docs-13", "segment-docs-20", "segment-docs-34", "segment-docs-42", "segment-docs-10", "segment-docs-19", "segment-docs-44", "segment-docs-4", "segment-docs-18", "segment-probe-rt-1" ] }, { "productId": "segment", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Segment is a closed-source SaaS CDP; the story asks about reading the product's source under an open license, which is a category error for a proprietary hosted service (though some client SDKs may be open, the core product itself is not, and no evidence pack claims otherwise).", "evidenceIds": [] }, { "productId": "segment", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Segment is a hosted SaaS customer data platform with no evidence of an open-source/self-hostable core edition; self-hosting is not a plausible axis for this managed cloud product, distinct from products with on-prem/OSS distributions.", "evidenceIds": [] }, { "productId": "segment", "storyId": "pii-field-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Segment provides a Privacy Portal, consent management, and general privacy/compliance tooling (GDPR/CCPA/HIPAA references) plus a Tracking Plan/Spec for data governance, but the evidence does not document per-destination controls like field-level hashing, masking, or selective filtering of sensitive attributes before data reaches specific destinations. Missing for 10: explicit documentation of per-destination PII transformation rules (hashing/masking configuration), field-level filtering UI or API, and independent/hands-on confirmation that these controls work as described.", "evidenceIds": [ "segment-docs-11", "segment-docs-12", "segment-docs-17", "segment-docs-25", "segment-docs-33", "segment-docs-40" ] }, { "productId": "segment", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers privacy tools, consent management, and generic data storage destinations, but nothing addresses regional/residency choice for where Segment processes or stores data. Missing for 10: explicit documentation of EU/regional workspace options, data residency controls, or geographic storage selection.", "evidenceIds": [ "segment-docs-11", "segment-docs-25", "segment-docs-13", "segment-docs-20" ] }, { "productId": "segment", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Segment provides general privacy tooling (Privacy Portal, Consent Management, GDPR/CCPA/HIPAA compliance) and even markets 'AI-powered audiences,' making the question of AI-training data controls plausible for this product category, but no evidence describes any mechanism to specifically opt customer data out of AI/ML model training. Consent Management docs address cookie/data-collection consent broadly, not AI training use specifically.", "evidenceIds": [ "segment-docs-11", "segment-docs-12", "segment-docs-25", "segment-docs-37", "segment-docs-40" ] }, { "productId": "segment", "storyId": "privacy-retention-controls", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment provides a dedicated Privacy Portal with data subject request/deletion tooling, consent management to control collection, CRUD API access (including delete operations) across resources, and compliance framing for GDPR/CCPA/HIPAA, giving users control over retention and deletion of customer data. missing for 10: no independent/hands-on evidence of an actual deletion workflow being executed, and no detail on data retention period configuration specifics.", "evidenceIds": [ "segment-docs-11", "segment-docs-17", "segment-docs-25", "segment-docs-12", "segment-docs-33", "segment-docs-40", "segment-docs-4", "segment-docs-18", "segment-docs-29" ] }, { "productId": "segment", "storyId": "privacy-telemetry-optout", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Segment ships Consent Management and a Privacy Portal that let end users set preferences to opt out of data collection/tracking, and supports GDPR/CCPA/HIPAA compliance, which partially maps to a telemetry opt-out capability. However, this addresses opting out end-users of data tracked *through* Segment by its customers, not an AI-native developer opting out of Segment's own product usage telemetry — no evidence addresses that specific angle. Missing for 10: explicit opt-out mechanism for Segment's own usage/telemetry collection about the product itself, and any AI-agent-specific consent flow or documentation.", "evidenceIds": [ "segment-docs-12", "segment-docs-33", "segment-docs-40", "segment-docs-11", "segment-docs-25" ] }, { "productId": "segment", "storyId": "realtime-audience-activation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Segment's Engage/Audiences product is documented to build audiences from real-time tracking events and traits and sync them continuously to hundreds of ad/engagement destinations, powered by real-time identity resolution ('Powered by real-time data, Twilio Engage', 'Audiences let you group users... sync Audiences to hundreds of Destinations'). This directly matches the marketer story of continuous audience sync with dynamic membership.\n\nmissing for 10: explicit documentation/evidence of near-real-time membership entry/exit mechanics (e.g. incremental diff syncing) and independent/hands-on confirmation that ad-platform syncs actually update membership continuously rather than on a batch schedule.", "evidenceIds": [ "segment-docs-9", "segment-docs-23", "segment-docs-32", "segment-docs-38", "segment-docs-39", "segment-docs-8" ] }, { "productId": "segment", "storyId": "sdk-event-collection", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment's docs describe a documented tracking spec (track, identify, page) applied consistently across libraries and APIs, with code examples (analytics.track) and confirmation that the ingest API is live and the official SDK installs and works. This directly matches the story of collecting events via official SDKs implementing a documented spec. Missing for 10: explicit mobile/server SDK-specific documentation snippets and independent third-party corroboration beyond Segment's own docs/probes.", "evidenceIds": [ "segment-docs-2", "segment-docs-3", "segment-docs-15", "segment-docs-21", "segment-docs-27", "segment-probe-rt-2" ] }, { "productId": "segment", "storyId": "server-ingest-http", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "Segment's HTTP Tracking API (api.segment.io) is documented and confirmed live with write-key authentication (returns structured 400 on invalid key), and a server-side Node SDK exists for programmatic server-to-server sends; the Segment Spec formalizes the payload format. However, explicit documentation of delivery guarantees (retry policies, at-least-once semantics, batching/queueing behavior) is not present in the evidence pack. Missing for 10: documented delivery-guarantee/retry semantics for the ingestion API, and independent verification of server-side batching reliability.", "evidenceIds": [ "segment-docs-2", "segment-docs-35", "segment-docs-21", "segment-probe-rt-2", "segment-docs-x2" ] }, { "productId": "segment", "storyId": "third-party-source-feeds", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment's docs state it can 'capture data from any source' and offers Functions to build custom sources for bringing in new types of data, plus Reverse ETL to pull data from warehouses into destinations, supporting ingestion beyond directly-instrumented apps. However, the evidence never explicitly names a catalog of prebuilt 'Cloud App' source connectors (e.g., Salesforce, Stripe, Zendesk feeds) or shows a hands-on example of pulling third-party cloud app data, relying instead on generic marketing claims. Missing for 10: explicit cloud-app source catalog documentation, a concrete third-party feed ingestion example, and independent/hands-on corroboration of this specific capability.", "evidenceIds": [ "segment-docs-5", "segment-docs-7", "segment-docs-36", "segment-docs-6" ] }, { "productId": "segment", "storyId": "tracking-plan-enforcement", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Segment explicitly markets 'enforce quality with schemas' and exposes Tracking Plans as a manageable resource via its Public API, showing schema definition and management exist, but the evidence pack contains no detail on the actual violation-handling mechanics (e.g., blocking, flagging, or quarantining non-conforming events) that the story specifically asks about — that functionality (Protocols-style enforcement) is not documented here.\n\nmissing for 10: concrete documentation of violation detection/blocking/quarantine behavior, independent confirmation that non-conforming events are actually stopped or flagged rather than passed through.", "evidenceIds": [ "segment-docs-1", "segment-docs-36", "segment-docs-18", "segment-docs-3", "segment-docs-21" ] }, { "productId": "segment", "storyId": "unified-profile-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Segment's Profile API is explicitly documented to query the entire user/account object programmatically, including traits, external_ids (identifiers), and events (history), directly matching the story; the Public API is separately documented with CRUD, auth, and a live runtime probe confirming it's a real, auth-gated endpoint. Identity Resolution/Identity Graph docs corroborate unified profile construction feeding this API. Missing for 10: independent (non-vendor) hands-on validation specifically of the Profile API's query behavior/response shape, and no evidence of query limits or SLAs.", "evidenceIds": [ "segment-docs-10", "segment-docs-19", "segment-docs-22", "segment-docs-31", "segment-docs-44", "segment-docs-24", "segment-probe-rt-1", "segment-docs-x1" ] }, { "productId": "segment", "storyId": "visual-audience-builder", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Docs confirm Segment/Engage lets marketers build Audiences from tracking events, traits, and computed traits, syncing to destinations (segment-docs-9, 32, 38, 23), which implies a no-code audience-building experience. However, there is no explicit mention of a visual drag-and-drop builder UI or of showing estimated audience size before activation. Missing for 10: explicit evidence of the visual/no-SQL builder interface and audience size estimation feature.", "evidenceIds": [ "segment-docs-9", "segment-docs-32", "segment-docs-38", "segment-docs-23", "segment-docs-39" ] }, { "productId": "segment", "storyId": "warehouse-sync-raw", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Segment supports warehouse/lake delivery via Data Storage Destinations (Snowflake, BigQuery, S3, etc.) and Reverse ETL for syncing back from warehouses, but these are destination-style syncs configured within Segment rather than a fully self-controlled, schedule-driven pipeline the data engineer independently manages. missing for 10: explicit ClickHouse support, details on sync scheduling/frequency control, and independent/hands-on confirmation that raw event and profile data lands reliably in the warehouse on a customer-defined schedule.", "evidenceIds": [ "segment-docs-13", "segment-docs-20", "segment-docs-34", "segment-docs-42", "segment-docs-7" ] } ]