[ { "productId": "buzz", "storyId": "admin-audit-logs", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only relevant evidence is a passing mention that agents have 'their own audit trail' alongside keys and channel memberships, which hints at some logging of agent actions but says nothing about a queryable/reviewable log covering both admin and human user actions across the workspace, nor any export/compliance tooling. Missing for 10: documented audit log viewer or export, coverage of admin actions and human user actions (not just agent actions), retention/compliance controls, and any independent corroboration.", "evidenceIds": [ "buzz-gh-4" ] }, { "productId": "buzz", "storyId": "agent-channel-member", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Buzz's core design explicitly gives agents their own channel memberships, keys, and audit trail, and describes agents participating in channel conversations (searching history, posting threads, orchestrating other agents) — directly matching the story of adding an AI agent as a channel member that engages when mentioned. However, there's no explicit documentation of an '@mention triggers agent response' mechanism, and community commentary treats it simply as 'bots in chat rooms' without confirming mention-based triggering specifics. Missing for 10: explicit documentation of mention-triggered activation, independent hands-on confirmation of this exact UX flow.", "evidenceIds": [ "buzz-gh-2", "buzz-gh-3", "buzz-gh-4", "buzz-comm-7" ] }, { "productId": "buzz", "storyId": "agent-reads-posts-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz is explicitly agent-first: agents have their own keys, channel memberships, and audit trails, can search history and post threads, and there's a documented CLI and MCP server for programmatic interaction. However, no OpenAPI/API spec was found (404s on all probed endpoints), and no explicit documentation of 'scoped tokens' for API access was cited, so the 'official API with scoped tokens' framing is only partially evidenced. missing for 10: explicit scoped-token/auth-scope documentation, a discoverable official REST/HTTP API spec (openapi.json returned 404).", "evidenceIds": [ "buzz-gh-3", "buzz-gh-4", "buzz-docs-5", "buzz-probe-3", "buzz-probe-4", "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe found no llms.txt at buzz.xyz (404), and no evidence pack item references agent-oriented documentation formats or discoverability files; only an MCP server and CLI are documented, which don't satisfy this specific story. Missing for 10: an llms.txt or equivalent agent-readable docs endpoint, any mention of agent-oriented documentation standards.", "evidenceIds": [ "buzz-probe-1" ] }, { "productId": "buzz", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence shows agents can search history and 'post the threads, not vibes' and orchestrate workflows/reviews, implying some data-derived context surfacing, but there is no explicit documentation of dedicated AI-generated insights, summaries, or suggestion features surfaced to users. Missing for 10: dedicated insight/summary dashboards, proactive suggestion features, and independent confirmation that agents actually generate actionable insights rather than just retrieving raw history.", "evidenceIds": [ "buzz-gh-3", "buzz-gh-2", "buzz-gh-5" ] }, { "productId": "buzz", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz's docs show agents with their own keys/channels/audit trail, workflow-trigger CLI commands, and an MCP-driven-hooks system that lets agents act on events without direct human invocation, all pointing to autonomous background automation. However there is no first-party documentation of scheduling, persistence, or long-running unattended jobs, and no independent hands-on report confirming such automations work reliably in practice. Missing for 10: explicit scheduling/trigger-on-interval docs, independent verification of autonomous background runs, and detail on failure/retry handling.", "evidenceIds": [ "buzz-gh-2", "buzz-gh-4", "buzz-docs-8", "buzz-probe-3" ] }, { "productId": "buzz", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz's docs/GitHub describe agents as first-class participants that can open repos, send patches, review code, run workflows, and orchestrate other agents inside the product, and it ships MCP-driven hooks for agent integration (buzz-gh-2, buzz-gh-4, buzz-probe-3). However this is framed as a multi-agent chat/dev platform where external agents join with their own keys, rather than a single dedicated 'built-in assistant' persona users delegate to by default. Missing for 10: a documented default/first-party assistant persona, evidence of a simple task-delegation UX (vs. general agent orchestration infrastructure), and independent hands-on confirmation that delegation works reliably (community threads mostly debate permissions/architecture, not task delegation itself).", "evidenceIds": [ "buzz-gh-2", "buzz-gh-4", "buzz-probe-3", "buzz-gh-3" ] }, { "productId": "buzz", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Buzz ships a CLI (buzz-cli) with scriptable commands for channels, workflows, repos, etc. (buzz-docs-5/7/8), which implies it can be driven non-interactively/automated, and agents have their own keys/audit trails (buzz-gh-4) suggesting programmatic access. However, there is no explicit documentation of a headless mode, CI pipeline integration, or CI-specific examples for Buzz itself. Missing for 10: explicit headless/CI-mode documentation, CI pipeline examples, and independent confirmation of running Buzz unattended in automation.", "evidenceIds": [ "buzz-docs-5", "buzz-docs-7", "buzz-docs-8", "buzz-gh-4", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "agentic-mcp-client", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only evidence is a documented file titled MCP_DRIVEN_HOOKS.md, suggesting Buzz supports MCP-driven hook integration, but no actual content, examples, or independent confirmation of plugging in third-party MCP servers is provided. Missing for 10: detailed docs on configuring/adding MCP servers, examples of tool usage via MCP, and community or hands-on validation.", "evidenceIds": [ "buzz-probe-3" ] }, { "productId": "buzz", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz is a chat/collaboration platform (not itself an agent), so shipping an MCP server axis applies; probe evidence confirms an official MCP-related doc (MCP_DRIVEN_HOOKS.md) exists in the repo, and the product's core design explicitly gives agents their own keys, channel memberships, and audit trails for connecting to the platform. However, the evidence pack lacks detailed documentation of the MCP server's setup, tool surface, or independent confirmation it works as described, and community commentary raises real concerns about the permission/auth model's real-world robustness. Missing for 10: full MCP server documentation/spec, independent hands-on verification of connecting an agent via MCP, and resolution of the permission-model critiques.", "evidenceIds": [ "buzz-probe-3", "buzz-gh-4", "buzz-gh-2", "buzz-comm-5", "buzz-comm-6" ] }, { "productId": "buzz", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Buzz is agent-native chat where agents interact via structured commands, channels, and an MCP/CLI interface (buzz-gh-2, buzz-probe-3, buzz-docs-5/7/8), but the CLI commands shown are structured flags/subcommands rather than natural-language input, and there's no evidence of a conversational NL interface for operating the product. missing for 10: documentation or demo of actual natural-language command parsing/interpretation (vs. structured CLI/MCP calls), independent confirmation that NL commands work in practice.", "evidenceIds": [ "buzz-gh-2", "buzz-docs-5", "buzz-docs-7", "buzz-docs-8", "buzz-probe-3", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Buzz ships an official CLI (buzz-cli crate) with documented commands spanning channels, repos, workflows, and GIF search, confirming it's a first-class part of the product for agentic/scripted workflows. missing for 10: independent hands-on verification of the CLI beyond vendor docs, and no evidence of broader AI-native conveniences like an llms.txt or shell completions.", "evidenceIds": [ "buzz-docs-5", "buzz-docs-6", "buzz-docs-7", "buzz-docs-8", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz ships a documented CLI (buzz-cli commands for channels, repos, workflows, gifs) and an official MCP server for agent-driven hooks, plus agents get their own API keys/audit trails — all enabling AI-native programmatic control. However, probes show no formal public REST API docs (openapi.json/swagger 404, llms.txt 404), so there's no single canonical 'documented public API' surface, only CLI/MCP tooling. Missing for 10: a published OpenAPI/REST spec or llms.txt, and independent confirmation that agents actually use these interfaces successfully in production.", "evidenceIds": [ "buzz-docs-5", "buzz-docs-7", "buzz-docs-8", "buzz-gh-4", "buzz-probe-3", "buzz-probe-4", "buzz-probe-1", "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Buzz documents that each agent gets 'their own keys, their own channel memberships, and their own audit trail' (buzz-gh-4), implying some per-agent credential isolation, and CLI commands like `repos protect` show coarse-grained permission levels (buzz-docs-7). However there is no first-party documentation of a formal least-privilege API credential/scoping mechanism (e.g., issuing a key with defined capability sets), and community commentary raises concrete doubts about whether the permission model handles real-world scoping correctly (buzz-comm-3, buzz-comm-5, buzz-comm-6), though this is speculative critique rather than a confirmed hands-on failure. Missing for 10: explicit docs on scoped/limited-permission key issuance, examples of restricting an agent's API access to specific resources, and independent verification that the scoping works as intended.", "evidenceIds": [ "buzz-gh-4", "buzz-docs-7", "buzz-comm-3", "buzz-comm-5", "buzz-comm-6" ] }, { "productId": "buzz", "storyId": "agentic-sdks", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Buzz ships a documented CLI (buzz-cli) and an MCP-driven hooks system that agents can call, and evidence notes agents have their own API keys — giving AI-native users some official programmatic surface. However, there is no evidence of a dedicated SDK library (Python/JS/etc.), and probes for an OpenAPI/swagger spec and llms.txt all returned 404, suggesting no formal SDK or API spec is published. Missing for 10: an actual SDK package/library, published API reference (OpenAPI/swagger), and independent confirmation of SDK usage by developers.", "evidenceIds": [ "buzz-probe-4", "buzz-probe-3", "buzz-gh-4", "buzz-probe-1", "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of a webhook subscription mechanism; Buzz's architecture is built around Nostr-based signed events, CLI commands, and an MCP-driven hooks system, but nothing in the evidence pack mentions webhooks specifically for external event subscription. Missing for 10: any documentation of a webhook API, subscription endpoint, or event push mechanism.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "ai-channel-summaries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Buzz evidence focuses on agents searching history and pulling up relevant threads (buzz-gh-3, buzz-gh-5) but there's no documentation of an AI-generated summary/recap feature for channels or threads a user missed; the CLI and docs list channel creation, repo management, and workflow triggers with no summarization command or feature mentioned.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "ai-meeting-recaps", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Buzz's evidence covers voice huddles, channels, agent search of history, and repo/workflow features, but there is no mention of AI-generated meeting notes, recaps, or summaries for huddles attended or missed. Missing for 10: any documentation of automatic meeting/huddle transcription or summary generation, evidence of a recap feature for missed huddles.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There is no evidence of an interactive API reference or runnable examples; the probe explicitly found no OpenAPI/Swagger spec and no llms.txt at Buzz's domain. Only a CLI and MCP hooks documentation exist, which do not constitute an interactive API reference with runnable examples. Missing for 10: any API reference site, OpenAPI/Swagger spec, or interactive/runnable example sandbox.", "evidenceIds": [ "buzz-probe-1", "buzz-probe-2", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct probes for OpenAPI/swagger specs and llms.txt all returned 404, and no evidence pack item mentions a downloadable API spec; only a CLI and MCP hooks are documented.", "evidenceIds": [ "buzz-probe-1", "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack describes a sandbox/staging environment or test mode distinct from production data; Buzz's evidence focuses on chat rooms, channels, code review, and agent orchestration, not on data isolation for testing.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of API versioning or a documented deprecation policy; openapi probes returned 404 and no changelog/versioning docs are cited. Missing for 10: versioned API docs, deprecation policy documentation, changelog or stability guarantees.", "evidenceIds": [ "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "app-marketplace", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an app directory or marketplace for prebuilt integrations that a team-admin could browse and install; Buzz's evidence covers CLI commands, agent orchestration, MCP hooks, and chat/dev workflows but nothing about an installable integrations marketplace. Missing for 10: any mention of an app directory, marketplace listing, or one-click integration install flow.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "audio-video-calls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence mentions 'drop into voice huddles' as a feature (buzz-gh-2), suggesting audio/video calling exists within the app, but there is no documentation on how to initiate a call from a channel/DM, no UI walkthrough, and no independent confirmation it works as described. Missing for 10: dedicated call-initiation documentation, admin-specific controls, video call evidence beyond a single passing mention, and hands-on/community confirmation of the feature working.", "evidenceIds": [ "buzz-gh-2" ] }, { "productId": "buzz", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows CLI/agent commands operating on single items (one channel, one repo, one workflow) but no documented bulk/batch operations across many items at once; no evidence of scripting loops, batch APIs, or multi-item commands.", "evidenceIds": [ "buzz-docs-5", "buzz-docs-7", "buzz-docs-8" ] }, { "productId": "buzz", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Buzz documents workflow triggers (buzz-docs-8) and a dedicated 'MCP-driven hooks' doc (buzz-probe-3) implying event-based automation tied to agent actions, but there is no detailed spec of rule syntax, supported event types, or conditions, and no independent confirmation of reliability. missing for 10: full rule-definition schema/docs, breadth of triggerable events, hands-on/independent verification that hooks fire reliably.", "evidenceIds": [ "buzz-docs-8", "buzz-probe-3", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of any scheduling/cron/recurring-trigger capability in Buzz — workflows can be triggered manually or via CLI/MCP hooks, but nothing documents recurring or time-based scheduling. Missing for 10: any docs/CLI command for cron-style or recurring job scheduling, evidence of scheduled workflow runs.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Buzz's core model treats automations as git-style patches with review and merge decisions baked into the channel (buzz-gh-1, buzz-gh-5), and the CLI exposes workflow trigger/approve commands (buzz-docs-8) plus repo protection rules (buzz-docs-7), giving some versioning and review capability for automation-like workflows. However, there is no explicit evidence of a 'rollback' mechanism for workflows/automations specifically, nor of automation-specific version history beyond generic git patch review. Missing for 10: explicit rollback/undo functionality for workflows, and dedicated versioning UI/CLI for automations distinct from general code patches.", "evidenceIds": [ "buzz-gh-1", "buzz-gh-5", "buzz-docs-7", "buzz-docs-8" ] }, { "productId": "buzz", "storyId": "custom-slash-commands", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of a slash-command registration API or SDK for developers to add custom commands invoked from the message box; evidence only covers CLI usage, channels, workflows, and MCP hooks. missing for 10: slash command registration API/SDK, documentation of command syntax, examples of third-party commands appearing in the message box.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "external-guest-access", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence covers channel creation, visibility settings, and agent-specific permissions, but nothing describes guest accounts for external partners or a limited-access sharing model for outside collaborators. Missing for 10: guest account mechanism, external-partner access controls, documentation of restricted/limited-access collaboration for non-org members.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "free-tier-full-history", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Buzz is an open-source, self-hosted team chat/dev platform with no evidence of a tiered pricing model, free/paid plans, or message-history retention limits tied to subscription tier — this pricing-limits axis is a category error for a self-hosted OSS project rather than a SaaS product with plan tiers.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "full-history-search", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Buzz claims agents can 'search six months of history' and 'search the conversation, patch, workflow run, and approval in one place,' implying a search capability across history, but no evidence describes structured filters like sender, channel, or date, nor a team-admin-specific search UI or command. missing for 10: documented filter parameters (sender/channel/date), admin-facing search tool or CLI command, independent confirmation of filter functionality.", "evidenceIds": [ "buzz-gh-3", "buzz-gh-5" ] }, { "productId": "buzz", "storyId": "granular-notifications", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of notification tuning by channel, keyword, or schedule anywhere in the docs, CLI reference, or README; the CLI examples cover channels, repos, workflows, and GIFs but nothing about notification preferences or muting/alerting rules. Missing for 10: any mention of notification settings, keyword alerts, schedule/quiet-hours controls, or per-channel notification toggles.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "incoming-webhook-post", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a simple incoming webhook URL feature for posting messages; Buzz's integration surface described is CLI commands, agent keys/channel membership, and MCP hooks, not a plug-and-play webhook URL. Missing for 10: any documentation of a webhook endpoint, webhook URL generation, or simple HTTP POST-to-channel mechanism.", "evidenceIds": [ "buzz-docs-5", "buzz-gh-4", "buzz-probe-3", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "interactive-app-ui", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Buzz as a chat/collaboration platform with channels, canvases, CLI, and agent integration, but there is no mention of a developer-facing SDK or API for building interactive UI elements like modals, buttons, or structured message layouts inside chat — this is a distinct app-platform capability (like Slack's Block Kit) that is not documented anywhere in the pack. Missing for 10: any API/SDK for interactive components, modal/button primitives, message-layout builder documentation.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "no-code-workflow-builder", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Buzz has developer-oriented 'workflows' tied to CI/CD and code review (e.g., 'buzz workflows trigger/approve' CLI commands, 'run workflows' in agent capabilities) but nothing describing a no-code workflow builder for team-admins with triggers from events, schedules, or form submissions. This is a CLI/agent-driven automation surface, not a no-code admin tool.", "evidenceIds": [ "buzz-gh-2", "buzz-docs-8" ] }, { "productId": "buzz", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz's CLI (buzz-cli) and agent capabilities (buzz-gh-2, buzz-docs-5/7/8) show many UI actions—creating channels, protecting repos, triggering/approving workflows—are exposed programmatically, and agents are described as having full access to open repos, review code, run workflows, and join channels (buzz-gh-2, buzz-gh-4). However, there's no documented OpenAPI/REST spec (buzz-probe-2 shows 404s) confirming full API parity, and some UI-only features like video comments or huddles are not shown as CLI/API accessible. missing for 10: a public API/OpenAPI reference proving complete UI-API parity, evidence that video/canvas/huddle features are scriptable via API.", "evidenceIds": [ "buzz-gh-2", "buzz-gh-4", "buzz-docs-5", "buzz-docs-7", "buzz-docs-8", "buzz-probe-2", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "openness-full-export", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Buzz's open-source, self-hostable design and Nostr-based signed-event architecture imply data ownership and portability ('the project lives in one place, and that place is yours'; run your own relay), but no CLI command or documented feature explicitly exports data in an open format for a user to leave with. Missing for 10: an explicit export/backup command, documentation of the open data format schema, and independent confirmation that self-hosted data can be fully extracted and reused elsewhere.", "evidenceIds": [ "buzz-docs-1", "buzz-docs-2", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Buzz's source is hosted publicly on GitHub (block/buzz) with docs, CLI code, and README all visible, and community discussion confirms it's treated as an open-source project ('decentralized, self-sovereign, and open source'). However, the evidence pack never explicitly states or cites a specific OSI license file/name. Missing for 10: explicit citation of the license type (e.g., Apache/MIT) confirming open-license terms, independent verification of license terms.", "evidenceIds": [ "buzz-gh-1", "buzz-gh-2", "buzz-docs-1", "buzz-comm-17", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Buzz is explicitly open source and self-hostable: docs state 'Run your own relay for one community... same OSS codebase' and 'The project lives in one place, and that place is yours,' with a public GitHub repo and CLI for setup. Missing for 10: no independent/hands-on report confirming a successful self-hosted deployment, and community comments raise skepticism about maturity/reliability rather than confirming self-hosting works in practice.", "evidenceIds": [ "buzz-docs-1", "buzz-docs-2", "buzz-gh-1", "buzz-probe-4" ] }, { "productId": "buzz", "storyId": "organize-channels", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Buzz supports creating channels/rooms with a visibility flag ('make it private', CLI --visibility open) and per-agent/user channel memberships, indicating basic public/private organization with membership. However, evidence for granular admin membership controls (e.g., invite management, role-based permissions, moderation) is thin, and community critique raises concrete doubts about the robustness of its custom permission model in real-world edge cases (e.g., auto-invite conflicts). missing for 10: detailed admin UI/CLI for managing membership/invites, documented role-based access control, independent verification that private channels reliably restrict access.", "evidenceIds": [ "buzz-docs-4", "buzz-docs-5", "buzz-gh-4", "buzz-comm-5", "buzz-comm-6" ] }, { "productId": "buzz", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack mentions self-hosting relay options (buzz-docs-2) but nowhere addresses data residency, regional storage choice, or compliance-driven data location controls. Buyers cannot determine whether or where data can be pinned to a specific region.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data usage or opt-out controls for Buzz; nothing discusses data being used to train models or a way to prevent it.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack describes any data retention policy, deletion controls, export, or purge mechanisms in Buzz; self-hosting (buzz-docs-2) implies ownership of infrastructure but says nothing about controlling retention/deletion of data itself.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions telemetry, usage tracking, or an opt-out mechanism; while Buzz is self-hostable, that alone doesn't confirm a telemetry opt-out exists. missing for 10: any documentation of telemetry collection or an opt-out setting/flag.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "realtime-bot-events", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Buzz's architecture gives agents their own keys, channel memberships, and audit trails, and documents MCP-driven hooks for agent integration, implying some event-driven mechanism for bots to react to chat activity. However, there is no explicit documentation of a formal events API, WebSocket/gateway protocol, or real-time subscription model comparable to Slack's Events API, and probes for openapi/llms.txt returned 404s. Missing for 10: explicit gateway/WebSocket protocol docs, formal events API reference, and independent confirmation that bots receive events in real time.", "evidenceIds": [ "buzz-gh-4", "buzz-gh-2", "buzz-probe-3", "buzz-probe-1", "buzz-probe-2" ] }, { "productId": "buzz", "storyId": "retention-legal-hold", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of retention policy configuration, legal hold mechanisms, or eDiscovery/compliance export tooling in Buzz's docs or CLI; the product focuses on chat/agent collaboration and repo protection, not compliance retention. missing for 10: retention policy controls, legal hold feature, eDiscovery export capability, compliance documentation.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "screen-sharing", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Buzz documents voice huddles (buzz-gh-2) and video-with-comments features (buzz-docs-3), but no evidence anywhere describes screen sharing during a call. Missing for 10: any mention of screen-share functionality, UI, or CLI command for sharing a screen in a huddle.", "evidenceIds": [ "buzz-gh-2", "buzz-docs-3" ] }, { "productId": "buzz", "storyId": "threaded-replies", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes channels, search across conversations, and agent chat rooms, but no documentation or feature mentions threaded replies to keep side discussions attached to an original message. missing for 10: any mention of a reply/thread UI or API, docs on thread creation, or community confirmation of threading behavior.", "evidenceIds": [] }, { "productId": "buzz", "storyId": "topic-based-catchup", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Buzz documents named rooms/channels created per feature or topic (buzz-docs-4, buzz-docs-5) and shows agents searching and posting 'threads, not vibes' with unified search across conversation, patch, workflow and approval (buzz-gh-3, buzz-gh-5), supporting organized, catch-up-friendly channels. However there's no explicit catch-up/unread-summary tooling or independent hands-on evidence that this actually makes busy-channel triage efficient for a human admin. missing for 10: explicit catch-up/digest feature, independent/hands-on validation of thread organization reducing admin overhead.", "evidenceIds": [ "buzz-docs-4", "buzz-docs-5", "buzz-gh-3", "buzz-gh-5" ] }, { "productId": "buzz", "storyId": "workspace-history-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any export/compliance feature for full workspace message history in machine-readable formats; evidence covers CLI for channels, workflows, repos, but nothing about admin data export or e-discovery. missing for 10: export/download tooling, machine-readable format documentation, admin controls over private conversation export, compliance/legal-hold features.", "evidenceIds": [] }, { "productId": "discord", "storyId": "admin-audit-logs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any audit-log feature for admin/user actions across a Discord server or workspace; the evidence pack covers developer APIs, bots, Nitro, Social SDK, and community sentiment, but nothing about compliance/audit logging capabilities for platform engineers.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agent-channel-member", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Discord's developer docs show a full bot platform — bot tokens, Gateway API for real-time message/event delivery, and application commands — that supports building an AI agent as a bot member of a server/channel, which is the standard mechanism for mention-triggered response bots. However, the evidence never explicitly documents mention-detection or an AI-agent-specific integration pattern, and there's no first-party or hands-on example of an AI agent responding when @mentioned in a channel. Missing for 10: explicit docs/example on mention-based triggering, hands-on/independent evidence of an AI agent bot working this way in production.", "evidenceIds": [ "discord-docs-10", "discord-docs-20", "discord-docs-4", "discord-docs-19", "discord-docs-7", "discord-docs-41" ] }, { "productId": "discord", "storyId": "agent-reads-posts-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Discord's official REST/Gateway API supports bot tokens and OAuth2 bearer tokens scoped to specific permissions, allowing an agent (bot) to read and post channel messages via documented endpoints and real-time Gateway events. missing for 10: no independent hands-on confirmation of an AI agent specifically using scoped tokens for message read/post, and no explicit documentation of granular message-read/post scopes beyond general bot/OAuth2 token mechanics.", "evidenceIds": [ "discord-docs-4", "discord-docs-17", "discord-docs-35", "discord-docs-10", "discord-docs-20", "discord-docs-18", "discord-docs-6" ] }, { "productId": "discord", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Direct probe evidence confirms Discord's developer docs serve a working llms.txt (HTTP 200) with an index of documentation pages, and individual doc pages are also available in .md format explicitly for agent consumption, pointing back to the llms.txt index. Missing for 10: no independent third-party confirmation of agent usage/adoption beyond the probe itself.", "evidenceIds": [ "discord-probe-1", "discord-probe-2" ] }, { "productId": "discord", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence Discord itself generates AI insights or suggestions from a user's data; evidence only covers bots/APIs, webhooks, threads, Nitro perks, and the Social SDK, none of which describe native AI-generated insights inside the product.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Discord's developer platform provides Gateway (persistent WebSocket) and webhook APIs that let bots run continuously in the background reacting to events, and third parties can build bots that act autonomously (e.g., CI/CD notifications). However, this requires custom bot development rather than a built-in no-code 'automation' feature for end users, and there's no evidence of a first-party AI-native automation/workflow builder. Missing for 10: native no-code automation/workflow feature for non-developer users, AI-specific automation tooling, and independent evidence of autonomous background agents working reliably in practice.", "evidenceIds": [ "discord-docs-10", "discord-docs-20", "discord-docs-5", "discord-docs-43", "discord-docs-56", "discord-docs-4" ] }, { "productId": "discord", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Discord's evidence covers building bots/apps via developer APIs, but there is no evidence of a built-in first-party AI assistant that users can delegate tasks to within the product itself.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Discord's REST API, bot tokens, and webhooks are explicitly documented as usable without a GUI, including a direct example of 'CI/CD pipelines posting build results or deployment notifications' via webhooks, and bots can run headlessly against the Gateway/REST API using only a token. However there's no first-party CLI, headless test harness, or SDK-level guidance for running the whole platform in automated pipelines beyond webhooks/bots. Missing for 10: an official CLI or headless client mode, dedicated CI documentation/examples beyond webhooks, and independent confirmation of headless bot reliability in CI.", "evidenceIds": [ "discord-docs-43", "discord-docs-56", "discord-docs-5", "discord-docs-4", "discord-docs-35" ] }, { "productId": "discord", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a chat/social/gaming communication platform with bots, webhooks, and OAuth2 APIs for third-party integrations, not an AI agent or assistant product that would host/consume MCP servers as tools. The story's axis (plugging MCP servers into a product so it can use their tools) applies to AI-native agent/assistant products, not to a messaging platform's developer API surface.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a chat/community platform, not an AI agent product, so connecting agents via an official MCP server is a category error for this evidence pack — no evidence of an MCP server exists, and the axis doesn't fit Discord's role as a communications platform rather than an agent tooling provider.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Discord's documented command system is built around structured slash commands, buttons, and modals (discord-docs-7/8/9/19/28/48), not natural-language interpretation of user requests; no evidence shows Discord itself parses free-form natural language to drive actions. The axis is plausible for a chat platform but nothing in the evidence demonstrates it.", "evidenceIds": [ "discord-docs-7", "discord-docs-8", "discord-docs-9", "discord-docs-19", "discord-docs-28", "discord-docs-48" ] }, { "productId": "discord", "storyId": "agentic-official-cli", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a chat/community platform, not a CLI-oriented dev tool; the evidence covers APIs, bots, webhooks, and SDKs but no official CLI, and a CLI is not a fair expectation for this product category.", "evidenceIds": [] }, { "productId": "discord", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Discord provides a well-documented REST API, Gateway WebSocket API, OAuth2, bot tokens, webhooks, and slash commands — all extensively documented for programmatic/AI-driven access (discord-docs-35, -10, -4, -5, -7). This gives an AI-native user a clear documented public API surface to drive the product. Missing for 10: no discoverable OpenAPI/Swagger spec (probe confirms 404s at standard paths), and no independent third-party verification of API completeness beyond first-party docs.", "evidenceIds": [ "discord-docs-35", "discord-docs-10", "discord-docs-4", "discord-docs-5", "discord-docs-7", "discord-docs-20", "discord-probe-3" ] }, { "productId": "discord", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Discord's API supports OAuth2 bearer tokens with defined scopes and bot tokens with granular permission bits (docs-4, docs-6, docs-17, docs-18, docs-27), which technically allow issuing narrower-than-full-access credentials for any integration, including an agent. However, there is no documentation framing this specifically for AI agents or describing least-privilege credential issuance workflows tailored to autonomous/agentic use. missing for 10: agent-specific scoped-credential guidance, examples of least-privilege bot/OAuth setups for AI agents, independent confirmation of scope granularity in practice.", "evidenceIds": [ "discord-docs-4", "discord-docs-6", "discord-docs-17", "discord-docs-18", "discord-docs-27" ] }, { "productId": "discord", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Discord provides extensive first-party documentation for building against official SDKs and APIs — the REST API, Gateway (WebSocket) API, OAuth2, Embedded App SDK, and a full Discord Social SDK with platform-specific guides for Unity, Unreal Engine, C++, iOS/Android, and web/mobile account linking. This gives builders (including AI-native developers) clear, well-documented interfaces to build bots, apps, and integrations. Missing for 10: independent/hands-on developer corroboration of SDK integration experience and AI-agent-specific SDK examples or tooling.", "evidenceIds": [ "discord-docs-4", "discord-docs-10", "discord-docs-13", "discord-docs-35", "discord-docs-44", "discord-docs-47", "discord-docs-70", "discord-docs-72", "discord-docs-58" ] }, { "productId": "discord", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Discord's webhook docs explicitly state apps can 'receive event notifications from Discord delivered to your app over HTTP,' confirming webhook-based event subscription exists alongside the Gateway websocket API for events. However, the evidence pack gives only a single line on this capability with no detail on which events are supported, setup/config steps, or independent developer confirmation. Missing for 10: full list of subscribable event types, setup/configuration docs, and third-party/community validation of webhook event delivery in practice.", "evidenceIds": [ "discord-docs-56", "discord-docs-5", "discord-docs-42", "discord-docs-10" ] }, { "productId": "discord", "storyId": "ai-channel-summaries", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any native Discord feature that generates AI summaries or recaps of missed channels/threads; docs cover bots, OAuth2, webhooks, threads, Social SDK, and Nitro perks but nothing about AI-generated recap/summary functionality. A third-party bot could theoretically add this, but no such capability is evidenced for Discord itself.", "evidenceIds": [ "discord-docs-37", "discord-docs-38", "discord-docs-54" ] }, { "productId": "discord", "storyId": "ai-meeting-recaps", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any AI-generated meeting notes, transcription, or recap feature for Discord voice/huddle calls; the evidence pack covers bots, APIs, webhooks, Social SDK, and Nitro perks but nothing about AI summarization of calls. Missing for 10: any documentation or feature reference to AI-generated call transcripts, summaries, or recap generation.", "evidenceIds": [] }, { "productId": "discord", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Discord's developer docs describe REST/Gateway/OAuth2 concepts and provide markdown-based reference pages, but the probe explicitly found no OpenAPI/Swagger spec (all candidate paths 404'd) and no evidence of an interactive, runnable-example API console or sandbox exists in the pack.", "evidenceIds": [ "discord-docs-35", "discord-docs-36", "discord-probe-3" ] }, { "productId": "discord", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Discord provides REST API documentation and an llms.txt for docs indexing, but a direct probe for OpenAPI/swagger specs at all standard paths (openapi.json, swagger.json, api/openapi.json, .well-known/openapi.json) returned 404s, indicating no downloadable machine-readable API spec is published.", "evidenceIds": [ "discord-probe-3", "discord-docs-35" ] }, { "productId": "discord", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a communication/social platform, not a service offering a sandbox/staging environment for testing against production-equivalent data; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "discord", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Discord's API surfaces (REST, Gateway, OAuth2, webhooks, Social SDK) but contains no documentation or mention of API versioning scheme, version deprecation timelines, or a changelog/deprecation policy for developers to rely on. Missing for 10: explicit API version documentation (e.g., v9/v10), a published deprecation policy, and changelog/migration guides.", "evidenceIds": [ "discord-docs-35", "discord-docs-4", "discord-docs-10" ] }, { "productId": "discord", "storyId": "app-marketplace", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Discord's docs confirm an App Directory — a searchable hub where users can browse apps/bots by name, category, or collection and add them to servers — which functions as a marketplace for prebuilt integrations (bots/apps). However, the evidence is entirely first-party docs about developer discovery/listing mechanics, with no detail on the admin-side installation/permission flow or independent confirmation of the experience. Missing for 10: independent/hands-on evidence of the admin installation UX, documentation of admin permission controls for installing apps, and confirmation beyond discovery-focused developer docs.", "evidenceIds": [ "discord-docs-11", "discord-docs-21", "discord-docs-29", "discord-docs-49", "discord-docs-12" ] }, { "productId": "discord", "storyId": "audio-video-calls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains only developer/API documentation (bots, webhooks, OAuth2, Social SDK for games) and community commentary on unrelated topics like verification and moderation; none of it documents the core client feature of a user/admin starting a voice or video call directly from a text channel or DM inside the Discord app itself. Mentions of 'voice chat' (discord-docs-3, discord-docs-41) refer to the Social SDK for third-party games, not native in-app calling.", "evidenceIds": [ "discord-docs-3", "discord-docs-41" ] }, { "productId": "discord", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers Discord's bot/API docs, OAuth2, webhooks, slash commands, and Social SDK, but nothing describes bulk endpoints or batch operations (e.g., bulk message delete, mass channel/role management) that an AI-native user could invoke to act on many items at once.", "evidenceIds": [] }, { "productId": "discord", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Discord's Gateway API lets developer-built bots subscribe to server events and act on them, and webhooks let external systems post to Discord on events (e.g. CI/CD triggers), giving a technical path to event-driven automation. However, there is no evidence of a native, no-code 'if this then that' rule-builder for end users — all automation requires writing and hosting a bot/webhook integration. Missing for 10: a first-party no-code automation/rules UI, evidence of AI-native rule triggers, and independent confirmation that non-developer users can set this up.", "evidenceIds": [ "discord-docs-10", "discord-docs-20", "discord-docs-43", "discord-docs-56", "discord-docs-5" ] }, { "productId": "discord", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a communication/social platform, not a workflow/automation scheduling product; scheduling recurring jobs is outside its core product category, though third-party bots could theoretically add this, no evidence exists of Discord itself offering job scheduling.", "evidenceIds": [] }, { "productId": "discord", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a chat/community platform, not an automation-building tool with version control, review, or rollback features for workflows; this axis targets automation platforms (e.g., Zapier, GitHub Actions) rather than a communications product like Discord.", "evidenceIds": [] }, { "productId": "discord", "storyId": "custom-slash-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Discord's docs clearly document slash commands ('application commands') as a native way for users to invoke apps by typing `/` in the chat box, with dedicated interactions/overview documentation covering registration and behavior. Missing for 10: independent hands-on developer corroboration and details on the actual registration API/code sample within this evidence pack.", "evidenceIds": [ "discord-docs-7", "discord-docs-19", "discord-docs-28", "discord-docs-48" ] }, { "productId": "discord", "storyId": "external-guest-access", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Discord's developer platform, threads, and Nitro features but contains no mention of guest accounts, cross-org shared channels, or admin-controlled limited-access partner collaboration akin to Slack Connect. Threads (discord-docs-37, discord-docs-38) are an internal channel-branching feature, not external partner access control.", "evidenceIds": [] }, { "productId": "discord", "storyId": "free-tier-full-history", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses message history retention, archiving limits, or free-tier data access policies for Discord servers; the docs cover developer APIs, Nitro perks, and unrelated community topics.", "evidenceIds": [] }, { "productId": "discord", "storyId": "full-history-search", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation or first-party reference to Discord's message search feature or its filters (sender, channel, date); all docs items focus on the developer API, bots, Nitro, and Social SDK. Community evidence even suggests messages are 'chaotic' and poorly indexed, but that speaks to external search engines, not an admin search UI, so it doesn't confirm the capability either.", "evidenceIds": [ "discord-comm-9" ] }, { "productId": "discord", "storyId": "granular-notifications", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers developer APIs, Nitro perks, Social SDK, threads, and community complaints, but contains no mention of Discord's actual notification settings features (per-channel mute/notification level, keyword/mention alerts, or scheduled quiet hours/Do Not Disturb) that a team-admin would use to tune interruptions.", "evidenceIds": [] }, { "productId": "discord", "storyId": "incoming-webhook-post", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Discord's docs explicitly describe incoming webhooks as a low-effort way to post messages to channels without requiring a bot user or authentication, and give concrete use cases like CI/CD pipelines posting notifications via HTTP. This directly matches the story of simple webhook-based posting. Missing for 10: independent hands-on developer confirmation of the webhook flow working in practice.", "evidenceIds": [ "discord-docs-5", "discord-docs-42", "discord-docs-43", "discord-docs-56" ] }, { "productId": "discord", "storyId": "interactive-app-ui", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Discord's developer docs explicitly document buttons, modals, slash/application commands, and message components as first-party interaction features for building rich in-chat UI (discord-docs-7,8,9,19,48). This directly matches the story's core ask. Missing for 10: no independent/hands-on developer corroboration of building a full interactive app, and no detail on select menus or full structured layout components beyond buttons/modals.", "evidenceIds": [ "discord-docs-7", "discord-docs-8", "discord-docs-9", "discord-docs-19", "discord-docs-48", "discord-docs-28" ] }, { "productId": "discord", "storyId": "no-code-workflow-builder", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Discord's evidence pack shows only developer-oriented building blocks—webhooks, bot tokens, Gateway API events, slash commands—which require writing and hosting code, not a no-code workflow builder for triggers/schedules/forms. There is no mention of any built-in no-code automation canvas, scheduled triggers, or form-submission triggers akin to Slack Workflow Builder or Zapier.", "evidenceIds": [ "discord-docs-5", "discord-docs-10", "discord-docs-43", "discord-docs-56", "discord-docs-9" ] }, { "productId": "discord", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Discord's developer platform exposes a broad REST/Gateway API, OAuth2, webhooks, slash commands, interactions, and a Social SDK covering messaging, presence, and account linking, showing substantial API coverage of bot/integration functionality. However, this coverage is aimed at building bots/apps rather than giving an end-user full parity with everything doable in the Discord client (e.g., no evidence of API-equivalent actions for Nitro subscription features, personal account social actions, or general UI-only settings), and the probe confirms no discoverable OpenAPI spec, suggesting the API surface isn't exhaustively documented for 1:1 parity. missing for 10: evidence of full end-user (non-bot) API parity for all client actions, an official OpenAPI/spec confirming complete surface coverage, and independent confirmation that no UI action lacks an API equivalent.", "evidenceIds": [ "discord-docs-1", "discord-docs-4", "discord-docs-5", "discord-docs-7", "discord-docs-10", "discord-docs-35", "discord-docs-56", "discord-probe-3" ] }, { "productId": "discord", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of a user-facing data export/portability feature or open-format data takeout for personal Discord data; the evidence pack covers developer APIs, bots, Nitro, and community complaints (e.g., loss of contact info on server bans, walled-garden criticism) rather than any account data-export capability. Missing for 10: documented data export/takeout tool, open-format (e.g., JSON) download of messages/DMs/servers, and any account deletion+portability workflow.", "evidenceIds": [ "discord-comm-4", "discord-comm-11", "discord-docs-35" ] }, { "productId": "discord", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a closed-source, proprietary SaaS platform; source-code openness is not a plausible axis for this kind of product, and no evidence suggests any open-licensed source availability.", "evidenceIds": [] }, { "productId": "discord", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Discord is a hosted proprietary SaaS chat platform with no self-hosted/open-source core offering; self-hosting is not a plausible axis for this product category, so this is a category error rather than a missing capability.", "evidenceIds": [] }, { "productId": "discord", "storyId": "organize-channels", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence confirms Discord supports organizing conversations into public and private sub-conversations (Threads, including 'Private Threads... rolling out to all servers') via discord-docs-37/38, which aligns with channel-like organization, but the pack contains no documentation of full channel-level permission/role systems, member/channel visibility controls, or admin management of channel membership that would fully substantiate the 'membership controls' part of the story. Missing for 10: explicit docs on channel permission overwrites/roles, admin UI for private channel membership, and any independent confirmation of these controls working as described.", "evidenceIds": [ "discord-docs-37", "discord-docs-38" ] }, { "productId": "discord", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack of Discord offering data residency/region selection controls for where user data is stored; documentation covers bots, APIs, SDKs, and Nitro features but nothing about data locality controls.", "evidenceIds": [] }, { "productId": "discord", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any AI-training data opt-out control, privacy setting, or policy statement addressing use of user data for AI/ML model training; evidence pack covers developer platform, bots, Nitro features, and unrelated community complaints (verification, moderation, breaches).", "evidenceIds": [] }, { "productId": "discord", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of data retention settings, data export, or account/message deletion controls for Discord users; it only shows unrelated developer API docs and community complaints about ID verification and a data breach, none of which describe actual retention/deletion controls.", "evidenceIds": [] }, { "productId": "discord", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any telemetry opt-out or privacy/data-tracking settings; the evidence pack covers developer APIs, Nitro features, and community complaints about verification/breaches, none of which address telemetry opt-out controls.", "evidenceIds": [] }, { "productId": "discord", "storyId": "realtime-bot-events", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Discord's documented Gateway API explicitly provides secure WebSocket connections for apps to receive real-time events (channel updates, role creation, etc.), and bot token authentication plus REST API access complete the developer bot-building path. Webhooks are also documented as an alternative for receiving/posting event notifications over HTTP. Missing for 10: independent hands-on developer confirmation of gateway reliability/rate limits and no direct community corroboration of real-time event handling in production.", "evidenceIds": [ "discord-docs-10", "discord-docs-20", "discord-docs-4", "discord-docs-35", "discord-docs-56" ] }, { "productId": "discord", "storyId": "retention-legal-hold", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack references message retention policies, legal holds, eDiscovery workflows, or compliance export tooling for platform engineers; the docs cover developer APIs, bots, Social SDK, and Nitro features only.", "evidenceIds": [] }, { "productId": "discord", "storyId": "screen-sharing", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains extensive Discord developer/API docs and community commentary but no mention of native screen-sharing during voice/video calls, which is the core capability the story asks about. Absence of evidence for this mainstream Discord feature means it cannot be credited even though it likely exists in the product.", "evidenceIds": [] }, { "productId": "discord", "storyId": "threaded-replies", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Discord's blog docs confirm threads let users branch off a channel's main feed without removing context, including private threads for servers, which supports side-discussions staying attached to the original message. However, evidence doesn't explicitly confirm 'reply in thread' UX specifics or admin-specific thread controls. missing for 10: explicit documentation of admin thread permission controls, reply-to-message-in-thread UX detail, independent/hands-on corroboration beyond blog announcement.", "evidenceIds": [ "discord-docs-37", "discord-docs-38", "discord-docs-54" ] }, { "productId": "discord", "storyId": "topic-based-catchup", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Discord docs confirm threads let you branch conversations off a channel's main feed to organize topics (discord-docs-37, discord-docs-38, discord-docs-54), which is the core mechanism the story asks for. However, independent community reports describe channels/threads as chaotic when busy and poorly organized for catch-up, noting messages 'gate' content and become 'very chaotic when a lot of people are posting' and that Discord's UI/UX makes content hard to find intuitively (discord-comm-9, discord-comm-11). Missing for 10: evidence of thread-based read-state/summary tools for admins, and resolution of the chaos/discoverability complaints from real users.", "evidenceIds": [ "discord-docs-37", "discord-docs-38", "discord-docs-54", "discord-comm-9", "discord-comm-11" ] }, { "productId": "discord", "storyId": "workspace-history-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any compliance-export tool, eDiscovery feature, or admin capability to export full message history (including private conversations) in machine-readable formats; the pack only covers developer APIs, bots, webhooks, Nitro, and Social SDK, none of which provide bulk/team-admin export of message history.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "admin-audit-logs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack includes Teams Export APIs for exporting chat/channel messages, but nothing documents an audit log of admin and user actions across the workspace (e.g., admin center audit trail, sign-in/action logs). This is an applicable enterprise-compliance axis for a SaaS collaboration platform, but no evidence demonstrates it. Missing for 10: any documentation of an audit log feature, admin action tracking, or audit log search/export API distinct from content export.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14" ] }, { "productId": "ms-teams", "storyId": "agent-channel-member", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs confirm Teams supports bots/agents that can be added to Teams and 'initiate and participate in conversations' within channels, with quickstart guidance to 'create an agent and chat with it,' plus supporting features like slash commands and message streaming that are used for triggering agent responses in conversations. Missing for 10: explicit documentation of the @mention trigger mechanism specifically and independent/hands-on confirmation that agents behave as first-class channel members when mentioned.", "evidenceIds": [ "ms-teams-docs-1", "ms-teams-docs-20", "ms-teams-docs-6", "ms-teams-docs-5", "ms-teams-docs-9" ] }, { "productId": "ms-teams", "storyId": "agent-reads-posts-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Microsoft Graph API documentation confirms an app/agent can post a chatMessage to a channel (ms-teams-docs-11/21) and Teams bots/agents can participate in conversations and automate channel/team actions (ms-teams-docs-8,9,19,20,35), and export APIs allow reading channel messages (ms-teams-docs-13). This is inherently permission-scoped via Azure AD app registrations, consistent with an 'official API with scoped tokens' model. Missing for 10: explicit documentation naming OAuth scope/permission types (e.g., ChannelMessage.Send/Read.All) for this exact read+post flow, and independent hands-on confirmation that an AI agent can freely read arbitrary channel messages (community notes Graph/Azure API setup is heavier than Slack's webhooks, ms-teams-comm-11).", "evidenceIds": [ "ms-teams-docs-11", "ms-teams-docs-21", "ms-teams-docs-8", "ms-teams-docs-9", "ms-teams-docs-19", "ms-teams-docs-20", "ms-teams-docs-13", "ms-teams-comm-11" ] }, { "productId": "ms-teams", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly show no llms.txt (404), no markdown-accessible docs endpoint, and no OpenAPI spec at Microsoft Learn — there's no agent-oriented documentation surface for an AI agent to point at. All other evidence is standard human-readable docs, not agent-consumable formats.", "evidenceIds": [ "ms-teams-probe-1", "ms-teams-probe-2", "ms-teams-probe-3" ] }, { "productId": "ms-teams", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Docs confirm Copilot Chat is embedded in Teams and Outlook, drawing on Microsoft Graph and Work IQ (work data) to generate AI insights/suggestions inside the product, with prompt starters to surface suggestions to users. Missing for 10: concrete detail on specific insight types (e.g., meeting summaries, action-item extraction) and independent/hands-on validation of insight quality beyond vendor docs.", "evidenceIds": [ "ms-teams-docs-15", "ms-teams-docs-31", "ms-teams-docs-37", "ms-teams-docs-32", "ms-teams-docs-40" ] }, { "productId": "ms-teams", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Teams' platform docs describe bots, webhooks/connectors, and Graph API automation that can post messages, create teams/channels, and react to external service events without direct real-time user interaction, which supports background-style automation. However, there is no clear documentation of persistent, autonomous AI-agent workflows (e.g., scheduled triggers, continuous background execution) beyond basic bot/connector integrations, and no independent verification of such automations running reliably unattended. Missing for 10: explicit scheduling/triggering mechanisms for autonomous agent runs, evidence of long-running background AI automation, and independent hands-on confirmation of this capability.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-10", "ms-teams-docs-12", "ms-teams-docs-19", "ms-teams-docs-30", "ms-teams-docs-36", "ms-teams-docs-44" ] }, { "productId": "ms-teams", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Teams docs confirm a built-in Copilot Chat assistant integrated directly in Teams and Outlook, capable of securely interacting with work/web data via Microsoft Graph, plus agent slash commands and prompt starters that let users delegate conversational tasks to it. Missing for 10: independent/hands-on evidence of successful task delegation (community evidence pack focuses on unrelated complaints/bugs, not Copilot capability), and more detail on the scope of tasks Copilot can autonomously execute vs. just answer.", "evidenceIds": [ "ms-teams-docs-37", "ms-teams-docs-15", "ms-teams-docs-31", "ms-teams-docs-6", "ms-teams-docs-32", "ms-teams-docs-40" ] }, { "productId": "ms-teams", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Microsoft Teams platform is automatable via the Microsoft 365 Agents Toolkit CLI (create, provision, deploy, package, and publish agents entirely from the command line) and via Microsoft Graph APIs that let external services 'run outside the Microsoft Teams user experience' to automate Teams scenarios like messaging, team/channel creation, and exports. This supports CI-style scripted automation of app/agent lifecycle and messaging, but there is no explicit documentation of running the Teams client itself headlessly or wiring these tools into a CI pipeline end-to-end. Missing for 10: explicit headless/CI runbook or GitHub Actions example, confirmation of non-interactive auth flows for CI, and independent evidence of real-world CI usage.", "evidenceIds": [ "ms-teams-docs-16", "ms-teams-docs-19", "ms-teams-docs-22", "ms-teams-docs-23", "ms-teams-docs-24", "ms-teams-docs-45", "ms-teams-probe-4" ] }, { "productId": "ms-teams", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence that Microsoft Teams (or its agent/bot platform) supports plugging in MCP servers as tool providers; docs cover bots, message extensions, connectors, webhooks, and Copilot/Graph integration but never mention MCP. Missing for 10: any documentation of MCP server connection, tool registration via MCP, or first-party MCP client support in Teams agents.", "evidenceIds": [ "ms-teams-docs-1", "ms-teams-docs-16", "ms-teams-docs-15" ] }, { "productId": "ms-teams", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers Teams' bot/agent SDK, Graph API, webhooks, and Agents Toolkit CLI, but nowhere mentions an official MCP (Model Context Protocol) server or endpoint that would let external AI agents connect to Teams. As a SaaS collaboration platform, this axis is a fair question, but no evidence shows it is delivered.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show Teams supports natural-language interaction via Copilot Chat, agent slash commands, and prompt starters (ms-teams-docs-15, ms-teams-docs-31, ms-teams-docs-37, ms-teams-docs-6, ms-teams-docs-32), giving a documented path for AI-native users to operate the product conversationally. However, this is vendor-only documentation with no independent corroboration of real-world reliability, and one community report describes a related bot (T-Bot) as 'greyed out and unusable' (ms-teams-comm-11), casting some doubt on maturity. Missing for 10: independent/hands-on validation of Copilot Chat command reliability, broader coverage beyond slash commands/prompt starters, and resolution of the T-Bot usability complaint.", "evidenceIds": [ "ms-teams-docs-15", "ms-teams-docs-31", "ms-teams-docs-37", "ms-teams-docs-6", "ms-teams-docs-32", "ms-teams-comm-11" ] }, { "productId": "ms-teams", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Microsoft ships an official Microsoft 365 Agents Toolkit CLI, documented as offering the same features as the IDE extensions—agent/app creation from templates, resource provisioning/deployment to Azure, validation/packaging/publishing, and preview—directly supporting AI-native agentic workflows for Teams apps/agents. missing for 10: independent/hands-on verification of CLI usage and no evidence of scripting/automation depth (e.g., CI/CD examples) beyond first-party docs.", "evidenceIds": [ "ms-teams-docs-16", "ms-teams-docs-22", "ms-teams-docs-23", "ms-teams-docs-24", "ms-teams-docs-38", "ms-teams-probe-4" ] }, { "productId": "ms-teams", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Microsoft Teams exposes extensive, well-documented public APIs (Microsoft Graph Teams API, Bot Framework, webhooks/connectors, Teams platform APIs) enabling programmatic control of chats, channels, teams, and messages, plus a CLI (Agents Toolkit CLI) for automating agent/app creation, provisioning, and publishing. This is corroborated by community complaints acknowledging the API exists but noting it requires the fuller Azure/Graph stack rather than simple webhooks. Missing for 10: a discoverable OpenAPI/llms.txt spec (probes returned 404s) and stronger independent hands-on validation of API robustness beyond docs and one critical community note.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-11", "ms-teams-docs-19", "ms-teams-docs-16", "ms-teams-docs-22", "ms-teams-docs-23", "ms-teams-docs-24", "ms-teams-comm-11", "ms-teams-probe-4" ] }, { "productId": "ms-teams", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Teams' Graph API and Agents Toolkit are documented for building agents/apps, none of the evidence describes issuing scoped or least-privilege API credentials specifically for an agent (e.g., granular OAuth scopes, permission consent flows tied to agent identity). The docs mention Azure resource provisioning and Graph API access broadly but not credential scoping mechanics.", "evidenceIds": [ "ms-teams-docs-15", "ms-teams-docs-23", "ms-teams-docs-19" ] }, { "productId": "ms-teams", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Microsoft documents official SDKs/toolkits (Bot Framework/Teams AI SDK equivalents implied via bots, Agents Toolkit CLI, Microsoft Graph API, Copilot extensibility) for building agents, bots, tabs, and message extensions against Teams, with a dedicated CLI and IDE tooling for creation, provisioning, and publishing. missing for 10: no independent/hands-on developer corroboration of SDK quality or ergonomics, and probes show no machine-readable API spec (openapi.json 404) or llms.txt, suggesting docs aren't fully AI-native optimized.", "evidenceIds": [ "ms-teams-docs-16", "ms-teams-docs-22", "ms-teams-docs-23", "ms-teams-docs-24", "ms-teams-docs-2", "ms-teams-docs-19", "ms-teams-probe-4", "ms-teams-probe-1", "ms-teams-probe-3" ] }, { "productId": "ms-teams", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Teams documents Incoming and Outgoing Webhooks and Connectors that let external services subscribe to and post messages/events to Teams channels (ms-teams-docs-12, ms-teams-docs-30, ms-teams-docs-36, ms-teams-docs-44), which is a real webhook subscription mechanism. However the evidence doesn't show Microsoft Graph's richer change-notification/subscription API for broader event types (message edits, membership changes, etc.), nor any AI-agent-specific webhook workflow. Missing for 10: explicit Graph webhook/subscription API documentation for arbitrary event types, and independent confirmation of reliability for programmatic/AI-native use cases.", "evidenceIds": [ "ms-teams-docs-12", "ms-teams-docs-30", "ms-teams-docs-36", "ms-teams-docs-44" ] }, { "productId": "ms-teams", "storyId": "ai-channel-summaries", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains only general platform/bot/webhook/API docs and community complaints, with no mention of AI-generated channel/thread summaries or 'catch-up' recap features (e.g., Copilot's recap capability is not cited here); nothing ties Copilot or any feature to summarizing missed conversations. Missing for 10: any documentation of a summarization/recap feature for channels or threads, independent verification of its use.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "ai-meeting-recaps", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of Copilot meeting recap, AI-generated notes, or transcript summarization features for Teams meetings/huddles; it only covers bot/app platform docs, Graph APIs, webhooks, and unrelated community complaints. Missing for 10: any documentation of Copilot meeting recap/notes generation, evidence of summarizing missed meetings, or hands-on confirmation of this capability.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of an interactive API reference with runnable examples; probes show llms.txt, docs-md, and openapi.json endpoints all 404, and cited docs are static reference/tutorial pages with no mention of interactive/runnable playgrounds.", "evidenceIds": [ "ms-teams-probe-1", "ms-teams-probe-2", "ms-teams-probe-3" ] }, { "productId": "ms-teams", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Teams/Graph exposes REST APIs (e.g., channel-post-messages) so an OpenAPI-style spec is a plausible ask, but the evidence pack shows explicit probe failures (404s) for openapi.json/swagger.json and no documentation page offering a downloadable machine-readable spec.", "evidenceIds": [ "ms-teams-probe-3", "ms-teams-probe-1", "ms-teams-probe-2" ] }, { "productId": "ms-teams", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence describes a sandbox/test environment isolated from production data for Teams; docs cover agent creation, toolkit CLI, provisioning, and publishing but never mention a dedicated sandbox mode or test tenant separate from live data. missing for 10: dedicated sandbox/test-tenant environment, documentation on data isolation from production, any first-party or community confirmation of safe testing without touching real data.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Graph API endpoints are referenced (e.g., graph-rest-1.0 versioning), no evidence pack item documents an explicit API versioning scheme or deprecation policy for Teams/Graph APIs; probes for OpenAPI specs and machine-readable docs also returned 404s. Missing for 10: documented API version lifecycle, deprecation timelines, and changelog/versioning policy pages.", "evidenceIds": [ "ms-teams-docs-11", "ms-teams-docs-21", "ms-teams-probe-3" ] }, { "productId": "ms-teams", "storyId": "app-marketplace", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Teams docs mention publishing agents/apps to Teams (ms-teams-docs-7) and built-in Connectors that let users subscribe to notifications from external web services (ms-teams-docs-30, ms-teams-docs-36, ms-teams-docs-44), implying a gallery of prebuilt integrations, but the evidence never explicitly describes a team-admin-facing app directory/marketplace (e.g., Teams Admin Center app catalog or AppSource) or an admin installation workflow. Missing for 10: explicit documentation of the Teams Admin Center app catalog/AppSource marketplace, admin approval/installation flow for prebuilt third-party apps, and independent corroboration of ease of use for admins.", "evidenceIds": [ "ms-teams-docs-7", "ms-teams-docs-30", "ms-teams-docs-36", "ms-teams-docs-44", "ms-teams-docs-19" ] }, { "productId": "ms-teams", "storyId": "audio-video-calls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs confirm Teams delivers integrated 'calling' alongside chat and meetings (ms-teams-docs-18), and community reports reference an in-app 'join call UI' and audio/video controls during calls (ms-teams-comm-10), implying calls happen without leaving the client. However, there is no specific documentation describing the exact one-click call button from a channel or DM, nor confirmation it works reliably. Missing for 10: explicit product docs on the channel/DM call-start UI, and reliable hands-on confirmation (the only firsthand account cites bugs with call UI being broken/missing).", "evidenceIds": [ "ms-teams-docs-18", "ms-teams-comm-10" ] }, { "productId": "ms-teams", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes individual Graph API calls (single channel message send, single team/channel creation, export APIs) and CLI commands for single agent/app packaging, but nothing documents bulk or batch operations across many items at once (e.g., batch message send, bulk channel creation, bulk data export in one call). Missing for 10: batch API support, bulk create/update endpoints, CLI bulk commands, or any documented example of operating on multiple items simultaneously.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-11", "ms-teams-docs-13", "ms-teams-docs-35", "ms-teams-docs-43" ] }, { "productId": "ms-teams", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Teams offers webhooks/connectors and Graph API triggers (incoming/outgoing webhooks, channel message posting) that could be wired into external automation like Power Automate, but there's no native user-facing rule engine within Teams itself for defining 'if event X then action Y' automations. missing for 10: a documented native automation/rules builder (e.g., Power Automate integration specifics), evidence of trigger-condition-action configuration UI, and independent confirmation of reliability.", "evidenceIds": [ "ms-teams-docs-12", "ms-teams-docs-30", "ms-teams-docs-36", "ms-teams-docs-44", "ms-teams-docs-11", "ms-teams-docs-8" ] }, { "productId": "ms-teams", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack shows Teams supporting scheduled or recurring jobs/workflows (e.g., no mention of Power Automate/Workflows integration, cron-like triggers, or recurring automation setup) — the docs cover bots, tabs, message extensions, webhooks, and CLI tooling but nothing about recurring/scheduled automation. Missing for 10: any documentation of recurring/scheduled workflow triggers, workflow automation platform integration, or CLI/API support for scheduling jobs.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any versioning, review, or rollback capability for automations/workflows in Teams; the Agents Toolkit CLI docs cover creation, provisioning, and publishing but nothing about version history, diffing, review workflows, or reverting a deployed agent/automation to a prior state.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "custom-slash-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Microsoft's official developer docs explicitly document 'Agent slash commands' as a supported bot/agent capability for Teams apps, allowing developers to register custom commands invoked from the message compose box. Missing for 10: no detailed first-party walkthrough content beyond the title/reference, and no independent/hands-on developer corroboration of the feature in practice.", "evidenceIds": [ "ms-teams-docs-6", "ms-teams-docs-28", "ms-teams-docs-40" ] }, { "productId": "ms-teams", "storyId": "external-guest-access", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of guest accounts, external access controls, or shared channels for cross-organization collaboration — it focuses entirely on bots, agents, APIs, webhooks, and app development. Missing for 10: any documentation of guest account provisioning, external user permissions, shared/B2B channels, or admin controls governing external partner access.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "free-tier-full-history", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses free-tier message history retention policies, retention limits, or admin controls for preserving history without upgrading; the pack covers bots, agents, APIs, webhooks, and general complaints, none of which touch pricing-tier history retention.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "full-history-search", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no vendor documentation of an admin-facing search feature with sender/channel/date filters — only generic Export APIs for compliance extraction (ms-teams-docs-13,14), which do not describe search/filter UI. Community reports explicitly complain that Teams search cannot filter Files by type or search within a channel and results can't be sorted (ms-teams-comm-11) and that 'search is abysmal' (ms-teams-comm-8), reinforcing the lack of evidence for this capability.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14", "ms-teams-comm-11", "ms-teams-comm-8" ] }, { "productId": "ms-teams", "storyId": "granular-notifications", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack documents per-channel, keyword, or schedule-based notification tuning; the only related community evidence explicitly says users 'can't seem to unsubscribe' and that muting notifications is 'impossible' even with settings turned off. missing for 10: any docs on channel-level notification settings, keyword alerts, or scheduled quiet hours.", "evidenceIds": [ "ms-teams-comm-14", "ms-teams-comm-15" ] }, { "productId": "ms-teams", "storyId": "incoming-webhook-post", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Docs clearly describe Incoming Webhooks as a way to post messages from external apps to a Teams channel via a webhook URL (ms-teams-docs-36, ms-teams-docs-12, ms-teams-docs-44, ms-teams-docs-30), matching the story's ask. However, hands-on community feedback contradicts the 'simple' framing, stating that real API integration with Teams 'requires the full Azure/Graph API stack unlike Slack's simple webhooks' (ms-teams-comm-11), indicating the webhook path is not as frictionless as documented. Missing for 10: independent corroboration that incoming webhook setup is as simple in practice as the docs claim, and clarity on whether legacy Incoming Webhooks/connectors remain fully supported going forward.", "evidenceIds": [ "ms-teams-docs-36", "ms-teams-docs-12", "ms-teams-docs-44", "ms-teams-docs-30", "ms-teams-comm-11" ] }, { "productId": "ms-teams", "storyId": "interactive-app-ui", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs confirm Teams platform supports rich in-chat UI building blocks — tabs, message extensions, message streaming, suggested actions, and bots — which are the primitives used to build modals, buttons, and structured layouts in Teams chat. However, the evidence never explicitly names 'Adaptive Cards' or 'task modules/dialogs' (the actual modal/button mechanism), and there is no independent developer corroboration of building such rich UI. Missing for 10: explicit Adaptive Cards/dialog (modal) documentation citation, hands-on developer testimony confirming ease of building interactive card UI.", "evidenceIds": [ "ms-teams-docs-3", "ms-teams-docs-4", "ms-teams-docs-5", "ms-teams-docs-40", "ms-teams-docs-25", "ms-teams-docs-26", "ms-teams-docs-27" ] }, { "productId": "ms-teams", "storyId": "no-code-workflow-builder", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence pack covers developer-oriented bots, connectors, webhooks, and the Agents Toolkit CLI, all of which require coding/deployment rather than a no-code, admin-facing workflow builder triggered by events/schedules/forms; there is no mention of a no-code automation surface (e.g., Power Automate/Workflows app) inside Teams chat.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Microsoft Graph and the Bot/Agents Toolkit expose substantial programmatic control—creating teams/channels, posting messages, managing webhooks, exporting chats, and building agents/bots/tabs—but this is a broad SDK/app-extension surface, not a documented 1:1 API mirror of every UI action (e.g., meetings/calls, reactions, threading UI). A community report also notes API integration requires the full Azure/Graph stack, unlike simpler alternatives, indicating friction rather than seamless UI-API parity. Missing for 10: explicit API coverage for meeting/calling controls and other real-time UI actions, and independent verification that all UI capabilities are exposed via API.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-11", "ms-teams-docs-19", "ms-teams-docs-35", "ms-teams-docs-44", "ms-teams-comm-11" ] }, { "productId": "ms-teams", "storyId": "openness-full-export", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Microsoft documents Teams Export APIs that let (typically admin/compliance) users export 1:1, group, meeting, and channel chat content, including recently deleted messages — showing some data portability exists. However, this is framed as a compliance/eDiscovery tool rather than a self-service 'export everything and leave' flow, and no evidence specifies open, non-proprietary formats or a full account/data export including files, calendar, and settings. Missing for 10: explicit open-format guarantee (e.g., JSON/CSV/mbox), self-service full account export for ordinary end-users, and confirmation of completeness (files, contacts, calendar) beyond chat messages.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14" ] }, { "productId": "ms-teams", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Microsoft Teams is closed-source proprietary software; no evidence in the pack indicates any open-license source availability, and the axis clearly applies since the story concerns openness of source code.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Microsoft Teams is a proprietary SaaS cloud service with no evidence of a self-hostable core product; all evidence describes cloud-hosted collaboration, extensibility via bots/tabs/connectors, and Azure-hosted app deployment, not self-hosting the Teams service itself.", "evidenceIds": [ "ms-teams-docs-18", "ms-teams-docs-23" ] }, { "productId": "ms-teams", "storyId": "organize-channels", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence confirms Teams channels exist and can be created/configured via Graph API (ms-teams-docs-8, ms-teams-docs-35, ms-teams-docs-43), implying channel-based organization, but nothing explicitly documents public vs. private channel types or membership/access controls for admins. Missing for 10: explicit documentation of public/private channel distinction, membership management APIs or admin UI, and any independent confirmation of these controls working as described.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-35", "ms-teams-docs-43" ] }, { "productId": "ms-teams", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses data residency, regional storage options, or geo-controls for Teams data; all evidence concerns app development, messaging features, or unrelated reliability/security complaints.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses opt-out or controls for AI/model-training use of Teams data; docs cover bots, agents, webhooks, and Copilot features but nothing about training-data exclusion or privacy controls for AI training.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Teams' Graph docs mention export APIs and note that user-deleted messages remain recoverable for 21 days, showing some retention/deletion behavior exists, but there is no evidence of AI-native controls (e.g., agent-specific data retention settings, deletion APIs for AI interactions, or admin policies tailored to AI usage). Missing for 10: explicit AI/agent data retention controls, user-facing deletion tools, and documentation on how AI interaction data (e.g., Copilot logs) is retained or purged.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14" ] }, { "productId": "ms-teams", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry opt-out or usage-tracking controls for AI-native users; the documentation excerpts cover app/agent building, messaging, webhooks, and CLI tooling, with no mention of privacy/telemetry settings. Missing for 10: any documentation of a telemetry opt-out mechanism, admin controls for usage tracking, or AI-specific data collection settings.", "evidenceIds": [] }, { "productId": "ms-teams", "storyId": "realtime-bot-events", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Teams supports building bots that receive messages/events, with docs covering bot creation, message streaming, slash commands, and porting Slack Bolt apps (implying event-driven bot architecture), plus webhooks/connectors for real-time notifications to channels. However, evidence never explicitly describes a dedicated 'events API' or gateway/WebSocket connection mechanism (like Slack's Events API or Socket Mode) — the Bot Framework's underlying real-time messaging endpoint mechanics aren't detailed, and one community comment notes API integration requires the full Azure/Graph stack rather than simple webhooks, adding friction. Missing for 10: explicit documentation of the real-time events/gateway protocol (e.g., Bot Framework messaging endpoint or streaming API mechanics), independent/hands-on validation of real-time event delivery reliability.", "evidenceIds": [ "ms-teams-docs-1", "ms-teams-docs-2", "ms-teams-docs-5", "ms-teams-docs-6", "ms-teams-docs-12", "ms-teams-docs-30", "ms-teams-docs-36", "ms-teams-comm-11" ] }, { "productId": "ms-teams", "storyId": "retention-legal-hold", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The evidence only covers Teams Export APIs for retrieving 1:1, group, meeting, and channel messages (including deleted messages up to 21 days) for eDiscovery-style export, but there is no documentation of retention policy configuration, legal hold mechanisms, or Purview-based compliance controls referenced in this pack. Missing for 10: retention policy documentation, legal hold configuration/enforcement details, and independent/hands-on confirmation of compliance workflows.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14" ] }, { "productId": "ms-teams", "storyId": "screen-sharing", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Teams docs only vaguely reference 'meetings and calling' features without a specific citation of screen-sharing, while community hands-on reports confirm the capability exists (screen share + annotation) but describe it as slow to enable ('a good 30 seconds') and annotation mode 'gets stuck', undermining the smooth live-collaboration promise. Missing for 10: explicit first-party documentation of the screen-share feature, admin/policy controls for screen sharing, and reliability corroboration beyond the negative anecdotes.", "evidenceIds": [ "ms-teams-docs-18", "ms-teams-comm-4", "ms-teams-comm-9" ] }, { "productId": "ms-teams", "storyId": "threaded-replies", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Teams channels do support conversation threads (implied by generic docs about conversations and channel messaging, e.g. ms-teams-docs-9, ms-teams-docs-11), but the evidence pack lacks any first-party documentation specifically describing 'reply in thread' functionality, and multiple community reports call out threading as confusing or poorly implemented ('the biggest issue was the threading; it truly beggars belief', 'no threading... inconsistent UI', 'took me long to realise... to follow along the threads'). Missing for 10: explicit product docs/UI walkthrough of thread-reply feature, and independent confirmation that threading works smoothly rather than being a pain point.", "evidenceIds": [ "ms-teams-docs-9", "ms-teams-docs-11", "ms-teams-comm-9", "ms-teams-comm-12", "ms-teams-comm-17" ] }, { "productId": "ms-teams", "storyId": "topic-based-catchup", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Docs confirm Teams channels exist and can be organized with channels/tabs (ms-teams-docs-8, ms-teams-docs-35, ms-teams-docs-43), implying topic-based organization, but hands-on community reports directly contradict effective thread/topic organization: 'The biggest issue was the threading; it truly beggars belief' and no ability to link to conversations, with 'inconsistent UI between channels and direct chats (no threading/code blocks in DMs)' and users confused distinguishing chat vs threads. Missing for 10: first-party documentation specifically describing named-topic thread organization, and any hands-on evidence that threading actually helps admins catch up efficiently.", "evidenceIds": [ "ms-teams-docs-8", "ms-teams-docs-35", "ms-teams-docs-43", "ms-teams-comm-17", "ms-teams-comm-9", "ms-teams-comm-12" ] }, { "productId": "ms-teams", "storyId": "workspace-history-export", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Microsoft documents Teams Export APIs that allow admins to export 1:1, group chat, meeting chats, and channel messages, including recovering deletions within 21 days, which directly supports machine-readable compliance exports. However, evidence does not confirm formats, full scope of 'all private conversations where policy allows', eDiscovery integration details, or independent/hands-on verification. Missing for 10: documentation of specific export file formats/schema, confirmation of full coverage of private chats beyond examples, independent or hands-on validation of the export process, and details on policy-based access controls governing what admins can export.", "evidenceIds": [ "ms-teams-docs-13", "ms-teams-docs-14" ] }, { "productId": "slack", "storyId": "admin-audit-logs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack includes only workspace data export/import documentation (e.g., slack-docs-22/23/35/36) and community complaints about export restrictions (slack-comm-2), but nothing that documents an audit log capability tracking admin and user actions across the workspace. This is a fair and applicable axis for an enterprise collaboration platform, so absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "slack-docs-22", "slack-docs-23", "slack-docs-35", "slack-docs-36", "slack-comm-2" ] }, { "productId": "slack", "storyId": "agent-channel-member", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack's Events API lets bots/apps respond to activity in channels ('Slack calls you'), and its ecosystem explicitly supports adding AI agents like ChatGPT, Claude, and Slackbot as channel-integrated participants that act on mentions/requests (e.g. 'start using tools like ChatGPT, Claude... within your chats', 'Route work through Slackbot... routing requests to agents', 'Coding agents can now work with your whole team'). Combined with the CLI/Bolt SDKs for building bot apps that join channels, this shows the underlying capability is well supported. Missing for 10: explicit first-party documentation of the app_mention event/scope specifically triggering agent responses, and independent hands-on confirmation that a mentioned agent reliably replies in-channel.", "evidenceIds": [ "slack-docs-47", "slack-docs-7", "slack-docs-63", "slack-docs-14", "slack-docs-37", "slack-docs-69", "slack-intdir-1", "slack-intdir-3", "slack-docs-9", "slack-docs-71" ] }, { "productId": "slack", "storyId": "agent-reads-posts-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack's official Web API (chat.postMessage, chat.history-type methods via OpenAPI spec covering user/bot token usage) plus scoped OAuth tokens is well documented, enabling agents to read and post channel messages programmatically; the MCP server and SDKs (Bolt, node-slack-sdk) further formalize agent access with admin-approved scopes. missing for 10: no independent hands-on developer report confirming real-world token-scoping friction or reliability at scale, and no explicit doc excerpt enumerating channel-read scopes (e.g., channels:history) alongside chat:write in one place.", "evidenceIds": [ "slack-docs-8", "slack-docs-32", "slack-docs-48", "slack-supp-openapi-spec", "slack-docs-2", "slack-docs-28", "slack-docs-46", "slack-docs-74" ] }, { "productId": "slack", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack has a confirmed llms.txt at docs.slack.dev/llms.txt (HTTP 200) plus llms-full-deno.txt variants, and its developer docs are explicitly agent-oriented (MCP server, AI build guides, quickstart) suitable for pointing an agent at. missing for 10: no independent/community confirmation of an agent successfully consuming llms.txt in practice, and OpenAPI-style machine spec endpoints under docs.slack.dev returned 404.", "evidenceIds": [ "slack-probe-1", "slack-docs-72", "slack-docs-75", "slack-probe-3", "slack-probe-2" ] }, { "productId": "slack", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack ships built-in AI features (intelligent daily briefing, Slackbot summaries/recaps, channel/thread summarization, workspace-wide semantic search across integrated data, meeting notes from huddles) that surface AI-generated insights directly inside the product, per slack-docs-13/14/15/16/19/34/52. missing for 10: independent/hands-on verification of insight quality and accuracy, and detail on how suggestions are surfaced/actioned beyond marketing copy.", "evidenceIds": [ "slack-docs-13", "slack-docs-14", "slack-docs-15", "slack-docs-16", "slack-docs-19", "slack-docs-34", "slack-docs-52" ] }, { "productId": "slack", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack's Workflow Builder lets users build no-code automations with triggers (including webhook triggers from outside Slack) and conditional branching that run autonomously in the background once configured, and the Events API/CLI/Bolt frameworks let developers build bots/apps that respond to activity without manual intervention. This directly satisfies the 'autonomous background automation' story for AI-native and non-technical users alike. missing for 10: independent/hands-on verification that these automations run reliably unattended over time, and explicit AI-agent-triggered automation examples beyond marketing copy", "evidenceIds": [ "slack-docs-10", "slack-docs-11", "slack-docs-12", "slack-docs-41", "slack-docs-50", "slack-docs-51", "slack-docs-6", "slack-docs-7", "slack-docs-47" ] }, { "productId": "slack", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack ships Slackbot as a built-in AI agent that can summarize channels, prepare meeting briefs, analyze reports, answer open-ended questions, and act on tasks like updating deals or routing work to other agents (slack-docs-13,14,15,38,55,57,69). This is a native, in-product delegation capability, not just a third-party integration. Missing for 10: independent/hands-on user reports confirming Slackbot's agentic task delegation works as advertised, and more detail on the scope of actions it can autonomously perform beyond summarization/Q&A.", "evidenceIds": [ "slack-docs-13", "slack-docs-14", "slack-docs-15", "slack-docs-38", "slack-docs-55", "slack-docs-57", "slack-docs-69" ] }, { "productId": "slack", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack's Web API (chat.postMessage etc.) is a pure HTTP interface callable without any UI, the Events API supports webhook/Socket Mode server-side listening, Workflow Builder supports webhook triggers to kick off automations from outside Slack, and the Slack CLI/Bolt SDKs let apps be built, deployed, and run non-interactively — all enabling headless automation suitable for CI-like use. Missing for 10: explicit CI/CD pipeline examples (e.g. GitHub Actions integration), and no documentation of running the CLI/SDKs specifically inside a CI runner or headless test harness.", "evidenceIds": [ "slack-docs-8", "slack-docs-48", "slack-docs-11", "slack-docs-31", "slack-docs-7", "slack-docs-9", "slack-docs-74", "slack-supp-openapi-spec", "slack-docs-71" ] }, { "productId": "slack", "storyId": "agentic-mcp-client", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All evidence describes Slack exposing its own official MCP server so external AI clients (Claude, ChatGPT, custom agents) can call Slack's tools — the reverse direction of this story, which asks whether a user can plug external MCP servers into Slack so Slack's own agents (e.g., Slackbot) can use their tools. No evidence shows Slack acting as an MCP client that consumes third-party MCP servers.", "evidenceIds": [ "slack-docs-2", "slack-docs-28", "slack-docs-46", "slack-docs-72", "slack-docs-69" ] }, { "productId": "slack", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack publishes an official MCP server (docs.slack.dev/ai/slack-mcp-server/) that lets MCP clients/agents search channels, send/draft messages, manage canvases, lists, files, and users, with admin approval controls for governance; this is corroborated by a direct probe confirming the docs page exists. Missing for 10: independent hands-on third-party verification of the MCP server's real-world reliability/performance beyond first-party docs.", "evidenceIds": [ "slack-docs-2", "slack-docs-28", "slack-docs-29", "slack-docs-30", "slack-docs-46", "slack-docs-61", "slack-probe-3" ] }, { "productId": "slack", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack ships Slackbot as an in-product AI agent that responds to natural-language requests (e.g., 'Update deals just by asking Slackbot', daily briefings, summarization, open-ended Q&A) and exposes an official MCP server so AI assistants can search, message, and manage Slack objects via natural language. This directly supports NL-command operation for AI-native users.\n\nmissing for 10: independent/hands-on validation of Slackbot NL command accuracy and reliability, and clearer documentation of the scope/limits of what natural-language commands can trigger (vs. workflow builder's no-code but still menu-driven automations).", "evidenceIds": [ "slack-docs-13", "slack-docs-14", "slack-docs-15", "slack-docs-38", "slack-docs-55", "slack-docs-57", "slack-docs-58", "slack-docs-72", "slack-docs-2", "slack-docs-28" ] }, { "productId": "slack", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack ships an official CLI for building/managing Slack apps (slack-docs-9, slack-docs-1, slack-docs-26/40/60, slack-probe-4), with quickstart guides supporting Bolt frameworks in multiple languages, tied into an AI-native workflow (docs mention creating agents via 'slack create' and building AI-integrated apps). Missing for 10: independent/hands-on community corroboration of the CLI itself (community evidence in the pack is unrelated to CLI usage) and more detail on AI-native-specific CLI commands beyond scaffolding.", "evidenceIds": [ "slack-docs-9", "slack-docs-1", "slack-docs-26", "slack-docs-40", "slack-docs-60", "slack-docs-71", "slack-probe-4" ] }, { "productId": "slack", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Slack ships extensive documented public APIs (Web API with 200+ methods, Events API, Bolt/CLI SDKs, official OpenAPI/AsyncAPI specs in slackapi/slack-api-specs) plus an official MCP server enabling AI-native agents to search, message, upload files, manage lists/canvases — all first-party documented and independently verifiable via the public GitHub spec repo. missing for 10: no independent hands-on report specifically confirming the raw REST/Web API (vs MCP) working end-to-end from a third-party AI integrator, and the docs.slack.dev/openapi.json probe returned 404 suggesting the interactive spec isn't hosted at the expected discovery path.", "evidenceIds": [ "slack-docs-8", "slack-docs-32", "slack-docs-2", "slack-docs-28", "slack-docs-46", "slack-docs-9", "slack-docs-71", "slack-docs-74", "slack-supp-openapi-spec", "slack-probe-3", "slack-probe-4", "slack-probe-2" ] }, { "productId": "slack", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Slack's API model implies scoped bot/user tokens (the OpenAPI spec notes 'user and bot user token usage of public Web API methods') and admin approval of MCP client integrations is described as keeping data safe, suggesting some governance over agent access, but there is no explicit documentation of an OAuth-scopes system or a user-facing flow to mint least-privilege credentials specifically for an agent. Missing for 10: explicit OAuth scope list/granularity docs, a documented workflow for a user to generate a scoped token for an agent, and any admin/user UI for restricting agent permissions beyond MCP client approval.", "evidenceIds": [ "slack-supp-openapi-spec", "slack-docs-46", "slack-docs-49" ] }, { "productId": "slack", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Slack ships multiple official SDKs (Bolt for Java, node-slack-sdk, Deno Slack SDK), an official CLI, Web API with published OpenAPI spec, Events API, and Block Kit docs, all clearly documented as first-party developer tooling for building AI-native/agentic integrations, plus a developer sandbox for safe testing. Missing for 10: independent/hands-on developer corroboration beyond official docs and a fully discoverable OpenAPI endpoint (probe found candidate paths 404 despite spec repo existing).", "evidenceIds": [ "slack-docs-73", "slack-docs-74", "slack-docs-75", "slack-docs-9", "slack-docs-71", "slack-docs-8", "slack-docs-32", "slack-docs-47", "slack-docs-49", "slack-supp-openapi-spec", "slack-docs-76" ] }, { "productId": "slack", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack's Events API lets developers subscribe to specific event types via webhook (public HTTP endpoint) or Socket Mode, with Slack calling the subscriber's endpoint on events — a core webhook-subscription mechanism well documented for building AI/agentic integrations. Workflow Builder also supports webhook triggers for starting workflows externally, reinforcing webhook-based event subscription. missing for 10: independent/hands-on corroboration of webhook reliability at scale, and more explicit framing of Events API webhooks specifically for AI-native/agent consumption (most AI-agent docs emphasize MCP/Web API rather than raw event webhooks).", "evidenceIds": [ "slack-docs-6", "slack-docs-7", "slack-docs-31", "slack-docs-47", "slack-docs-63", "slack-docs-11", "slack-docs-50" ] }, { "productId": "slack", "storyId": "ai-channel-summaries", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Slack's first-party AI features docs explicitly state AI in Slack can summarize channels and threads and serve daily recaps (slack-docs-15), backed by Slackbot as an intelligent daily briefing/agent (slack-docs-13, slack-docs-14) and huddle note-taking/recaps (slack-docs-19, slack-docs-34). This directly matches the story of AI-generated summaries/recaps of missed channels/threads. Missing for 10: independent/hands-on verification of summary quality or accuracy, and no community evidence corroborating real-world reliability of this specific feature (community evidence pack focuses on unrelated pain points like pricing/export/threads UX).", "evidenceIds": [ "slack-docs-13", "slack-docs-14", "slack-docs-15", "slack-docs-19", "slack-docs-34" ] }, { "productId": "slack", "storyId": "ai-meeting-recaps", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Slack's docs directly claim AI note-taking for huddles (key takeaways, action items, who said what compiled at huddle end) and AI-generated channel/thread summaries and daily recaps for content missed, matching the story's core ask. Missing for 10: independent/hands-on corroboration of huddle-note accuracy or completeness, and no explicit confirmation that recaps cover 'missed' meetings specifically (recaps are framed around channels/threads more than scheduled meetings).", "evidenceIds": [ "slack-docs-19", "slack-docs-34", "slack-docs-15", "slack-docs-17", "slack-docs-44", "slack-docs-20", "slack-docs-53" ] }, { "productId": "slack", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Slack has API method reference docs (e.g. chat.postMessage) and an OpenAPI/AsyncAPI spec repo, but there is no evidence of an interactive, runnable API reference (e.g. a Swagger/try-it console); a direct probe for openapi.json/swagger.json on the docs site returned 404s, indicating no in-browser interactive reference exists.", "evidenceIds": [ "slack-docs-48", "slack-supp-openapi-spec", "slack-probe-2" ] }, { "productId": "slack", "storyId": "api-machine-spec", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "An official OpenAPI 2.0 spec for the Web API (and AsyncAPI spec for Events API) exists in the slackapi/slack-api-specs GitHub repo, satisfying the core ask of a machine-readable spec. However, live probes show the obvious/expected locations on docs.slack.dev (openapi.json, swagger.json, etc.) all 404, meaning the spec isn't directly downloadable from the primary docs site and requires knowing about a separate GitHub repo. Missing for 10: direct download link from docs.slack.dev, first-party documentation pointing users to the spec repo, and independent confirmation the spec is kept in sync with the live API.", "evidenceIds": [ "slack-supp-openapi-spec", "slack-probe-2", "slack-docs-8", "slack-docs-32" ] }, { "productId": "slack", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack's official docs describe a 'developer sandbox' as an Enterprise org environment explicitly built to let developers 'build against all Slack features safely and securely' and 'empower teams to build without putting production at risk,' directly matching the story of testing without touching production data. However, missing for 10: independent/hands-on confirmation of the sandbox in use, clarity on whether this is available outside Enterprise plans, and detail on how it isolates AI/agent-specific testing (e.g., MCP server or bot testing) within that sandbox.", "evidenceIds": [ "slack-docs-49", "slack-docs-62" ] }, { "productId": "slack", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Slack maintains official OpenAPI specs for its Web API and a dated, running deprecation changelog with explicit migration windows (e.g., classic app deprecation date), which supports documented deprecation policy; the Web API and Events API references also show first-party API documentation. However, there's no explicit evidence of a formal API versioning scheme (e.g., v1/v2 endpoint versioning) beyond method-level docs and changelog dates. Missing for 10: explicit versioning scheme documentation, independent/community corroboration of deprecation practices being honored reliably.", "evidenceIds": [ "slack-supp-openapi-spec", "slack-supp-deprecations", "slack-docs-8", "slack-docs-32" ] }, { "productId": "slack", "storyId": "app-marketplace", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack explicitly advertises an App Directory with 2,600+ prebuilt apps (Salesforce, Jira, Google Drive, ChatGPT, etc.) and a help doc specifically for admins on how to add apps to a workspace. This directly matches the team-admin persona and app-platform theme. missing for 10: independent/hands-on confirmation of the admin install/approval workflow beyond the docs, and no detail on admin-specific approval controls for directory apps (only MCP client approval is mentioned).", "evidenceIds": [ "slack-docs-21", "slack-docs-42", "slack-docs-54" ] }, { "productId": "slack", "storyId": "audio-video-calls", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack's Huddles feature lets any user click the headphones icon in a channel/DM header to instantly start audio or video calls with screen sharing, all inside the app, and includes admin-manageable extras like AI notes and saved shared content. missing for 10: no explicit documentation of admin-specific controls/permissions for enabling or restricting huddles, and no independent hands-on corroboration beyond Slack's own marketing docs.", "evidenceIds": [ "slack-docs-18", "slack-docs-33", "slack-docs-24", "slack-docs-19", "slack-docs-20", "slack-docs-25" ] }, { "productId": "slack", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Slack's Web API and MCP server document single-item actions (send one message, upload one file, create one list entry, etc.) with no documented batch/bulk endpoints or MCP tools for operating across many items in one call. Workflow Builder and automations are trigger-based, not bulk-operation mechanisms, and export tools are admin-only data dumps rather than AI-native bulk actions.", "evidenceIds": [] }, { "productId": "slack", "storyId": "automation-rules-engine", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Slack's Workflow Builder lets users define triggers, conditional branches, and webhook-based automations that fire actions on events (message posted, emoji reaction, webhook call, etc.), directly matching the story; the Events API further supports event-driven automation. missing for 10: independent/hands-on verification of workflow trigger reliability and no evidence of AI-native rule authoring beyond no-code builder.", "evidenceIds": [ "slack-docs-10", "slack-docs-11", "slack-docs-12", "slack-docs-50", "slack-docs-51", "slack-docs-6", "slack-docs-7", "slack-docs-47" ] }, { "productId": "slack", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Slack's Workflow Builder is documented as a no-code automation tool with webhook triggers and conditional branching, which are automation-depth building blocks, but the evidence never explicitly mentions a 'scheduled' or 'recurring' trigger type for jobs/workflows. AI-native automation is described mostly around single-shot chat/AI features (summaries, briefings) rather than recurring job scheduling. missing for 10: explicit documentation of scheduled/recurring trigger type in Workflow Builder, independent confirmation of recurring automation use, and any AI-agent-specific recurring job scheduling capability.", "evidenceIds": [ "slack-docs-10", "slack-docs-11", "slack-docs-12", "slack-docs-41", "slack-docs-50", "slack-docs-51" ] }, { "productId": "slack", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers Workflow Builder's creation, branching, and webhook triggers, but nothing describes version history, change review, or rollback capabilities for workflows/automations built in Slack. The axis is applicable (automation platforms commonly offer versioning/rollback) but no supporting evidence exists.", "evidenceIds": [ "slack-docs-10", "slack-docs-11", "slack-docs-12", "slack-docs-41", "slack-docs-50", "slack-docs-51" ] }, { "productId": "slack", "storyId": "custom-slash-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Slack's general app-platform tooling (CLI, Bolt frameworks, Web/Events APIs, Block Kit, Workflow Builder, MCP server) but never mentions slash commands specifically as a registrable app feature invoked from the message box.", "evidenceIds": [] }, { "productId": "slack", "storyId": "external-guest-access", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of guest accounts, Slack Connect, or shared/external channels with limited access — nothing about admin controls for external collaboration appears anywhere in the docs, community, or probe items. This is a mainstream, applicable capability for a workspace chat product, but absence of evidence means it cannot be credited.", "evidenceIds": [] }, { "productId": "slack", "storyId": "free-tier-full-history", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Slack marketing claims 'Unlimited message history' (slack-docs-43), but this benefit is documented on the pricing page and is know to apply to paid tiers, and multiple community reports concretely describe free workspaces having message/storage limits enforced, with older messages disappearing once a few thousand messages are exceeded (slack-comm-10, slack-comm-15). This directly contradicts the idea that a team-admin can stay on a free tier indefinitely without losing history. Missing for 10: an explicit first-party statement about free-tier retention limits, and any first-party pricing-page confirmation that free tier does NOT purge history.", "evidenceIds": [ "slack-docs-43", "slack-comm-10", "slack-comm-15" ] }, { "productId": "slack", "storyId": "full-history-search", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Slack docs confirm full, unlimited searchable message history (slack-docs-43, slack-docs-16/52) and Slack's native search supports filtering, but the evidence pack does not explicitly document admin-specific advanced search operators (from:, in:, before:/after:) or an admin-console-level cross-workspace search UI beyond general user search claims; the MCP server also offers 'searching through Slack' but is a separate API-driven tool rather than the admin search UI itself. missing for 10: explicit documentation of native in-app search filter syntax (sender/channel/date), evidence of admin-level search scope (e.g. Enterprise-wide search across workspaces), and independent/hands-on confirmation of filter functionality.", "evidenceIds": [ "slack-docs-43", "slack-docs-16", "slack-docs-52", "slack-docs-28" ] }, { "productId": "slack", "storyId": "granular-notifications", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no documentation on per-channel/keyword/schedule notification preferences (e.g., mute channels, keyword alerts, do-not-disturb scheduling) — Slack's actual notification settings are not represented anywhere in this pack, only unrelated AI, workflow, MCP, and integration docs. Missing for 10: any mention of notification preferences, keyword alerts, per-channel mute/schedule controls, or admin-level notification policy tools.", "evidenceIds": [] }, { "productId": "slack", "storyId": "incoming-webhook-post", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Slack's docs evidence shows webhook-based triggers for Workflow Builder (\"how to start a workflow from outside of Slack\") and the chat.postMessage Web API method for sending messages, both of which can be used to post into a channel from an external system, but neither is the classic single-URL 'Incoming Webhook' integration developers commonly expect. Missing for 10: explicit documentation of the dedicated Incoming Webhooks app/URL for zero-config posting, and any hands-on confirmation that a bare webhook POST (without workflow setup or OAuth token) posts a message.", "evidenceIds": [ "slack-docs-11", "slack-docs-50", "slack-docs-48", "slack-docs-8" ] }, { "productId": "slack", "storyId": "interactive-app-ui", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Slack's Block Kit is explicitly documented as the JSON-based framework for building modals, messages, and tabs with the same building blocks, backed by chat.postMessage's structured 'blocks' parameter, plus SDKs (Bolt for Java/Python/JS, Node Slack SDK) and CLI tooling to build these apps. This directly matches the story of building rich interactive UI (modals, buttons, structured layouts) inside Slack chat. Missing for 10: no independent/hands-on developer corroboration of the Block Kit UI-building experience beyond first-party docs.", "evidenceIds": [ "slack-docs-76", "slack-docs-70", "slack-docs-48", "slack-docs-71", "slack-docs-73", "slack-docs-74", "slack-docs-9" ] }, { "productId": "slack", "storyId": "no-code-workflow-builder", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Slack's Workflow Builder is documented as a no-code way to build workflows directly in Slack, supporting event/schedule/form-submission triggers, webhook triggers, and conditional branching. missing for 10: independent/hands-on corroboration of the builder in use, and detail on schedule-based triggers specifically beyond webhook/event mentions.", "evidenceIds": [ "slack-docs-10", "slack-docs-11", "slack-docs-12", "slack-docs-41", "slack-docs-50", "slack-docs-51" ] }, { "productId": "slack", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Slack ships an extensive Web API (200+ methods per slack-docs-74), an Events API, official OpenAPI/AsyncAPI specs (slack-supp-openapi-spec), a CLI, SDKs, and an MCP server covering messaging, search, canvases, lists, and file uploads (slack-docs-8, slack-docs-28-30, slack-docs-48). However, community evidence shows a concrete gap: exporting DMs and private channel content requires legal/compliance justification and Slack approval, not open self-serve API access (slack-comm-2, slack-comm-4), and moderation tooling is described as 'purposefully useless' compared to UI expectations (slack-comm-9). Missing for 10: verified parity for admin/compliance-only UI actions (e.g., full data export, moderation controls) via API, and a public discoverable OpenAPI schema (probe shows standard openapi.json paths 404, slack-probe-2).", "evidenceIds": [ "slack-docs-8", "slack-docs-74", "slack-supp-openapi-spec", "slack-docs-28", "slack-docs-48", "slack-comm-2", "slack-comm-4", "slack-comm-9", "slack-probe-2" ] }, { "productId": "slack", "storyId": "openness-full-export", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Slack documents a workspace data export feature (slack-docs-22/23/35/36), but concrete community evidence shows this is heavily restricted in practice: Corporate Export of DMs/private channels requires legal/compliance justification and Slack's approval (slack-comm-2), users openly question whether multi-year history can even be exported (slack-comm-4), and Slack has shut down open-protocol (IRC/XMPP) access that once enabled third-party/portable access (slack-comm-11). There's no evidence the export format is genuinely open/interoperable rather than a locked-down archive. Missing for 10: documented open export format specification, independent confirmation of unrestricted self-service export, and no contradicting reports of approval gating.", "evidenceIds": [ "slack-docs-22", "slack-docs-23", "slack-docs-35", "slack-docs-36", "slack-comm-2", "slack-comm-4", "slack-comm-11" ] }, { "productId": "slack", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Slack is closed-source proprietary SaaS; no evidence of any open-licensed source code release. Its CLI, MCP server, and APIs are tools around a closed core, not the product's source itself.", "evidenceIds": [] }, { "productId": "slack", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Slack is a cloud SaaS product; the evidence pack shows only hosted/cloud offerings, developer sandboxes, CLI, SDKs, and export tools—no self-hosted deployment option is documented anywhere, and community evidence even discusses difficulty exporting data or migrating off Slack's hosted service.", "evidenceIds": [ "slack-docs-49", "slack-docs-64", "slack-comm-2", "slack-comm-4" ] }, { "productId": "slack", "storyId": "organize-channels", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack focuses almost entirely on Slack's AI/MCP tooling, developer SDKs, huddles, and integrations, with no first-party documentation describing channel creation, public vs. private channel types, or admin membership controls. The only channel-related mentions (e.g., MCP 'search channels', a raw SEO keyword list) do not document this admin capability.", "evidenceIds": [] }, { "productId": "slack", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions data residency, regional storage options, or geographic data controls for Slack; the evidence covers MCP servers, APIs, workflows, and AI features but nothing about choosing where data is stored. This is a fair axis for an enterprise SaaS product, but absence of evidence means it cannot be credited.", "evidenceIds": [] }, { "productId": "slack", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data opt-out or controls preventing Slack/customer data from being used to train AI models; the pack covers unrelated AI features (search, summarization, MCP server) and export/pricing controversies but nothing about AI-training data usage or opt-out settings.", "evidenceIds": [] }, { "productId": "slack", "storyId": "privacy-retention-controls", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Slack documents workspace export/import tools (data retention/deletion-adjacent controls), but community evidence explicitly says business customers can't freely export their own chats — Corporate Export requires legal/compliance justification and Slack's approval, and even feasibility of full history export is questioned. This directly contradicts the notion of straightforward user/admin control over data retention and deletion. Missing for 10: explicit documentation of configurable retention periods, deletion policies/workflows, and independent confirmation that exports/deletions can be self-served without gatekeeping.", "evidenceIds": [ "slack-docs-22", "slack-docs-23", "slack-docs-35", "slack-docs-36", "slack-comm-2", "slack-comm-4" ] }, { "productId": "slack", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses telemetry or usage-tracking opt-out controls for Slack; the privacy/data-export items (slack-comm-2, slack-docs-22/23/35/36) relate to data export/retention, not telemetry opt-out. This axis plausibly applies to a SaaS collaboration product, but no supporting capability is documented.", "evidenceIds": [] }, { "productId": "slack", "storyId": "realtime-bot-events", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Slack's Events API is explicitly documented to push real-time events to developer-built apps/bots via HTTP endpoint or Socket Mode, with subscription filtering, and this is complemented by SDKs (Bolt for Java, Node SDK) and quickstart guides for building bots. Missing for 10: independent hands-on developer corroboration of reliability/latency of the events pipeline beyond first-party docs.", "evidenceIds": [ "slack-docs-6", "slack-docs-7", "slack-docs-31", "slack-docs-47", "slack-docs-63", "slack-docs-73", "slack-docs-74", "slack-docs-71" ] }, { "productId": "slack", "storyId": "retention-legal-hold", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows generic data export/import guides (slack-docs-22/23/35/36) and a community note that Corporate Export requires legal/compliance justification and Slack approval (slack-comm-2), but nothing documents actual retention-policy enforcement, legal-hold placement, or eDiscovery tooling. Missing for 10: retention policy configuration, legal hold mechanism, eDiscovery search/export APIs, admin documentation on compliance holds.", "evidenceIds": [ "slack-docs-22", "slack-docs-23", "slack-docs-35", "slack-docs-36", "slack-comm-2" ] }, { "productId": "slack", "storyId": "screen-sharing", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Slack huddles explicitly support instant audio/video connection with screen sharing directly in the conversation, usable by any team member including admins, per first-party docs (slack-docs-33, slack-docs-66, slack-docs-18). However, missing for 10: independent/hands-on corroboration of screen-share quality or reliability, and no explicit admin-specific controls or documentation around screen sharing during calls beyond the general huddles feature description.", "evidenceIds": [ "slack-docs-33", "slack-docs-66", "slack-docs-18", "slack-docs-24" ] }, { "productId": "slack", "storyId": "threaded-replies", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "No first-party Slack documentation in this evidence pack describes the threading/reply feature directly; the only evidence that threads exist comes from community complaints (comm-12, comm-14) confirming the feature is used but describing it as poorly notified, hard to find replies, and 'close to impossible to use' as a tiny side panel with missing capabilities (snippets/files/slash commands not working in threads). This suggests threads function but with real UX friction, not a clean full delivery. Missing for 10: official docs/screenshots describing thread-reply UX, independent confirmation that reply notifications and thread views work smoothly, and resolution of the cited usability complaints.", "evidenceIds": [ "slack-comm-12", "slack-comm-14" ] }, { "productId": "slack", "storyId": "topic-based-catchup", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Slack does support channel/thread organization plus AI features to summarize channels and threads for catching up (slack-docs-15, slack-docs-19, slack-docs-34), but concrete hands-on community reports say the thread implementation itself is poorly organized and hard to use — notifications don't auto-update, threads are 'a tiny section off to the side,' and Slack 'encourages saying everything in the main channel' rather than threads (slack-comm-12, slack-comm-14). This directly contradicts the premise that conversations are cleanly organized under threads for efficient catch-up. Missing for 10: independent verification that threading/summarization actually resolves the catch-up problem in practice, admin-specific tooling for enforcing thread discipline.", "evidenceIds": [ "slack-docs-15", "slack-docs-19", "slack-docs-34", "slack-comm-12", "slack-comm-14" ] }, { "productId": "slack", "storyId": "workspace-history-export", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Slack does document official export tools for workspace data (slack-docs-22/23/35/36), which nominally support the compliance-export story, but community evidence directly contradicts free/easy access: Corporate Export of DMs and private channels requires legal/compliance justification and Slack's approval, and users questioned whether migrating years of full message history out of Slack is even feasible under these restrictions. Missing for 10: no first-party documentation of a machine-readable format spec (JSON/CSV schema details), no evidence addressing the approval-gate friction, and no independent confirmation that large-scale/private-channel exports actually work in practice.", "evidenceIds": [ "slack-docs-22", "slack-docs-23", "slack-docs-35", "slack-docs-36", "slack-comm-2", "slack-comm-4" ] }, { "productId": "zulip", "storyId": "admin-audit-logs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention audit logs, admin action logs, or user activity tracking features in Zulip; the evidence covers topics, channels, search, bots, integrations, and export/import tools but nothing about auditability of admin/user actions.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "agent-channel-member", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Zulip's documented bot framework lets you write and run custom bots (including via a dedicated Botserver for production) that 'react to messages,' and the full REST/API surface (confirmed live and via OpenAPI spec) supports sending/receiving messages, which is the technical substrate needed for an AI-agent-as-channel-member use case. However, this requires custom bot development rather than a first-party 'add an AI agent to a channel' feature, and there's no explicit documentation or evidence of native @-mention-triggered AI agent participation out of the box. Missing for 10: explicit first-party AI-agent bot support (vs generic bot framework), documentation of mention-triggered behavior specifically, and independent/hands-on confirmation of an AI agent actually participating in a channel conversation.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-18", "zulip-docs-24", "zulip-probe-4", "zulip-probe-5" ] }, { "productId": "zulip", "storyId": "agent-reads-posts-api", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Zulip ships a documented, versioned REST API (OpenAPI spec, live endpoint confirmed) with a bot framework specifically designed to read and react to channel messages and a documented message-sending endpoint, plus an official CLI/Python client for scripting — bots authenticate via their own per-bot API key, which functions as a scoped credential distinct from a user's. missing for 10: explicit documentation of granular token scopes/permissions (vs. just per-bot keys), and an explicit documented 'read messages' endpoint (only send-message and bot-reacts-to-message are directly evidenced).", "evidenceIds": [ "zulip-docs-4", "zulip-docs-5", "zulip-docs-12", "zulip-docs-18", "zulip-probe-4", "zulip-probe-5", "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "No llms.txt exists (confirmed 404) and other agent-friendly doc endpoints (openapi.json, docs.md) also 404 on the primary domain, but Zulip does publish a full machine-readable OpenAPI spec in its GitHub repo that an agent could be pointed at to understand the API surface. This is a weak substitute for a true llms.txt/agent-docs entry point. Missing for 10: an actual llms.txt file, any officially surfaced agent-oriented documentation page, and discoverability of the OpenAPI spec from the main docs site rather than only via GitHub raw.", "evidenceIds": [ "zulip-probe-1", "zulip-probe-2", "zulip-probe-3", "zulip-probe-5" ] }, { "productId": "zulip", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any AI-generated insights, summarization, or suggestion features surfaced within Zulip itself; evidence covers topics, channels, search, bots (rule-based), integrations, and hosting/export, none of which involve AI analysis of data. Missing for 10: any AI summarization/insight feature, AI-generated suggestions, or documented AI assistant surfaced in the product UI.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Zulip supports bots that run autonomously in the background via its bot API framework and Botserver for production deployment, plus a full REST/OpenAPI API and CLI tools for scripting automations. However, this is a general chatbot/integration framework rather than an AI-native agentic automation platform with built-in scheduling, triggers, or autonomous task orchestration. Missing for 10: evidence of AI-specific agent orchestration, native scheduling/triggering beyond message-reactive bots, and independent hands-on validation that bots run reliably unattended in production.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-18", "zulip-probe-5", "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Zulip's evidence covers bots/integrations built by users via its API, but there is no mention of a built-in AI assistant that users can delegate tasks to directly within the product.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Zulip ships a documented REST API (OpenAPI spec verified live), a keyless-working API endpoint, and an official Python CLI (zulip-send) that installs via pip and runs headlessly from scripts, supporting basic CI automation like sending messages. However, there's no evidence of first-class CI/CD integration patterns, GitHub Actions examples, containerized headless server mode, or broader automation tooling beyond bots/webhooks. missing for 10: CI-specific documentation or examples, containerized/headless deployment guidance for automation pipelines, evidence of use in real CI workflows.", "evidenceIds": [ "zulip-probe-4", "zulip-probe-5", "zulip-probe-6", "zulip-docs-4", "zulip-docs-18" ] }, { "productId": "zulip", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Zulip is a team chat/communication platform, not an AI agent or assistant; there is no evidence of MCP client functionality allowing it to plug in and use MCP servers' tools. This is a category mismatch — MCP client integration applies to AI agents/assistants, not to a chat product like Zulip (though it does offer bots/integrations, those are unrelated to MCP).", "evidenceIds": [] }, { "productId": "zulip", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Zulip is a chat platform, so publishing an official MCP server to let AI agents connect is a plausible axis, but no evidence pack item mentions MCP at all — only bots, webhooks, REST API, and OpenAPI spec are documented. missing for 10: any mention of an MCP server (official or community), MCP protocol support, or agent-connection tooling beyond generic bots/API.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-probe-5" ] }, { "productId": "zulip", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Zulip's docs describe channels, topics, search filters, and a bot API for building reactive bots, but none of this constitutes an AI-native natural-language command interface for operating the product itself — no evidence of NLU-driven commands, AI assistant, or agentic control layer. missing for 10: any natural-language command parsing/interface, AI assistant for operating Zulip, evidence of NL-driven actions beyond keyword search filters.", "evidenceIds": [ "zulip-docs-3", "zulip-docs-23", "zulip-docs-4", "zulip-docs-12" ] }, { "productId": "zulip", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Hands-on evidence confirms an official 'zulip-send' CLI installs via PyPI and runs headlessly for scripting message sends, which supports agentic/automation use cases. However, the evidence pack shows no broader CLI feature set (e.g., reading messages, managing channels, bots) beyond sending, and no first-party docs elaborating CLI capabilities beyond the probe. Missing for 10: documented full CLI command reference, evidence of read/administrative CLI operations, and independent community corroboration of CLI use in agentic workflows.", "evidenceIds": [ "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Zulip publishes a documented REST API (zulip.com/api) backed by a full OpenAPI 3.0 spec in its repo, verified live against a public server responding to documented endpoints, plus an official Python CLI (zulip-send) installable via pip for scripting/automation. This directly supports an AI-native user driving the product programmatically. Missing for 10: no discoverable llms.txt or machine-readable docs endpoint for LLM consumption, and no independent third-party corroboration beyond hands-on probes.", "evidenceIds": [ "zulip-docs-5", "zulip-probe-4", "zulip-probe-5", "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Zulip documents bot accounts and API keys for automation, but no evidence shows a mechanism for issuing scoped or least-privilege credentials (e.g., restricted permission bots, granular API scopes) specifically for AI agents — bots appear to get a single API key without documented fine-grained access controls.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-18", "zulip-docs-24" ] }, { "productId": "zulip", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip ships an official Python SDK/CLI installable via PyPI (pip install zulip) with hands-on verified functionality (zulip-send), a full machine-readable OpenAPI 3.0.1 spec covering the REST API, and a live documented REST API confirmed working on a public server. This directly satisfies building against official SDKs for an AI-native/agentic workflow. Missing for 10: no evidence of SDKs in other languages (JS/Node, Go, etc.), no llms.txt or dedicated agent-facing docs, and no independent third-party corroboration of SDK quality beyond the hands-on probe.", "evidenceIds": [ "zulip-probe-4", "zulip-probe-5", "zulip-probe-6", "zulip-docs-5" ] }, { "productId": "zulip", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows Zulip supports *incoming* webhooks for pushing external events into Zulip (zulip-docs-19) and a bot framework for reacting to messages (zulip-docs-4/12/24), but nothing documents an outgoing webhook mechanism for an AI-native user to subscribe to Zulip's own events. missing for 10: documentation of outgoing/subscription webhooks, event-type configuration, or webhook payload schema for external consumers.", "evidenceIds": [ "zulip-docs-19", "zulip-docs-4", "zulip-docs-12" ] }, { "productId": "zulip", "storyId": "ai-channel-summaries", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any AI-generated summary, recap, or digest feature for missed channels/threads; documentation focuses on topics, search, bots, integrations, and export/import but never mentions AI summarization.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "ai-meeting-recaps", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any meeting/huddle recording, transcription, or AI-generated recap/notes feature; Zulip's evidence covers topics, channels, bots, integrations, and self-hosting but nothing about calls, huddles, or AI summarization of conversations.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Zulip publishes a full machine-readable OpenAPI 3.0 spec for its REST API (zulip-probe-5) and a public API reference site with example endpoints like 'Send a message' (zulip-docs-5), and the API is confirmed live and functional hands-on (zulip-probe-4). However, there is no direct evidence that the API reference page itself offers interactive 'try it out' runnable examples in-browser rather than just documented curl/code snippets. Missing for 10: explicit confirmation of an in-browser interactive/try-it console on the API docs, independent user reports of using runnable examples.", "evidenceIds": [ "zulip-docs-5", "zulip-probe-5", "zulip-probe-4" ] }, { "productId": "zulip", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Zulip's REST API ships a machine-readable OpenAPI 3.0.1 spec (zulip.yaml, ~1.5MB) directly in its repo, confirmed hands-on, and the live API docs at zulip.com/api/ are generated from this spec. Missing for 10: no dedicated discoverable download link/endpoint on the main docs site itself (openapi.json probes 404'd, so it's not trivially discoverable without knowing the GitHub path).", "evidenceIds": [ "zulip-probe-5", "zulip-docs-5", "zulip-probe-3" ] }, { "productId": "zulip", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers self-hosting, export/import, integrations, and API access, but nowhere mentions a dedicated sandbox, staging, or test-mode instance that is separate from production data. Nothing describes a way to safely test bots/integrations against non-production data without standing up and fully configuring an entirely separate self-hosted server.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Zulip clearly has a documented, machine-readable REST API (OpenAPI spec, live endpoint, CLI) per zulip-docs-5, zulip-probe-4/5/6, the evidence pack contains no mention of API versioning scheme or a deprecation policy for changed/removed endpoints. Missing for 10: documentation of API version numbers, backward-compatibility guarantees, or a deprecation/changelog process.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "app-marketplace", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Zulip provides an official integrations directory (zulip.com/integrations) listing 130+ native prebuilt integrations plus Zapier/IFTTT for hundreds more, which team-admins can browse and install/configure (e.g., via incoming webhooks) without custom coding. missing for 10: no evidence of an in-app 'install with one click' marketplace UI or independent hands-on confirmation of the install flow.", "evidenceIds": [ "zulip-docs-9", "zulip-docs-13", "zulip-docs-19" ] }, { "productId": "zulip", "storyId": "audio-video-calls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions audio/video calling features in Zulip; all documentation and community references cover topics, channels, search, bots, integrations, export/import, and self-hosting, but nothing about starting a call from a channel or DM.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Zulip exposes a full REST API and CLI tooling (zulip-probe-5, zulip-probe-6, zulip-docs-5) that could theoretically be scripted, the evidence pack contains no documentation or hands-on proof of a bulk/batch endpoint (e.g., mass message updates, bulk channel management, batch subscribe/unsubscribe) that lets an AI-native user act on many items in one call. missing for 10: documented bulk-update/bulk-delete/batch endpoints, evidence of batch request support, any example of operating on multiple items in a single API call.", "evidenceIds": [ "zulip-docs-5", "zulip-probe-5", "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Zulip has no documented native rules/automation engine; the closest capabilities are a bot framework requiring custom code (zulip-docs-4/12/24) and webhook/Zapier/IFTTT integrations (zulip-docs-9/19) that let external tools trigger actions on Zulip events. This is automation via third-party glue or coding, not a built-in 'define rules' feature. Missing for 10: a native no-code rules/trigger builder, first-party documentation of event-condition-action automation, and any evidence of it working out-of-the-box without external services or custom bot code.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-9", "zulip-docs-12", "zulip-docs-19", "zulip-docs-24" ] }, { "productId": "zulip", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Zulip is a team chat platform with bots, integrations, and an API for sending messages, but there is no evidence of any scheduler, cron-like feature, or recurring workflow/job automation capability — only reactive bots and one-off messages are documented.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-18", "zulip-docs-5" ] }, { "productId": "zulip", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Zulip is a team chat platform, not an automation/workflow-building tool with a concept of 'automations' that could be versioned, reviewed, or rolled back; while it supports bots/integrations, there's no evidence of any automation-authoring feature with version control or rollback semantics. This axis is a category error for a chat product rather than an unmet capability.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "custom-slash-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Zulip's docs describe an interactive-bot framework that reacts to messages, but there is no evidence of a slash-command registration API or mechanism where a developer registers a custom command invoked via '/' in the message box, distinct from Slack-style slash commands.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-24", "zulip-docs-18" ] }, { "productId": "zulip", "storyId": "external-guest-access", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Zulip docs mention that 'guests' are a distinct role with restricted channel subscription ability (zulip-docs-22), implying a guest-account mechanism exists, but the evidence pack contains no documentation of inviting external partners, guest account setup/permissions, or any shared-channel/cross-organization collaboration feature. Missing for 10: explicit guest-invite workflow docs, permission scoping details for guests, and any shared-channel-with-external-org capability or independent confirmation it works in practice.", "evidenceIds": [ "zulip-docs-22" ] }, { "productId": "zulip", "storyId": "free-tier-full-history", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of Zulip's free-tier message history limits or retention policy, so there is no support for the claim that a free-tier team retains full access to older messages. Missing for 10: any documentation or community evidence about free-plan message history caps/retention, and confirmation that free tier does not truncate history.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "full-history-search", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Zulip's docs confirm a full-text search with real filter syntax (channel:design, has:image, channels:public) and state it offers 'a wide array of search filters', but the evidence pack never shows explicit sender: or date-range filter syntax, and one community report from 2016 claims the search function 'barely works'. missing for 10: explicit sender: and date/time filter documentation, independent verification of search accuracy, resolution of the community complaint about search reliability.", "evidenceIds": [ "zulip-docs-3", "zulip-docs-17", "zulip-docs-23", "zulip-comm-13" ] }, { "productId": "zulip", "storyId": "granular-notifications", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no documentation or mentions of per-channel, per-keyword, or scheduled notification controls (e.g., no citations about notification settings, alert words, or do-not-disturb/quiet hours) — only topics, channels, search, bots, and export/import material. Notification tuning is a standard, fair axis for a chat product, but nothing in the pack demonstrates it.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "incoming-webhook-post", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip explicitly documents incoming webhooks as a native integration type (zulip-docs-19) alongside 130+ native integrations (zulip-docs-9/13), and its API includes a straightforward 'send a message' endpoint (zulip-docs-5) backed by a full OpenAPI spec (zulip-probe-5) and live-verified API (zulip-probe-4). This matches the standard incoming-webhook-posts-to-channel pattern. Missing for 10: a first-party doc snippet showing the exact incoming-webhook URL format/config screen, and independent third-party confirmation of webhook setup ease.", "evidenceIds": [ "zulip-docs-19", "zulip-docs-9", "zulip-docs-5", "zulip-probe-5", "zulip-probe-4" ] }, { "productId": "zulip", "storyId": "interactive-app-ui", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers Zulip's bot/API framework, integrations, and messaging features but contains no mention of interactive UI elements like modals, buttons, or structured message layouts within chat (unlike Slack's Block Kit or similar). Missing for 10: any documentation of interactive message components, modal dialogs, button widgets, or structured layout building blocks for developers.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "no-code-workflow-builder", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Zulip's evidence shows only custom-coded bots, webhooks, and 130+ integrations plus optional Zapier/IFTTT connections (external tools), but no built-in no-code workflow/automation builder with triggers, schedules, or form submissions inside the chat product itself.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-9", "zulip-docs-12", "zulip-docs-19" ] }, { "productId": "zulip", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Zulip ships a large, machine-readable OpenAPI spec (~1.5MB) covering messaging, bots, integrations, and administration, with a live public endpoint confirming the API works and an official CLI/bot framework for scripting (zulip-probe-5, zulip-probe-4, zulip-probe-6, zulip-docs-5, zulip-docs-12). However, there is no explicit vendor or independent claim that every UI action (e.g., search filters, topic management UI nuances) has a 1:1 API equivalent. Missing for 10: explicit UI-API parity documentation/audit, independent confirmation that all UI-only features (e.g., advanced search UX, settings toggles) are scriptable via API.", "evidenceIds": [ "zulip-probe-5", "zulip-probe-4", "zulip-probe-6", "zulip-docs-5", "zulip-docs-12" ] }, { "productId": "zulip", "storyId": "openness-full-export", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip documents high-quality export tools that let users take both public and private (consented) data out in open formats, explicitly for migrating away from Zulip Cloud to self-hosted servers, and is fully open-source/self-hostable so no vendor lock-in exists. This directly matches 'export data and leave.' Missing for 10: no independent/hands-on verification of the export file format's openness or completeness, and no community testimonial specifically confirming a successful full data exodus.", "evidenceIds": [ "zulip-docs-6", "zulip-docs-10", "zulip-docs-14", "zulip-docs-8", "zulip-comm-8" ] }, { "productId": "zulip", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip's source code is hosted publicly on GitHub with a contributing guide, and Zulip is widely documented (including in community evidence) as being fully open-source (100% FOSS, not open-core), consistent with its known Apache 2.0 licensing. Missing for 10: explicit citation of the license file/text itself and independent third-party confirmation of the specific license terms.", "evidenceIds": [ "zulip-gh-1", "zulip-comm-8" ] }, { "productId": "zulip", "storyId": "openness-self-host", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "Zulip is documented as fully open-source and self-hostable, with official production install docs, import/export tools to migrate between cloud and self-host, and a GitHub repo for contributing (zulip-docs-8, zulip-docs-25, zulip-docs-7, zulip-gh-1). However, community hands-on reports describe real friction: installs require a dedicated server/VM with poor containerization support, heavy RAM requirements, and limited distro support beyond Ubuntu (zulip-comm-18, zulip-comm-13, zulip-comm-14, zulip-comm-3). Missing for 10: independent verification that installation friction has been resolved, broader OS/container support, and clearer resource-requirement documentation.", "evidenceIds": [ "zulip-docs-8", "zulip-docs-25", "zulip-docs-7", "zulip-docs-20", "zulip-gh-1", "zulip-comm-18", "zulip-comm-13", "zulip-comm-14", "zulip-comm-3" ] }, { "productId": "zulip", "storyId": "organize-channels", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm channels can be public/private/web-public with subscription controls (zulip-docs-2, zulip-docs-22), and channel-scoped search/export tools acknowledge private channel membership boundaries (zulip-docs-14, zulip-docs-17). However, there is no explicit documentation of admin-side membership management workflows (adding/removing members, role-based permissions per channel) or granular channel permission settings. missing for 10: detailed admin UI/API for managing channel membership and permissions, evidence of private channel invite-only enforcement, independent corroboration of admin controls in practice.", "evidenceIds": [ "zulip-docs-2", "zulip-docs-22", "zulip-docs-14", "zulip-docs-17" ] }, { "productId": "zulip", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Zulip's self-hosting docs let users install the server 'on a system of your choice' anywhere they want, effectively giving control over data location/residency, and full export/import tools support migrating data between Zulip Cloud and self-hosted servers. However, there is no evidence of a built-in region-selection feature within Zulip Cloud itself (e.g., choosing EU vs US data centers) — the only residency mechanism is self-hosting your own infrastructure. Missing for 10: explicit multi-region hosting options within Zulip Cloud, documented data-residency guarantees, and independent confirmation of regional deployment support.", "evidenceIds": [ "zulip-docs-8", "zulip-docs-25", "zulip-docs-6", "zulip-docs-10", "zulip-docs-20" ] }, { "productId": "zulip", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data usage, opt-out controls, or any explicit AI-training privacy policy for Zulip; self-hosting is mentioned but not tied to preventing AI training use of data. missing for 10: explicit policy/statement on AI model training use of data, opt-out mechanism, or contractual guarantee against training use.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Zulip's self-hosting option and data export/import tools (including exporting private data with consent) give users significant control over where their data lives and how it can be extracted or migrated, which touches on data retention/portability. However, there is no direct evidence of message retention policies, auto-deletion settings, or a documented data-deletion workflow for accounts/messages. Missing for 10: explicit retention-policy controls, message/account deletion documentation, and any GDPR-style data-deletion API or admin setting.", "evidenceIds": [ "zulip-docs-6", "zulip-docs-10", "zulip-docs-14", "zulip-docs-8", "zulip-docs-25" ] }, { "productId": "zulip", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry, usage tracking, analytics collection, or an opt-out setting for Zulip; the self-hosting docs discuss data export/import and deployment but never mention telemetry controls.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "realtime-bot-events", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Zulip explicitly documents a bot framework that lets developers write custom bots that 'react to messages in Zulip' in real time, deployable persistently via the Zulip Botserver, backed by a full OpenAPI-documented REST API and a working live API endpoint plus an installable CLI/client library for scripting integrations. This maps to Zulip's known events/register API model for real-time bots, though the evidence pack never names the events/register endpoints or long-polling mechanics explicitly. Missing for 10: explicit documentation/citation of the events/register API endpoints and real-time event queue mechanics, and independent hands-on confirmation of a bot actually receiving live events.", "evidenceIds": [ "zulip-docs-4", "zulip-docs-12", "zulip-docs-18", "zulip-probe-5", "zulip-probe-4", "zulip-probe-6" ] }, { "productId": "zulip", "storyId": "retention-legal-hold", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack only covers data export/import tools for migrating organizations, with no mention of configurable message retention policies, automatic deletion schedules, or legal hold/eDiscovery preservation features. No documentation or community evidence addresses compliance-driven retention enforcement.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "screen-sharing", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Zulip is an async, topic-based chat platform with no evidence of built-in video/audio calling or screen-sharing during calls; this story concerns real-time call features which are outside Zulip's core product category as evidenced here.", "evidenceIds": [] }, { "productId": "zulip", "storyId": "threaded-replies", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip's core topic-based threading model lets users reply within a topic to keep side discussions attached to the original conversation, and community evidence strongly corroborates this as a standout feature ('the killer feature', 'fundamentally superior model' to Slack threads). Docs describe starting/joining topics and searching within them, and admins have the same messaging capabilities as any user. missing for 10: explicit admin-specific documentation on replying in threads (evidence is general-user focused), and some community reports note UX friction/confusion for non-technical users when threading.", "evidenceIds": [ "zulip-docs-1", "zulip-docs-16", "zulip-docs-21", "zulip-comm-5", "zulip-comm-15", "zulip-comm-20", "zulip-comm-9" ] }, { "productId": "zulip", "storyId": "topic-based-catchup", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip's topic model is core to the product: docs explain starting new topics per conversation, subscribing to channels surfaces conversations in inbox/feed, and topic-scoped search lets admins filter busy channels. Community reports strongly corroborate that this threading model is 'fundamentally superior' to Slack for following busy, high-volume discussions without being overwhelmed, and the 'all messages' view helps catch up chronologically across channels. Missing for 10: independent measurement of catch-up efficiency and some community reports note UX friction (miscasting to wrong topic, non-technical user confusion) that slightly tempers the ideal experience.", "evidenceIds": [ "zulip-docs-1", "zulip-docs-2", "zulip-docs-3", "zulip-docs-16", "zulip-docs-21", "zulip-comm-1", "zulip-comm-5", "zulip-comm-11", "zulip-comm-20", "zulip-comm-9", "zulip-comm-10" ] }, { "productId": "zulip", "storyId": "workspace-history-export", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Zulip's docs explicitly describe an export tool that can include 'public and private data (with consent)' — private channel messages and DMs from consenting members — in a machine-readable export format used for migration/backup, directly matching the compliance-export story for a team-admin. This is corroborated by general export/import documentation and self-hosting docs confirming full data portability. Missing for 10: independent/hands-on verification of the export tool's exact output format and confirmation of admin-level override for private data without member consent.", "evidenceIds": [ "zulip-docs-6", "zulip-docs-14", "zulip-docs-10", "zulip-docs-7" ] } ]