[
  {
    "productId": "1password",
    "storyId": "agent-code-retrieval",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "1Password docs confirm OTP storage/lookup in the app (docs-20, docs-24, docs-19) and a general-purpose CLI/SDK for programmatic item access (docs-1, docs-2, docs-26, probe-rt-3), which together imply an agent could retrieve a TOTP field via CLI, but no evidence explicitly documents a TOTP-specific command or API response format for pulling a live 2FA code in an automated workflow. missing for 10: explicit CLI/API documentation of TOTP field retrieval (e.g., a `--otp` flag or field type), and any example/community confirmation of an agent completing 2FA end-to-end.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-24",
      "1password-docs-19",
      "1password-docs-1",
      "1password-docs-2",
      "1password-docs-26",
      "1password-probe-rt-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agent-local-endpoint",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "The 1Password CLI (`op`) and SDKs/Connect Server provide a local, scriptable, programmatic interface (not screen-scraping) that returns items, secrets, and OTP codes directly, and this is corroborated by real-world packaging (Homebrew cask) confirming it's a genuine local endpoint agents can shell out to. Missing for 10: no direct hands-on evidence of an AI agent actually querying the CLI/Connect Server for codes, and the newer MCP server explicitly withholds raw secrets from the agent, so full 'codes and secrets' access is only fully realized via CLI/SDK, not MCP.",
    "evidenceIds": [
      "1password-docs-1",
      "1password-docs-2",
      "1password-docs-3",
      "1password-docs-4",
      "1password-docs-26",
      "1password-probe-3",
      "1password-probe-rt-3",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agent-vault-provisioning",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "1Password documents multiple programmatic surfaces (CLI, SDKs in Go/JS/Python, Connect Servers REST API, Service Accounts) explicitly for 'Automate item management: Programmatically manage items in your 1Password account,' which covers creating and updating vault entries including credentials.  These are official, well-documented interfaces suitable for agent-driven automation. Missing for 10: an explicit documented example/field reference for seeding TOTP secrets via these APIs, and independent/hands-on verification that write operations (create/update, not just read) work reliably in practice.",
    "evidenceIds": [
      "1password-docs-8",
      "1password-docs-26",
      "1password-docs-4",
      "1password-docs-5",
      "1password-docs-1",
      "1password-probe-rt-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-agent-docs",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "1Password.dev and support.1password.com both serve confirmed llms.txt/llms-full.txt files plus markdown mirrors of every docs page, and this is directly verified via live probes, not just claims. missing for 10: independent third-party (non-vendor) confirmation that agents actually consume these files successfully in practice.",
    "evidenceIds": [
      "1password-probe-1",
      "1password-probe-rt-2",
      "1password-docs-27",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-ai-insights",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password's evidence shows rule-based security features (Watchtower flags weak/breached passwords) and developer-facing MCP/SDK/CLI tooling for external agents to access secrets, but nothing about the product itself generating AI-driven insights or suggestions from a user's stored data. Missing for 10: any AI-generated analysis, recommendations, or summaries surfaced inside the 1Password app/UI itself.",
    "evidenceIds": [
      "1password-docs-18",
      "1password-docs-27",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-autonomous-automation",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "1Password provides machine-facing automation building blocks — Service Accounts, Connect Servers, Credential Broker, CLI, and SDKs — that let CI/CD pipelines and other unattended workflows fetch secrets autonomously in the background, and the Environments MCP Server lets AI agents manage secrets without human intervention. However, there's no evidence of a general-purpose scheduler, trigger system, or orchestration layer for building broader 'automations' beyond secrets retrieval/injection. Missing for 10: native scheduling/triggers, workflow orchestration UI, and evidence of autonomous multi-step automations beyond secret access.",
    "evidenceIds": [
      "1password-docs-3",
      "1password-docs-4",
      "1password-docs-5",
      "1password-docs-7",
      "1password-docs-26",
      "1password-probe-rt-1",
      "1password-docs-27"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-builtin-assistant",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence shows 1Password exposes MCP servers, CLI, and SDKs so external AI agents (Claude Code, Cursor, Codex) can call into 1Password's data — the opposite of a built-in assistant inside 1Password itself. No evidence describes an in-product AI assistant a user can delegate tasks to.",
    "evidenceIds": [
      "1password-docs-27",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-headless",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "1Password ships a dedicated CLI (confirmed packaged via Homebrew cask), Service Accounts explicitly for automating secrets in CI/infrastructure without extra services, Connect Servers exposing a REST API for machine workflows, and a Credential Broker for CI/CD short-lived access — all first-party documented and headless by design. Missing for 10: independent hands-on case studies/community reports specifically validating CI pipeline usage rather than just vendor docs.",
    "evidenceIds": [
      "1password-docs-1",
      "1password-docs-3",
      "1password-docs-4",
      "1password-docs-5",
      "1password-probe-rt-3",
      "1password-probe-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "1Password is a password/secrets manager, not an AI agent or assistant host that consumes external tools via MCP; the evidence shows the opposite direction — 1Password *ships* an MCP server (Environments MCP Server) for other AI agents like Claude Code/Cursor to consume its secrets, not a client surface for plugging in third-party MCP servers itself.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "agentic-mcp-server",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "1Password ships an official Environments MCP Server that lets MCP clients (Claude Code, Codex, Cursor, Kiro) securely manage 1Password Environments without exposing secrets to the agent, and a runtime probe confirms a live keyless MCP initialize handshake against 1Password's own MCP endpoint. This is first-party documentation plus real runtime corroboration of the server actually working. Missing for 10: broader independent/community hands-on reports beyond the vendor probe, and clarity since the Environments MCP server is explicitly marked Beta.",
    "evidenceIds": [
      "1password-docs-27",
      "1password-probe-2",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-nl-commands",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "1Password ships an official Environments MCP Server that lets AI agents (Claude Code, Codex, Cursor, Kiro) manage 1Password Environments via natural-language prompts through MCP clients, and a public docs MCP server for AI-readable documentation — genuine natural-language operability. However this is explicitly Beta and scoped only to Environments/secrets management, not the broader vault/login/passkey functionality that makes up most of 1Password's product surface, and the primary automation surface (CLI, SDKs) is structured commands, not natural language. Missing for 10: NL control over core password/vault/item management, general-availability status of the MCP server, independent hands-on verification of the NL workflow.",
    "evidenceIds": [
      "1password-docs-27",
      "1password-probe-rt-1",
      "1password-probe-2"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-official-cli",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "1Password ships an official `op` CLI with detailed docs, reference commands, Homebrew packaging, and integration with secrets automation, service accounts, and SSH/Git workflows, making it well-suited to AI-native/agentic scripting. missing for 10: independent hands-on review or benchmark of the CLI's use in agentic workflows beyond vendor docs and packaging.",
    "evidenceIds": [
      "1password-docs-1",
      "1password-docs-2",
      "1password-probe-3",
      "1password-probe-rt-3",
      "1password-docs-9"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-public-api",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "1Password exposes a well-documented public API surface for programmatic control: a scriptable CLI (op), official SDKs in Go/JS/Python, a Connect Server REST API, Service Accounts, Events API, and even a public MCP server for AI agents — all backed by first-party docs and confirmed via runtime probes (CLI packaged in Homebrew, MCP handshake succeeding, llms.txt/markdown mirrors of docs). This directly satisfies an AI-native user's need to drive the product via documented APIs rather than only a GUI. Missing for 10: independent third-party developer testimonials/case studies of building against these APIs beyond vendor docs and probes.",
    "evidenceIds": [
      "1password-docs-1",
      "1password-docs-2",
      "1password-docs-4",
      "1password-docs-5",
      "1password-docs-26",
      "1password-gh-1",
      "1password-docs-27",
      "1password-probe-2",
      "1password-probe-3",
      "1password-probe-rt-1",
      "1password-probe-rt-2",
      "1password-probe-rt-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-scoped-keys",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "1Password Service Accounts and Connect Servers support scoped, vault-limited, short-lived credentials for machine/agent workflows, and the Environments MCP Server explicitly avoids returning secrets to the agent, which aligns with least-privilege agent access. However, evidence doesn't show fine-grained per-agent scoping controls, credential rotation/expiry specifics, or audit tooling tailored to AI agents specifically (vs generic machine/service workflows). missing for 10: documentation of granular per-agent permission scoping, credential lifecycle/expiry controls for agents, and independent/hands-on verification of least-privilege enforcement in agent contexts.",
    "evidenceIds": [
      "1password-docs-3",
      "1password-docs-4",
      "1password-docs-5",
      "1password-docs-27",
      "1password-probe-rt-1"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-sdks",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "1Password ships official SDKs for Go, JavaScript, and Python for programmatically interacting with vaults, secrets, and items, backed by GitHub repos, docs, and complementary CLI/Connect/Service Accounts tooling for automation workflows. missing for 10: independent third-party developer testimonials/case studies validating real-world SDK usage beyond vendor docs and GitHub repo descriptions.",
    "evidenceIds": [
      "1password-docs-7",
      "1password-docs-8",
      "1password-docs-26",
      "1password-gh-1",
      "1password-docs-5",
      "1password-docs-4",
      "1password-probe-rt-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "agentic-webhooks",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password documents an Events API for retrieving account activity and forwarding it to a SIEM system, but this is a pull-based polling API, not a webhook subscription mechanism. No evidence anywhere in the pack shows a webhook registration/callback capability for AI-native or any consumers.",
    "evidenceIds": [
      "1password-docs-6"
    ]
  },
  {
    "productId": "1password",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password ships CLI/SDK/API docs, llms.txt exports, and an MCP server, but nothing in the evidence describes an interactive API reference with runnable/try-it examples (e.g., an API console or embedded sandbox); the CLI reference is static text, not executable in-browser. missing for 10: an interactive API explorer/playground, evidence of runnable code samples, any 'try it' console for the REST or SDK APIs.",
    "evidenceIds": [
      "1password-docs-2",
      "1password-docs-4",
      "1password-docs-26",
      "1password-probe-rt-2"
    ]
  },
  {
    "productId": "1password",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password documents REST APIs (Connect Server, Events API) and SDKs, but no evidence pack item mentions a downloadable OpenAPI/Swagger spec or any machine-readable API schema for these APIs. Missing for 10: any OpenAPI/Swagger file, schema reference, or equivalent machine-readable spec for Connect, Events API, or SDKs.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "api-sandbox",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password provides vaults, CLI, Connect, and Service Accounts for automation, but no evidence describes a dedicated sandbox/test environment (e.g., a staging API or non-production account) that would let an AI-native user validate integrations without touching real production vaults/secrets.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack shows 1Password has developer APIs, SDKs, CLI, and Connect servers, but nowhere does it document API versioning schemes or a formal deprecation policy for these interfaces. Missing for 10: explicit API version numbers/headers, a published deprecation/sunset policy, changelog or migration guides for breaking changes.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "app-lock",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "The evidence pack only covers CLI/SDK sign-in via system authentication (Touch ID/Windows Hello) for developer tooling, not the everyday consumer app's biometric/PIN lock screen protecting saved logins or OTP codes on a borrowed phone. No documentation or community evidence in the pack describes the mobile/desktop app requiring biometrics or PIN to unlock and view items like one-time passwords.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "automation-bulk-operations",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "The 1Password CLI (`op item list`, etc.) and SDKs explicitly support programmatic, scriptable management of items ('Automate item management: Programmatically manage items in your 1Password account'), which enables bulk operations via scripting loops or SDK calls. However, there is no dedicated bulk-edit/batch-update command or documentation showing native multi-item bulk operations (e.g., bulk delete, bulk tag) — missing for 10: explicit bulk-operation commands/API endpoints, documented examples of bulk updates across many items, and independent verification of bulk-scale performance.",
    "evidenceIds": [
      "1password-docs-2",
      "1password-docs-8",
      "1password-docs-26",
      "1password-probe-rt-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "automation-rules-engine",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "1Password provides scripting/CLI/SDK automation (op CLI, Connect, service accounts) and an Events API for exporting activity to SIEM, but none of these constitute a user-defined rules engine that automatically triggers actions on events within the product itself; Watchtower only flags issues rather than acting on them. No evidence of an 'if this event happens, then do this action' automation/trigger system exists in the evidence pack.",
    "evidenceIds": [
      "1password-docs-6",
      "1password-docs-18",
      "1password-docs-3",
      "1password-docs-5"
    ]
  },
  {
    "productId": "1password",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "1Password is a password/secrets manager; scheduling recurring jobs or workflows is not a capability category it offers or claims — it provides CLI/SDK/Connect for on-demand secrets access, not a job scheduler or workflow orchestration engine. This axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "automation-versioned-workflows",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence covers 1Password's secrets management, CLI, SDKs, Connect servers, and MCP integrations, but there is no mention of any versioning, review, or rollback mechanism for automations themselves (e.g., audit history of scripts/workflows, diffing, or reverting automation configurations). No evidence of automation version control or rollback exists anywhere in the pack.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "breach-alerting",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Watchtower explicitly flags breaches, weak passwords, duplicate/reused items, and other security problems across saved items, directly matching the story's requirements, and it's surfaced natively in the app/browser extension (also flagging passkey-upgrade opportunities). Missing for 10: independent hands-on verification of Watchtower's breach-detection accuracy/coverage beyond vendor docs.",
    "evidenceIds": [
      "1password-docs-18",
      "1password-docs-13"
    ]
  },
  {
    "productId": "1password",
    "storyId": "browser-extension-autofill",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs confirm browser extension autofills passkeys during sign-in and stores/retrieves one-time passwords (TOTP), covering both parts of the story, with community corroboration of browser extension quality and iframe-aware autofill behavior. Missing for 10: explicit first-party statement or hands-on demo showing TOTP codes specifically autofilled (rather than just 'stored/accessed') and independent confirmation of passkey autofill working reliably across sites.",
    "evidenceIds": [
      "1password-docs-12",
      "1password-docs-14",
      "1password-docs-20",
      "1password-docs-21",
      "1password-comm-4",
      "1password-comm-5"
    ]
  },
  {
    "productId": "1password",
    "storyId": "competitor-import",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "1Password documents general import from other apps/browsers via CSV and the newer Credential Exchange standard on iOS 26+, and it supports storing one-time passwords, but no evidence explicitly confirms bulk import of authenticator/OTP tokens specifically from other authenticator apps (e.g., Google Authenticator, Authy) rather than just passwords/logins. Missing for 10: explicit documentation of OTP-specific bulk import/migration flow from named authenticator apps, and any hands-on/community confirmation that OTP secrets survive the CSV or Credential Exchange import.",
    "evidenceIds": [
      "1password-docs-16",
      "1password-docs-17",
      "1password-docs-23",
      "1password-docs-20"
    ]
  },
  {
    "productId": "1password",
    "storyId": "desktop-app",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Evidence confirms a desktop 1Password app exists (CLI integrates with 'the 1Password app' via Touch ID/Windows Hello, and community references to the Electron-based desktop client) and that vault/OTP data is stored centrally and accessible from apps generally, but no evidence pack item explicitly documents desktop-specific vault UI or OTP display screens, and community notes flag desktop app quality concerns (Electron complaints, no native app comments). missing for 10: dedicated desktop-app feature docs (OTP display, vault browsing UI on Mac/Windows/Linux), first-party screenshots or hands-on confirmation of parity with mobile, and resolution of the Electron/native-app criticism.",
    "evidenceIds": [
      "1password-docs-1",
      "1password-docs-20",
      "1password-comm-8",
      "1password-comm-10",
      "1password-comm-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "device-to-device-transfer",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "The evidence pack covers CLI/SDK/Connect integrations, browser passkeys, import/export from other apps, and OTP storage, but nothing describes a guided 'move to new phone' flow that automatically transfers all tokens/OTPs in one step. Cloud sync via account sign-in is 1Password's usual mechanism, but no citation confirms this specific onboarding experience or that it covers OTP/token migration seamlessly.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "e2ee-backup",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack contains no documentation of 1Password's end-to-end encryption architecture, Secret Key design, or zero-knowledge claims for vaults/backups — it only covers CLI/SDK/Connect/SSH tooling and unrelated community commentary on UX and pricing. Without any citation describing the encryption design or vendor-key-never-held guarantee, this axis is unevidenced.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "lost-phone-recovery",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack covers 1Password's password/OTP storage, sync, import/export between apps, SSH/passkey features, and developer tooling, but contains no documentation of a lost-device recovery path (e.g., Emergency Kit, Secret Key re-enrollment, account recovery flow) that would restore an everyday user's tokens on a new device after losing their phone. Missing for 10: documented device-loss/account-recovery procedure, evidence of Secret Key or Emergency Kit restoration flow, any confirmation that OTPs specifically survive a lost-device scenario.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "multi-device-sync",
    "verdict": "full",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Docs show 1Password stores and retrieves one-time-passwords (tokens) across the browser, Apple Watch, and other apps (docs-20, docs-19/24, docs-21), implying that the same vault (and thus tokens) is accessible from phone, tablet, and desktop, and a community comment confirms 'desktop and mobile work great' (comm-9), suggesting real-world cross-device consistency. However none of the evidence explicitly describes the automatic sync mechanism or confirms real-time consistency across all three device types simultaneously. Missing for 10: explicit documentation of the cloud-sync architecture ensuring instant multi-device consistency, and independent testing/benchmarks of sync latency or conflict handling.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-19",
      "1password-docs-24",
      "1password-docs-21",
      "1password-comm-9"
    ]
  },
  {
    "productId": "1password",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "The evidence only confirms basic one-time password storage (docs-20, docs-19) but contains no mention of Steam Guard tokens, HOTP counter-based codes, or custom period/digit-length TOTP support. Missing for 10: any documentation of Steam Guard support, HOTP counter handling, or custom period/digit configuration.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "offline-code-generation",
    "verdict": "disputed",
    "quality": 3,
    "confidence": "medium",
    "rationale": "1Password does store and display OTP codes (docs-20, docs-24), but the product fundamentally requires a 1Password account/subscription and cloud-synced vault to unlock and view items — community evidence explicitly states 1Password has moved away from local, non-cloud vault storage ('no native apps, no local vault storage... The VC rot has already set in'), directly contradicting the 'no vendor account required' claim. Missing for 10: any first-party or independent confirmation of a fully offline mode with no account signup/sync dependency, and no evidence disputes this gap.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-24",
      "1password-comm-6",
      "1password-comm-7",
      "1password-comm-8"
    ]
  },
  {
    "productId": "1password",
    "storyId": "open-format-export",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "1Password documents a general export feature to move data to another app ([1password-docs-15]), and TOTP/OTP storage is documented ([1password-docs-20]), but no evidence specifies that TOTP secrets are included in the export or that the export format is an open, readable standard (e.g., otpauth:// URIs or plain text) rather than 1Password's proprietary 1PUX format. Missing for 10: explicit confirmation that TOTP secrets are exportable, evidence of an open/readable export format, and independent/hands-on corroboration of successful migration of OTP secrets to another app.",
    "evidenceIds": [
      "1password-docs-15",
      "1password-docs-20"
    ]
  },
  {
    "productId": "1password",
    "storyId": "open-source-clients",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "No evidence in the pack indicates 1Password's client apps are open source or available for community code review; all citations describe closed commercial SDKs, CLI, Connect servers, and browser extension features without any open-source licensing or public repository claims for the core vault/client apps themselves. missing for 10: any statement of open-source licensing for 1Password clients, a public source repository for the desktop/mobile/browser apps, or third-party audit citing open code review.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "openness-api-parity",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "1Password's CLI, SDKs (Go/JS/Python), Connect Server, and Service Accounts let AI/automation programmatically read, create, and manage vault items and secrets ([1password-docs-2],[1password-docs-4],[1password-docs-5],[1password-docs-8],[1password-docs-26]), which covers the core secrets-management workflows. However, many UI-only capabilities — passkey creation/autofill in the browser extension, Watchtower breach/weak-password monitoring, Apple Watch lookups, import/export flows, SSH agent autofill — have no documented API/CLI equivalent, so full UI/API parity is not evidenced. Missing for 10: API-exposed passkey management, Watchtower/security-alerts API, and full item-type/browser-feature parity via CLI or SDK.",
    "evidenceIds": [
      "1password-docs-2",
      "1password-docs-4",
      "1password-docs-5",
      "1password-docs-8",
      "1password-docs-26",
      "1password-docs-18",
      "1password-docs-12",
      "1password-docs-21"
    ]
  },
  {
    "productId": "1password",
    "storyId": "openness-full-export",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "1Password documents a built-in export feature explicitly for moving data to another app, and separately documents CSV import compatibility, implying an open-format export path (e.g. CSV) exists — but the evidence never states which formats export actually produces (1Password's native export is typically 1PUX, not just CSV) nor confirms full data coverage (attachments, SSH keys, secure notes) is included. missing for 10: explicit confirmation that exported format is open/interoperable (not proprietary 1PUX), evidence of full-fidelity data portability, and independent/hands-on confirmation of successful migration.",
    "evidenceIds": [
      "1password-docs-15",
      "1password-docs-16",
      "1password-docs-23"
    ]
  },
  {
    "productId": "1password",
    "storyId": "openness-open-license",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "1Password is closed-source proprietary software; the evidence pack shows CLI, SDKs, MCP servers and docs, but nothing indicating source code is published under an open license. Missing for 10: any evidence of an open-source license, public source repository, or statement of source availability.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "openness-self-host",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "1Password is a cloud-hosted SaaS vault; the only 'self-hosted' pieces are Connect Servers/Environments proxies that still require a cloud 1Password account behind them, not the core vault itself. Community comments explicitly confirm the loss of local/offline vault storage and no self-host option ('no native apps, no local vault storage... VC rot has already set in'), and there is no docs evidence of a self-hostable core product.",
    "evidenceIds": [
      "1password-docs-4",
      "1password-comm-7",
      "1password-comm-8"
    ]
  },
  {
    "productId": "1password",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence pack covers CLI/SDK developer tooling, personal password features, import/export, and community sentiment, but contains no documentation of admin console policies for enforcing app lock, restricting export, or mandating master password strength across an organization. This axis clearly applies to a business password manager, but no supporting evidence is present.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "1Password's docs show passkeys can be created, saved, and used from the browser extension across 'a growing number of websites and apps' and Watchtower flags logins for passkey upgrade, implying sync across whatever platform the extension/app runs on rather than vendor lock-in. However the evidence pack never explicitly confirms native passkey support/sync parity on Linux or Android apps (only browser extension and Apple-ecosystem mentions like Apple Watch/Touch ID), and an older community comment specifically raises concerns about a missing Linux client, leaving cross-platform parity unconfirmed by direct docs. Missing for 10: explicit Linux and Android app passkey documentation, independent hands-on confirmation of parity across all five listed platforms.",
    "evidenceIds": [
      "1password-docs-12",
      "1password-docs-13",
      "1password-docs-14",
      "1password-comm-3"
    ]
  },
  {
    "productId": "1password",
    "storyId": "passkey-storage-signin",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "1Password's own support docs confirm passkey creation, storage, and sign-in on websites/apps directly through 1Password (browser extension and apps), plus Watchtower flagging logins that can upgrade to passkeys, going well beyond just TOTP storage which is also documented separately. Missing for 10: independent hands-on verification of passkey sign-in reliability across many sites and no explicit mobile-app (non-browser) passkey autofill confirmation.",
    "evidenceIds": [
      "1password-docs-12",
      "1password-docs-13",
      "1password-docs-14",
      "1password-docs-20"
    ]
  },
  {
    "productId": "1password",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack item mentions data residency, regional storage options, or the ability to choose where a vault/account's data is physically stored; 1Password's architecture appears to be a single managed cloud service without documented regional selection. Missing for 10: any documentation of region/residency selection, EU/US data center choice, or self-hosted storage location controls.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "privacy-no-training",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence in the pack addresses any policy, setting, or documentation about opting out of or preventing data use for AI model training; the pack covers CLI/SDK/Connect/SSH/passkeys but nothing about AI training data usage or opt-outs.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "privacy-retention-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The pack shows data export/import and an MCP design that avoids returning secrets to agents, but there is no evidence of explicit controls for data retention policies or deletion (e.g., audit-log retention settings, vault/item purge, GDPR-style deletion) tailored to AI-native workflows. missing for 10: retention policy controls, explicit deletion/purge mechanisms for AI-consumed data, documentation tying these to AI agent use.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "privacy-telemetry-optout",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack item addresses telemetry/usage-tracking opt-out settings or privacy controls for AI-native usage; all evidence covers unrelated features like CLI, SSH, SDKs, and password management. This is a fair axis for any product handling sensitive data, but no documentation or community evidence confirms or denies a telemetry opt-out option.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence in the pack references independent third-party security audits, pen-test reports, or cryptographic protocol reviews of 1Password's app or sync protocol (e.g., no mention of the publicly known white paper audits by NCC Group/etc.). All citations cover CLI, SDKs, SSH, passkeys, and general product docs, none addressing audit publication.",
    "evidenceIds": []
  },
  {
    "productId": "1password",
    "storyId": "qr-totp-enrollment",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Docs confirm 1Password stores and generates one-time passwords for two-step verification (docs-20, docs-19/24), which implies TOTP support, but no evidence explicitly describes the QR-code scanning flow for adding a new TOTP account. Missing for 10: explicit documentation or screenshots of QR code scanning to add a new TOTP entry, and independent/hands-on confirmation of the immediate code-generation experience.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-19",
      "1password-docs-24"
    ]
  },
  {
    "productId": "1password",
    "storyId": "self-host-sync-server",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "1Password markets a 'Connect Server' that can be deployed in a company's own infrastructure to access items via REST API (docs-4), which sounds like partial self-hosting, but this is only a caching/access layer in front of 1Password's cloud vaults, not a full self-hosted sync server. Community evidence directly contradicts the idea that secrets can stay entirely within an admin's perimeter: users note 1Password has 'no local vault storage' anymore and ask the vendor to 'continue support for local, non-cloud-based vault files' (comm-7, comm-8), confirming that the cloud remains the source of truth. Missing for 10: any documented on-prem deployment of the full sync/vault backend, migration guide for self-hosted secret storage, or evidence that Connect Server operates without 1Password's cloud.",
    "evidenceIds": [
      "1password-docs-4",
      "1password-comm-7",
      "1password-comm-8"
    ]
  },
  {
    "productId": "1password",
    "storyId": "team-shared-vaults",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack covers 1Password's developer tooling (CLI, SDKs, Connect, SSH agent) and personal features (Watchtower, OTP storage, passkeys) but contains no mention of shared vaults, collections, group/per-member permissions, or admin controls for team sharing of TOTP items. Missing for 10: documentation of shared vaults/collections, per-member access control settings, or admin console screenshots showing granular sharing permissions for TOTP logins.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-18"
    ]
  },
  {
    "productId": "1password",
    "storyId": "token-organization",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "Docs confirm 1Password stores and quickly surfaces one-time passwords (including via Apple Watch) and flags login issues via Watchtower, but the pack provides no evidence of folder/tag/group organization, dedicated search, or service icons for TOTP entries specifically. missing for 10: explicit search functionality, folder/tag/group organization for TOTP items, service icon display for OTP entries, independent hands-on validation of organizing many tokens.",
    "evidenceIds": [
      "1password-docs-20",
      "1password-docs-19",
      "1password-docs-24",
      "1password-docs-18"
    ]
  },
  {
    "productId": "1password",
    "storyId": "watch-codes",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "1Password explicitly documents Apple Watch support for quickly looking up saved information including one-time passwords, letting users read codes without pulling out their phone. This directly matches the story, though evidence is limited to Apple Watch (no mention of other smartwatch platforms like Wear OS) and lacks independent hands-on corroboration. Missing for 10: evidence of Android/Wear OS smartwatch support, independent user reviews confirming the watch OTP experience.",
    "evidenceIds": [
      "1password-docs-19",
      "1password-docs-24",
      "1password-docs-20"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agent-code-retrieval",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence explicitly states 2FAS has no public API for programmatic TOTP retrieval ('Public API: None — local-first by design, no agent-callable endpoint for token generation'), and no CLI is documented anywhere in the pack; OpenAPI probes all 404. This directly rules out agent-driven fetching of TOTP codes via CLI or API.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agent-local-endpoint",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The product's own llms.txt explicitly states 'Public API: None' and no OpenAPI/local endpoint was found; 2FAS is local-first by design with no agent-callable interface for querying codes or secrets programmatically.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agent-vault-provisioning",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No programmatic API exists for creating/updating vault entries or seeding TOTP secrets; the product's own llms.txt explicitly states 'Public API: None' and openapi probes all 404, confirming no agent-callable surface for this workflow.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-agent-docs",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Direct probe confirms a live llms.txt with an explicit 'For AI agents' section, plus modular per-section llms files, llms-full.txt, per-page .md mirrors, and Accept: text/markdown rendering — strong first-party agent-oriented docs infrastructure verified via runtime probes. Missing for 10: no independent/community corroboration of agents actually consuming these docs in practice.",
    "evidenceIds": [
      "2fas-probe-1",
      "2fas-probe-rt-1",
      "2fas-probe-rt-2"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-ai-insights",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a 2FA authenticator/password manager focused on secure credential storage and sync, not a data-analytics or AI-insights product; there is no dataset or usage history it analyzes to generate suggestions. The evidence explicitly confirms it has no public API and is local-first by design, reinforcing that AI-generated insights are outside its product category.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a 2FA authenticator/password manager with no built-in AI assistant feature; delegating tasks to an AI assistant is not a fair axis for this product category. Evidence even confirms 'Public API: None' and no agent-callable endpoints, reinforcing this is out of scope rather than a missing feature.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-headless",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a mobile authenticator/password manager with no CLI, headless mode, or API for CI/automation; the product's own llms.txt explicitly declares 'Public API: None' and is local-first by design, meaning it cannot be run headlessly or scripted in CI.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a password manager/2FA authenticator app, not an AI agent or platform with MCP tool-plugin capability; the product's own docs explicitly state 'Public API: None' and it has no agent/tool-integration surface. Plugging MCP servers into it for tool use is a category error for this product type.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a password/2FA manager, not an agent, so an MCP server axis could plausibly apply to its ecosystem; however evidence explicitly states 'Public API: None' and no OpenAPI/MCP endpoint exists, with probes confirming no API surface for agents to connect to.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "agentic-official-cli",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a mobile/browser 2FA and password-manager app with no evidence of an official CLI; docs explicitly note 'Public API: None' and no CLI tool is mentioned anywhere in the evidence pack.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-public-api",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS explicitly states 'Public API: None' in its own llms.txt, and OpenAPI/swagger probes all return 404, confirming there is no documented public API to drive the product programmatically — it is local-first by design.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a local-first authenticator/password manager with no public API; its own llms.txt explicitly states 'Public API: None' and no agent-callable endpoint for token generation, so there is no mechanism to issue scoped/least-privilege API credentials for an agent.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-sdks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS explicitly declares 'Public API: None' and has no OpenAPI/SDK endpoints; probes confirm no SDK or API surface exists for developers to build against.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "agentic-webhooks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is explicitly local-first with no public API ('Public API: None' per its own llms.txt), and no evidence anywhere mentions webhooks or event subscriptions; this is a password/2FA app, not an event-driven platform.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of an interactive API reference or runnable examples; openapi probe returned 404s across all candidate paths and llms.txt explicitly states 'Public API: None' since 2FAS is local-first with no agent-callable endpoints.",
    "evidenceIds": [
      "2fas-probe-3",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Direct probes for OpenAPI/swagger specs all returned 404, and the product's own llms.txt explicitly states 'Public API: None,' confirming no machine-readable API spec is offered.",
    "evidenceIds": [
      "2fas-probe-3",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a consumer password/2FA manager with no API or developer sandbox concept; there's no test/production data separation to speak of since it's local-first with no public API ('Public API: None'). This story targets developer-platform/agentic products with sandbox environments, which is a category error for a personal auth app.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS explicitly declares 'Public API: None' and has no OpenAPI/swagger endpoints (all probes 404), meaning there is no versioned API at all, let alone a documented deprecation policy.",
    "evidenceIds": [
      "2fas-probe-3",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "app-lock",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack describes 2FAS Pass's tiered security and sync options, and confirms access to the browser extension/autofill must be approved in-app, but nowhere states that the 2FAS Auth or Pass app itself can be locked behind biometrics or a PIN to block access if the phone is borrowed. No docs or community evidence mention an app-lock/biometric-gate feature for the authenticator itself.",
    "evidenceIds": [
      "2fas-docs-4",
      "2fas-docs-19"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "automation-bulk-operations",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "2FAS is a local-first authenticator/password manager with no public API (explicitly declared 'Public API: None'), and no evidence of bulk operations across items (e.g., batch import/export beyond single-file import, bulk edit/delete of tokens or vault entries) that an AI agent could invoke. There's no scripting, CLI, or API surface for programmatic bulk actions.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-docs-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a local-first authenticator/password manager with no public API or event-driven automation surface (llms.txt explicitly declares 'Public API: None'); rule-based automation triggers are outside the scope of what this product category offers.",
    "evidenceIds": [
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a 2FA authenticator/password manager with no workflow/job automation or scheduling engine; recurring job scheduling is outside its product category entirely.",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a 2FA authenticator/password manager, not an automation or workflow tool; there is no concept of automations to version, review, or roll back in this product category.",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "breach-alerting",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of breach monitoring, weak/reused/exposed password detection, or security-posture alerts anywhere in the docs, community reports, or probes; 2FAS's evidence covers sync, tiers, self-hosting, and import/export but nothing about credential health warnings or breach alerts.",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "browser-extension-autofill",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "2FAS's browser extension is documented to autofill TOTP tokens with confirmation via the mobile app ('You don't have to retype anything'), and the 2FAS Pass extension supports autofill for passwords/passkeys confirmed in the vault app, with the free tier confirmed by community reports to include auto-fill. However, evidence is vendor-documented with only partial independent corroboration and no explicit hands-on confirmation of passkey autofill specifically working smoothly in-browser. Missing for 10: independent hands-on validation of passkey autofill UX, more detail on cross-browser support, and confirmation of friction-free flow beyond vendor claims.",
    "evidenceIds": [
      "2fas-docs-3",
      "2fas-docs-19",
      "2fas-comm-2",
      "2fas-docs-6"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "competitor-import",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS docs explicitly list bulk import support from Aegis, Raivo, LastPassAegis, Stratum, and Google Authenticator, directly supporting the power-user portability story. However, the list is limited to a handful of named apps, no evidence of a generic/universal import format (e.g., OTP URI batch, QR export from arbitrary apps), and no independent hands-on verification of the import process working smoothly. Missing for 10: broader import coverage beyond five named apps, independent/community confirmation of successful bulk import, and details on edge cases (e.g., failed imports, partial data loss).",
    "evidenceIds": [
      "2fas-docs-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "desktop-app",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only shows mobile apps (iOS/Android) plus a browser extension, and the extension explicitly requires confirmation via the mobile app (2fas-docs-3, 2fas-docs-19) rather than functioning as an independent desktop client. No native desktop app for code generation or vault access is documented anywhere in the pack.",
    "evidenceIds": [
      "2fas-docs-3",
      "2fas-docs-19",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "device-to-device-transfer",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "2FAS Auth supports iCloud/Google Drive sync and encrypted export/backup files, letting a user restore tokens on a new device by simply enabling sync or importing the backup file, and 2FAS Pass has a dedicated recovery flow for restoring the vault on a different device via iCloud/Google Drive backups. missing for 10: a documented single-tap 'migrate to new phone' wizard UI and independent hands-on confirmation of the transfer experience.",
    "evidenceIds": [
      "2fas-docs-2",
      "2fas-docs-9",
      "2fas-docs-17",
      "2fas-docs-8",
      "2fas-docs-18"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "e2ee-backup",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "2FAS documents that backups/sync can be encrypted with a user password (docs-9, docs-17, docs-18) and that vault storage location is user-controlled, but the encryption is presented as optional ('we encourage you to do that') rather than guaranteed end-to-end by default, and there is no detailed technical whitepaper describing key derivation, zero-knowledge architecture, or threat model. Community discussion (2fas-comm-1) explicitly questions whether backups to iCloud/WebDAV truly avoid vendor/server trust, further undercutting a strong E2E claim. missing for 10: a dedicated cryptographic design document (algorithms, key derivation, zero-knowledge proof), confirmation that encryption is mandatory/default rather than opt-in, and independent security audit corroboration.",
    "evidenceIds": [
      "2fas-docs-9",
      "2fas-docs-17",
      "2fas-docs-18",
      "2fas-docs-5",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "lost-phone-recovery",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "2FAS documents multi-device sync via iCloud/Google Drive/encrypted export files for the Auth app, plus a dedicated recovery page explaining how to restore or run the Pass Vault on a new device using the cloud-synced encrypted vault file, and supports importing from other authenticator apps for migration scenarios. This directly addresses losing a phone and restoring tokens elsewhere, though community commentary raises trust questions about relying on third-party cloud storage rather than disputing that recovery works. Missing for 10: independent hands-on verification of the actual recovery flow succeeding, and clearer detail on recovery when no cloud sync was enabled beforehand.",
    "evidenceIds": [
      "2fas-docs-2",
      "2fas-docs-8",
      "2fas-docs-18",
      "2fas-docs-9",
      "2fas-docs-1",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "multi-device-sync",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS documents syncing tokens across devices via iCloud/Google Drive and lists 'Multi-device sync (encrypted)' as a feature, and computer access is possible through a browser extension that confirms via the mobile app. However, this cross-device access relies on manual confirmation from the phone rather than tokens being independently and automatically available on a tablet/computer at all times, and multi-device sync appears gated behind a paid tier for the Pass product. Missing for 10: evidence of true simultaneous, always-available token access across phone/tablet/computer without per-use phone confirmation, and confirmation that Auth (not just Pass) multi-device sync is free and automatic.",
    "evidenceIds": [
      "2fas-docs-2",
      "2fas-docs-3",
      "2fas-docs-17",
      "2fas-comm-2"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence in the pack addresses Steam Guard tokens, HOTP counter-based codes, or custom period/digit-length configuration for 2FAS Auth — the docs only mention generic 'token customization' for groups/badges/icons/labels, which is unrelated to non-standard token algorithms.",
    "evidenceIds": [
      "2fas-docs-10",
      "2fas-docs-16"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "offline-code-generation",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "2FAS Auth is described as open-source, local-first with no public API for token generation, and pricing docs confirm it's free with no telemetry, consistent with fully offline TOTP generation without vendor account requirement. Community evidence questions cloud-sync/backup security but this concerns 2FAS Pass (password manager), not the core Auth TOTP generation flow. missing for 10: independent hands-on confirmation that TOTP codes generate with device fully offline (airplane mode test), and explicit documentation stating no account/signup is ever required.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-rt-2",
      "2fas-docs-9"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "open-format-export",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS explicitly supports imports from other apps (Aegis, Raivo, Google Authenticator, etc.) and offers 2FAS export files for backup/sync, with optional password-based encryption of backups. However, evidence doesn't confirm the export format is an open/readable standard (e.g., plaintext otpauth URIs or documented JSON schema) rather than a proprietary encrypted blob, and there's no explicit statement about exporting TO other apps' formats for migration away from 2FAS. missing for 10: documented open/standard export format spec, explicit 'export to other apps' migration path, independent confirmation the export file is human-readable/portable.",
    "evidenceIds": [
      "2fas-docs-1",
      "2fas-docs-2",
      "2fas-docs-9"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "open-source-clients",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "2FAS explicitly markets itself as open-source and points to a public GitHub repo for code review, including for the browser extension backend ('delve deep into the intricacies'), and invites community contribution/code review. The core apps (2FAS Auth, described as 'Free, Open-source 2FA Authenticator App') are confirmed open-source via probe data. Missing for 10: no independent security audit report or third-party code-review corroboration is cited, and evidence doesn't explicitly confirm the mobile app repos (vs. just extension) are inspectable.",
    "evidenceIds": [
      "2fas-docs-6",
      "2fas-docs-7",
      "2fas-docs-13",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "openness-api-parity",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS's own llms.txt explicitly declares 'Public API: None' and probes confirm no OpenAPI/swagger spec exists at any candidate path, meaning there is no API surface at all through which a user could replicate UI actions.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-3"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "openness-full-export",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS explicitly supports exporting/backing up data (encrypted export files, self-host freedom, import/export in free tier) and even imports from competitor formats, showing some portability. However, there's no evidence the export format itself is documented as an open/standard schema (e.g., JSON spec or standard otpauth migration format), and the backup is typically encrypted for 2FAS's own re-import rather than a documented open format for third-party tools. missing for 10: explicit open/standard export format spec, independent confirmation the exported file is usable outside 2FAS ecosystem, and details on the exact format encoding.",
    "evidenceIds": [
      "2fas-docs-2",
      "2fas-docs-9",
      "2fas-docs-14",
      "2fas-docs-5",
      "2fas-comm-2",
      "2fas-docs-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "openness-open-license",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "2FAS explicitly points to its GitHub repositories for both the auth app and browser extension, describing itself as open-source, and the probe confirms 'open-source two-factor authentication' positioning with 'Freedom to self-host your data.' missing for 10: explicit license name (e.g., MIT/GPL) is not stated in evidence, and no independent audit confirming license terms.",
    "evidenceIds": [
      "2fas-docs-6",
      "2fas-docs-7",
      "2fas-docs-13",
      "2fas-docs-14",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "openness-self-host",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS explicitly markets 'Freedom to self-host your data' and lets users choose their own cloud/WebDAV/external drive storage for vaults, and the core apps are open-source on GitHub for self-hosting/auditing. However, this is self-hosting of data/storage, not the full core service (no self-hostable server/backend, no API for self-managed infrastructure), and community commentary questions how this differs meaningfully from server-reliant competitors. Missing for 10: a self-hostable backend/server component, documentation of running the whole product on own infrastructure, and independent confirmation that self-hosted storage removes all vendor dependency.",
    "evidenceIds": [
      "2fas-docs-5",
      "2fas-docs-14",
      "2fas-docs-6",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a consumer-focused authenticator/password manager with no evidence of centralized org policy management, admin dashboards, enforced app-lock policies, export restrictions, or credential strength mandates across users; it is explicitly local-first with no public API for such control (2fas-probe-rt-1). No IT-admin console or MDM/policy feature is documented anywhere in the pack.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-docs-14",
      "2fas-docs-9"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence pack describes 2FAS Auth's 2FA token sync and 2FAS Pass's password vault sync (iCloud, Google Drive, WebDAV, browser extension) but contains no mention of 'passkey' or WebAuthn/FIDO2 credential support or storage anywhere. Since passkey sync is a distinct capability from OTP tokens or password items, there's no evidence this product delivers it.",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "passkey-storage-signin",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is a TOTP authenticator (2FAS Auth) and separately a password manager (2FAS Pass); evidence covers token/2FA codes, vault items, and password autofill, but nothing describes passkey (WebAuthn/FIDO2) storage or passkey-based sign-in to websites/apps.",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "2fas",
    "storyId": "privacy-data-residency",
    "verdict": "partial",
    "quality": 7,
    "confidence": "medium",
    "rationale": "2FAS is local-first: users choose to keep data on-device, in their own iCloud/Google Drive, WebDAV, or fully self-hosted, giving strong control over storage location (2fas-docs-5, 2fas-docs-14, 2fas-docs-17). This satisfies the spirit of data residency choice, though it's not a formal 'select region/datacenter' feature and relies on user-configured third-party clouds rather than a first-party regional hosting option. Missing for 10: explicit region/datacenter selection controls, independent verification of self-host setup beyond marketing pages.",
    "evidenceIds": [
      "2fas-docs-5",
      "2fas-docs-14",
      "2fas-docs-17",
      "2fas-docs-9",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "privacy-no-training",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "2FAS is local-first with explicit 'no telemetry' claims and no public API for data collection (2fas-probe-rt-1, 2fas-probe-rt-2), which implies user data isn't centrally harvested and thus couldn't feed AI training pipelines. However, there is no explicit statement addressing AI model training or an opt-out policy specifically. Missing for 10: explicit AI-training data policy/opt-out statement, independent confirmation that no data is ever sent to third-party AI services.",
    "evidenceIds": [
      "2fas-probe-rt-1",
      "2fas-probe-rt-2"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "2FAS gives users explicit control over where data is stored (own cloud, external drive, self-hosting) and confirms no telemetry/tracking, which supports retention control (2fas-docs-5, 2fas-docs-14, 2fas-probe-rt-2). However there is no explicit documentation of a deletion/erasure workflow, data-retention policy, or account-deletion mechanism beyond implied local file control. Missing for 10: explicit data deletion/right-to-erasure documentation, retention period policy, and independent confirmation that deleting local/cloud copies fully removes data.",
    "evidenceIds": [
      "2fas-docs-5",
      "2fas-docs-14",
      "2fas-docs-9",
      "2fas-probe-rt-2"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "privacy-telemetry-optout",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "2FAS explicitly states in its machine-readable pricing/docs that 2FAS Auth has 'no advertising, no telemetry,' meaning tracking is absent by design rather than requiring opt-out, and the product is positioned as local-first/open-source, reinforcing a privacy-first posture. Missing for 10: no explicit dedicated privacy-settings toggle documentation, and no independent audit confirming zero telemetry across 2FAS Pass as well as Auth.",
    "evidenceIds": [
      "2fas-probe-rt-2",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence shows only open-source code availability claims and general transparency messaging, with no mention of independent third-party security audits of the app or its sync protocol; community discussion even questions the trust model of cloud-based sync without referencing any audit report.",
    "evidenceIds": [
      "2fas-docs-6",
      "2fas-docs-7",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "qr-totp-enrollment",
    "verdict": "partial",
    "quality": 5,
    "confidence": "low",
    "rationale": "2FAS Auth is a well-known TOTP app and docs reference connecting accounts via video tutorials, but the evidence pack lacks any direct documentation or hands-on confirmation of the core QR-scan-to-code-generation flow. missing for 10: explicit documentation/screenshots of QR scanning UX, confirmation that codes generate immediately post-scan, independent/hands-on corroboration of the onboarding flow.",
    "evidenceIds": [
      "2fas-docs-12",
      "2fas-probe-rt-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "self-host-sync-server",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "2FAS advertises 'freedom to self-host your data' and lets users choose where encrypted vault/token data lives (own cloud, WebDAV, external drive) rather than relying on 2FAS-hosted storage, which partially satisfies the perimeter-control need. However there is no evidence of an actual downloadable/self-hostable 'sync server' component (e.g. a Vaultwarden-style server binary) — it's more bring-your-own-storage for encrypted files/backups, and community commentary explicitly questions whether this differs meaningfully from relying on third-party server infrastructure. Missing for 10: a dedicated self-hosted sync-server artifact/deployment docs, and independent confirmation that all sync traffic stays fully within admin-controlled infra.",
    "evidenceIds": [
      "2fas-docs-5",
      "2fas-docs-14",
      "2fas-comm-1"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "team-shared-vaults",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "2FAS is positioned as a personal, local-first authenticator/password manager with individual sync (iCloud/Google Drive/self-host) and multi-device sync for a single user, not team/organization features. No evidence of shared vaults, collections, or per-member access control for an IT-admin-managed team; the HN community discussion even questions its single-user 'local-only' security model, but nothing addresses team sharing at all.",
    "evidenceIds": [
      "2fas-docs-2",
      "2fas-docs-17",
      "2fas-comm-1",
      "2fas-comm-2"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "token-organization",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Docs confirm token customization with 'full control over groups, badges, icons, and labels' and Apple Watch access, directly supporting organization by groups/icons for quick access, but there is no mention of search functionality within the token list, no detail on folder/group UX depth, and no independent hands-on account of managing 'dozens of tokens' at scale. missing for 10: explicit search feature evidence, hands-on/independent validation of organization UX at scale, deeper detail on folder vs group implementation.",
    "evidenceIds": [
      "2fas-docs-10",
      "2fas-docs-16",
      "2fas-docs-11",
      "2fas-docs-15"
    ]
  },
  {
    "productId": "2fas",
    "storyId": "watch-codes",
    "verdict": "partial",
    "quality": 5,
    "confidence": "low",
    "rationale": "2FAS explicitly markets 'Apple Watch — Improved convenience and accessibility' as a feature, indicating watch support exists, but there's no detail on what functionality is available on the watch (e.g., whether codes are viewable standalone or require phone proximity) and no independent/hands-on confirmation of the experience. missing for 10: details on watch app functionality/UX, confirmation codes can be read without unlocking phone, independent hands-on review of the watch experience.",
    "evidenceIds": [
      "2fas-docs-11",
      "2fas-docs-15"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agent-code-retrieval",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a consumer authenticator app; there is no documented CLI/API for a user or agent to programmatically fetch their own current TOTP code, and Twilio's docs confirm the Authy API is deprecated and closed to new customers with no successor for this use case. Community evidence further shows Authy intentionally blocks exporting secrets/codes, requiring hacky workarounds (deprecated Chrome extension, debug-mode Electron hacks) rather than any supported programmatic access.",
    "evidenceIds": [
      "authy-probe-rt-1",
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-13",
      "authy-comm-14"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agent-local-endpoint",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence Authy offers any local programmatic endpoint for agents to query codes/secrets; its API is closed to new customers and deprecated, and community reports describe the vault as deliberately hard to export via any means other than hacky manual extraction.",
    "evidenceIds": [
      "authy-probe-rt-1",
      "authy-comm-13",
      "authy-comm-14",
      "authy-comm-4"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agent-vault-provisioning",
    "verdict": "disputed",
    "quality": 2,
    "confidence": "medium",
    "rationale": "Docs mention an SDK for 'the Authy API' to integrate 2FA, but Twilio's own docs page (probe) states the Authy API is closed to new customers and being deprecated with no new integrations, and multiple community reports confirm there is no supported way to programmatically seed, export, or update vault entries — users describe extreme difficulty or hacky workarounds to even extract secrets. This directly contradicts any claim of a documented programmatic surface for agent-driven vault creation/updates. Missing for 10: any current API/SDK for creating or updating TOTP vault entries, official export/import endpoints, and first-party agent integration examples.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-docs-13",
      "authy-probe-rt-1",
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-14"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agentic-agent-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-ai-insights",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA/authenticator product; AI-generated insights or suggestions from user data is a category mismatch, not something a 2FA app category would ship.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA/authentication app; delegating tasks to a built-in AI assistant is a wrong-axis question for this product category, with no evidence it ships any AI assistant feature.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-headless",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA/authenticator app, not an agentic AI product or platform with a tool-use ecosystem; plugging MCP servers into it for tool use is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-official-cli",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-public-api",
    "verdict": "disputed",
    "quality": 2,
    "confidence": "medium",
    "rationale": "Twilio's own docs describe an SDK/API for integrating Authy (authy-docs-1, authy-docs-13), but a direct probe of the same page shows the Authy API is deprecated and 'closed to new customers' with 'no programmatic surface remains open to new integrations' (authy-probe-rt-1), meaning an AI-native user cannot actually drive Authy via a documented public API today. Missing for 10: an open, actively maintained public API for new integrations, migration path documentation usable by AI agents, and independent confirmation of working programmatic access.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-docs-13",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "agentic-sdks",
    "verdict": "disputed",
    "quality": 3,
    "confidence": "medium",
    "rationale": "Twilio's docs claim official SDKs for common web languages to integrate Authy 2FA (authy-docs-1, authy-docs-13), but the same docs page also states the Authy API is closed to new customers and being deprecated in favor of Verify v2, meaning no new AI-native integration can actually be built against it. Missing for 10: evidence of an actively maintained, open-to-new-customers SDK, and any agentic/AI-specific tooling or examples.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-docs-13",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "agentic-webhooks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any webhook subscription capability in Authy's docs or community reports; the product's API is deprecated with no new programmatic integrations mentioned. This is a fair axis for an authentication/API platform, but no support is documented.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "No evidence of an interactive API reference with runnable examples for Authy; docs pack only describes SDKs and app features, and the Authy API itself is now closed/deprecated in favor of Verify, with no mention of interactive docs or runnable code samples.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-docs-13",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only mentions SDKs and API docs (Verify/Authy), with no mention of a downloadable OpenAPI/Swagger spec or other machine-readable API definition; the Authy API is also noted as deprecated with no new integrations possible.",
    "evidenceIds": [
      "authy-docs-1",
      "authy-docs-13",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a consumer 2FA app/service, not an AI-native developer tool with sandbox/test environments for agentic testing; no evidence pack content addresses sandbox vs production environments for AI agent testing, making this axis a category error for this product.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "api-versioning-policy",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Twilio's docs do carry an explicit deprecation notice for the Authy API, stating it is closed to new customers and pointing to a migration guide toward Verify v2, which is a documented deprecation policy of sorts. However there is no evidence of a broader versioning scheme (e.g., v1/v2 semantics, changelogs, sunset timelines) beyond this one-time 'this API is dying' notice, and it applies to abandonment rather than an ongoing API lifecycle policy. missing for 10: evidence of a formal API versioning scheme, sunset/timeline commitments, changelog practices, and confirmation that Verify (the successor) itself has a documented deprecation policy.",
    "evidenceIds": [
      "authy-docs-11",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "app-lock",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Twilio's official docs claim TouchID, PIN, and password protection guarding access to 2FA tokens, and a community user independently corroborates using Face ID to lock the entire app on their phone. This directly matches the story of biometric/PIN app-lock preventing exposure on a borrowed phone. Missing for 10: more independent hands-on verification of PIN-specific lock behavior and no detail on lockout/failure edge cases.",
    "evidenceIds": [
      "authy-docs-6",
      "authy-comm-12"
    ]
  },
  {
    "productId": "authy",
    "storyId": "automation-bulk-operations",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA authenticator app/service, not an automation or workflow-rules platform; defining event-triggered rules is outside its product category and there is no evidence of such a feature.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA/authenticator app; scheduling recurring jobs or workflows is not a relevant capability for this product category.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a 2FA/authentication app, not an automation-building tool; versioning, reviewing, and rolling back 'automations' is not a concept that applies to this product category.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "breach-alerting",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence Authy monitors for breached services, weak/reused/exposed credentials, or provides any security-posture alerts; evidence only covers 2FA sync, backup, device management, and separate breach news about Authy itself (not a feature it offers users).",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "browser-extension-autofill",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence pack shows no current Authy browser extension for autofilling TOTP or passkeys; the only extension mentioned is a deprecated Chrome extension used via hacky workarounds to extract keys, not autofill. Authy's own product is a mobile/desktop authenticator app, and passkey support referenced is for Twilio Verify (a separate API product), not the Authy app/extension.",
    "evidenceIds": [
      "authy-comm-13",
      "authy-comm-14",
      "authy-docs-2"
    ]
  },
  {
    "productId": "authy",
    "storyId": "competitor-import",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence shows Authy lets users add individual accounts via QR code capture (authy-docs-12) but nothing indicates a bulk import feature that pulls multiple existing tokens/accounts from other authenticator apps at once. Community evidence instead focuses on Authy making it hard to export data out, which is the opposite direction from what the story asks about.",
    "evidenceIds": [
      "authy-docs-12",
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10"
    ]
  },
  {
    "productId": "authy",
    "storyId": "desktop-app",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Twilio's docs list Authy as available on macOS, Windows, and Linux, suggesting first-class desktop apps, but hands-on community reports concretely contradict this, stating Authy is 'EOL'ing desktop apps' with 'near immediate deprecation' and no export path, leaving the desktop surface unreliable for power users. Missing for 10: no evidence of continued desktop app support with vault/code access, no independent confirmation the desktop client remains functional or maintained post-EOL announcement.",
    "evidenceIds": [
      "authy-docs-16",
      "authy-comm-10",
      "authy-comm-18"
    ]
  },
  {
    "productId": "authy",
    "storyId": "device-to-device-transfer",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Authy's own docs describe encrypted cloud backup, multi-device sync, and 'add new device with SMS/voice/existing device approval' as the guided path to move 2FA tokens to a new phone, which directly matches this story (authy-docs-3,4,5,10). Community comments about difficulty exporting data are about moving to a *different app*, not the in-ecosystem new-phone transfer, so they don't contradict this specific flow. Missing for 10: independent/hands-on confirmation that the new-phone restore process itself is smooth and single-step (most community friction reports concern cross-app export, not device-to-device transfer).",
    "evidenceIds": [
      "authy-docs-3",
      "authy-docs-4",
      "authy-docs-5",
      "authy-docs-10",
      "authy-comm-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "e2ee-backup",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Authy's marketing page states backups are encrypted and 'only decrypt on the devices using a password only you know' (authy-docs-5), implying a vendor-can't-decrypt design, but there is no technical documentation of the encryption algorithm, key derivation, or threat model, and no independent audit confirming the vendor truly never holds the key. Community reports focus on account-takeover via device-add (authy-comm-15) and painful data export (authy-comm-13/14), not on breaking the underlying backup encryption, so this doesn't rise to a concrete dispute of the encryption claim itself. Missing for 10: a detailed whitepaper/spec of the E2E encryption scheme, key management details, and independent security audit or crypto review corroborating the zero-knowledge claim.",
    "evidenceIds": [
      "authy-docs-5",
      "authy-comm-13",
      "authy-comm-14",
      "authy-comm-15"
    ]
  },
  {
    "productId": "authy",
    "storyId": "lost-phone-recovery",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Authy's official docs describe an encrypted backup feature that restores 2FA tokens to a new device using a user-known password, plus multi-device sync and device management (authy-docs-3,4,5,8,10), and a community user confirms this recovery path works in practice after phone loss/SIM replacement (authy-comm-19). Some community friction exists around exporting data to competing apps, but that's a separate migration-away concern, not evidence the phone-loss recovery path itself fails. Missing for 10: a detailed first-party step-by-step restore walkthrough, and broader independent corroboration beyond a single community anecdote.",
    "evidenceIds": [
      "authy-docs-3",
      "authy-docs-4",
      "authy-docs-5",
      "authy-docs-8",
      "authy-docs-10",
      "authy-comm-19"
    ]
  },
  {
    "productId": "authy",
    "storyId": "multi-device-sync",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Docs and community confirm sync across phone/tablet (and even Apple Watch) works well and is a headline feature (authy-docs-3, authy-docs-4, authy-docs-16, authy-comm-1), but the 'computer' part of the story is directly contradicted: community reports Authy EOL'd its desktop apps, breaking the phone/tablet/computer parity the docs still describe (authy-comm-10, authy-comm-18). Missing for 10: confirmation that desktop/computer sync still functions today, and resolution of the desktop deprecation vs docs claim.",
    "evidenceIds": [
      "authy-docs-3",
      "authy-docs-4",
      "authy-docs-16",
      "authy-comm-1",
      "authy-comm-10",
      "authy-comm-18"
    ]
  },
  {
    "productId": "authy",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence anywhere in the pack mentions Steam Guard support, HOTP counter-based tokens, or custom period/digit configurations; documentation only references standard TOTP and QR-code capture from mainstream services. Absence of evidence for this applicable power-user axis yields 'none'.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "offline-code-generation",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Authy's own docs claim codes can be viewed without internet ('access secured websites without internet access on your phone'), but the product fundamentally requires creating a Twilio/Authy account tied to a phone number before any TOTP codes can be generated or viewed, and codes are further gated behind an app password — directly contradicting the 'no vendor account required' part of the story. Community evidence confirms this account-centric architecture (phone-number-as-username, multi-device sync tied to account, extraction of underlying seeds required hacky workarounds via a deprecated debug mode rather than a supported offline export).",
    "evidenceIds": [
      "authy-docs-7",
      "authy-comm-1",
      "authy-comm-6",
      "authy-comm-13",
      "authy-comm-14",
      "authy-comm-16"
    ]
  },
  {
    "productId": "authy",
    "storyId": "open-format-export",
    "verdict": "disputed",
    "quality": 2,
    "confidence": "high",
    "rationale": "Authy provides no official export feature for TOTP secrets, and community reports (authy-comm-3, authy-comm-4, authy-comm-10, authy-comm-18) confirm the app deliberately blocks migration/export, with users resorting to hacky workarounds like extracting keys via a deprecated Chrome extension debug mode (authy-comm-13, authy-comm-14). Docs never claim an export feature exists — only backup/sync within Authy's own ecosystem (authy-docs-5, authy-docs-3). missing for 10: any documented open/standard export format, first-party export tool, official migration path preserving secrets, and evidence contradicting the well-documented lock-in behavior.",
    "evidenceIds": [
      "authy-docs-5",
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10",
      "authy-comm-13",
      "authy-comm-14",
      "authy-comm-18"
    ]
  },
  {
    "productId": "authy",
    "storyId": "open-source-clients",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "There is no evidence Authy's client apps are open source; evidence instead shows closed, proprietary apps with deliberately obstructed export/migration paths and hacky reverse-engineering required to extract seeds. This directly contradicts the premise of community-reviewable open-source code handling seeds.",
    "evidenceIds": [
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10",
      "authy-comm-13",
      "authy-comm-14"
    ]
  },
  {
    "productId": "authy",
    "storyId": "openness-api-parity",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy's API (the Twilio Authy API) is explicitly deprecated and closed to new customers per Twilio's own docs, and community reports confirm there is no way to export/manage 2FA data programmatically outside the mobile/desktop UI—users describe hacky workarounds just to extract seeds. There is no evidence of a supported API that mirrors the app's UI capabilities (device management, backup, sync, disabling installs, etc.).",
    "evidenceIds": [
      "authy-probe-rt-1",
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10",
      "authy-comm-14"
    ]
  },
  {
    "productId": "authy",
    "storyId": "openness-full-export",
    "verdict": "disputed",
    "quality": 2,
    "confidence": "medium",
    "rationale": "Authy provides no official open-format export tool; community reports (authy-comm-3, authy-comm-4, authy-comm-10, authy-comm-18) describe deliberately obstructed migration, requiring hacky Electron debug-mode QR dumps (authy-comm-14) rather than any documented export feature, directly contradicting any implicit claim of open portability. missing for 10: any first-party documentation of a data export feature or open format, evidence of a supported 'leave the platform' workflow, and confirmation that TOTP seeds/secrets can be retrieved without workarounds.",
    "evidenceIds": [
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10",
      "authy-comm-14",
      "authy-comm-18",
      "authy-docs-5"
    ]
  },
  {
    "productId": "authy",
    "storyId": "openness-open-license",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "openness-self-host",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy's evidence pack shows only consumer-facing features (per-device PIN/TouchID lock, backup password, device management) with no mention of any organization/admin console, centralized policy enforcement, or IT-admin controls across a team of users. The product is also being deprecated in favor of Verify, with no admin management surface described anywhere.",
    "evidenceIds": [
      "authy-docs-6",
      "authy-docs-8",
      "authy-docs-9",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Authy's own docs describe syncing TOTP/2FA tokens across mobile/tablet devices (authy-docs-3, authy-docs-4), not passkeys; the only 'Passkeys' mention is in Twilio Verify API docs, which is a separate developer verification service, not evidence Authy itself stores or syncs WebAuthn passkeys across iOS/Android/Windows/Linux/browsers. No evidence shows Authy functioning as a cross-platform passkey manager.",
    "evidenceIds": [
      "authy-docs-2",
      "authy-docs-3",
      "authy-docs-4",
      "authy-docs-16"
    ]
  },
  {
    "productId": "authy",
    "storyId": "passkey-storage-signin",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only shows Twilio's separate Verify API service listing 'Passkeys' as one of many verification factors developers can integrate (authy-docs-2), not that the Authy consumer app itself stores user passkeys or lets users sign into websites/apps with them. All Authy app feature docs (docs-3 through docs-12) describe only TOTP/2FA sync, backups, and device management — no passkey storage or autofill capability is mentioned, and community evidence never discusses passkey sign-in via Authy.",
    "evidenceIds": [
      "authy-docs-2",
      "authy-docs-3",
      "authy-docs-6",
      "authy-docs-12"
    ]
  },
  {
    "productId": "authy",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only shows generic Push and Silent Device Approval support (authy-docs-2, authy-docs-15) with no mention of number matching, location context, or admin-enforced MFA policy controls; the Authy API itself is also noted as deprecated for new integrations (authy-probe-rt-1). Missing for 10: any documentation of number matching, location-based risk signals, or admin policy enforcement for push sign-in.",
    "evidenceIds": [
      "authy-docs-2",
      "authy-docs-15",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "authy",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "privacy-no-training",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "privacy-retention-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No documentation shows Authy giving users control over data retention/export/deletion; instead multiple independent reports describe Twilio deliberately blocking data export ('no export option', 'extremely difficult to export your data') and forcing convoluted workarounds to extract keys, the opposite of user-controlled retention/deletion.",
    "evidenceIds": [
      "authy-comm-3",
      "authy-comm-4",
      "authy-comm-10",
      "authy-comm-13",
      "authy-comm-14",
      "authy-comm-18"
    ]
  },
  {
    "productId": "authy",
    "storyId": "privacy-telemetry-optout",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence pack contains no vendor claim of independent third-party security audits of the app or its sync protocol; documentation focuses on feature descriptions (SDKs, sync, backup) with no audit reports or security whitepapers cited. Community evidence discusses a data breach and a slow-to-fix vulnerability, but these do not substitute for published audit evidence and there's no vendor claim to dispute.",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "qr-totp-enrollment",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Authy's own product page states it can capture 2FA QR codes from major providers and lists TOTP as a supported authentication method, directly matching the scan-and-generate story, and community comments confirm ongoing everyday use of the app for this purpose. Missing for 10: a first-person hands-on account of the exact scan-to-code flow and more detailed onboarding documentation beyond the marketing feature list.",
    "evidenceIds": [
      "authy-docs-12",
      "authy-docs-14",
      "authy-comm-1",
      "authy-comm-19"
    ]
  },
  {
    "productId": "authy",
    "storyId": "self-host-sync-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "authy",
    "storyId": "team-shared-vaults",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Authy is a personal authenticator app with no evidence of shared vaults, collections, or per-member access control for team/admin management; evidence only covers individual multi-device sync and backup features. Community evidence even highlights difficulty exporting/sharing data at all, reinforcing the lack of team-sharing capability.",
    "evidenceIds": [
      "authy-docs-3",
      "authy-docs-5",
      "authy-comm-3",
      "authy-comm-4"
    ]
  },
  {
    "productId": "authy",
    "storyId": "token-organization",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence shows only basic token/QR capture (service icons implied) with no mention of search or folder/group organization; a community user explicitly complains 'can't we please have alphabetization?' indicating the app lacks even simple sorting, let alone search/folders for power users managing dozens of tokens.",
    "evidenceIds": [
      "authy-docs-12",
      "authy-comm-11"
    ]
  },
  {
    "productId": "authy",
    "storyId": "watch-codes",
    "verdict": "partial",
    "quality": 5,
    "confidence": "low",
    "rationale": "Authy's own marketing page explicitly claims support on 'your phone, tablet, even your Apple Watch,' which directly matches the smartwatch-reading story, but this is a single first-party claim with no independent or hands-on confirmation of watch functionality (e.g., no community mention of using the watch app), and the API deprecation notice signals the product line is winding down. Missing for 10: independent/hands-on verification of the Apple Watch experience, detail on Wear OS or other smartwatch support, and confirmation the feature is still maintained post-deprecation.",
    "evidenceIds": [
      "authy-docs-4",
      "authy-docs-3",
      "authy-probe-rt-1"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agent-code-retrieval",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden's integrated authenticator generates TOTP codes (bitwarden-docs-1) and the CLI is documented as a full vault-management tool suitable for automated workflows via personal API key (bitwarden-docs-7, bitwarden-docs-9); runtime probes confirm 'bw serve' exposes a local REST Vault Management API and an official MCP server completes a full handshake, both surfaces an agent could use to fetch TOTP codes programmatically (bitwarden-probe-rt-1, bitwarden-probe-rt-2). Hands-on community evidence independently corroborates that 'bw list' actually returns current TOTP codes in plaintext, confirming the CLI does return live TOTP data (bitwarden-comm-13). Missing for 10: explicit documentation naming a dedicated 'get totp' command/API endpoint and a clean (non-complaint) hands-on workflow example.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-7",
      "bitwarden-docs-9",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agent-local-endpoint",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden's CLI supports a documented `bw serve` mode exposing the vault as a local RESTful API, and Bitwarden ships an official MCP server (bitwarden/mcp-server) that completed a live stdio handshake, both giving agents programmatic access to vault items and TOTP codes without screen-scraping. missing for 10: no independent hands-on validation of `bw serve` specifically for TOTP retrieval by an agent, and no broader third-party corroboration beyond the vendor-run probes.",
    "evidenceIds": [
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2",
      "bitwarden-probe-3",
      "bitwarden-docs-7"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agent-vault-provisioning",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Bitwarden documents multiple programmatic surfaces for vault management — the fully-featured CLI (which supports create/edit item operations and a `bw serve` mode exposing a local REST API for TOTP/items), a personal API key explicitly recommended for 'automated workflows' and 'external applications,' and an official first-party MCP server that completed a live stdio handshake, giving agents a documented path to create and update vault entries including TOTP secrets. Missing for 10: an explicit doc/code example showing the exact CLI/API call syntax for adding a TOTP field to a new item, and independent (non-vendor) confirmation that an agent successfully created/updated entries end-to-end via these surfaces.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-9",
      "bitwarden-probe-4",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-agent-docs",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Bitwarden serves a live llms.txt at bitwarden.com/llms.txt (HTTP 200) with structured content, and help pages ship real per-page markdown mirrors (e.g., cli.md) confirming genuine agent-oriented documentation rather than a stub. This is directly confirmed by runtime probes, not just claims. Missing for 10: no independent third-party corroboration of an agent actually consuming these docs end-to-end in a workflow.",
    "evidenceIds": [
      "bitwarden-probe-1",
      "bitwarden-probe-rt-3"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-ai-insights",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Bitwarden is a password/secrets manager; there is no evidence of any AI-generated insights or suggestions derived from the user's vault data (e.g., no AI-driven analysis, summarization, or recommendations beyond static, non-AI vault health reports). The MCP server and CLI enable agents to query vault data but do not themselves generate AI insights within the product.",
    "evidenceIds": [
      "bitwarden-docs-11",
      "bitwarden-docs-17",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden offers CLI/API/MCP server access that agents could use, but there is no evidence of a mechanism for setting up autonomous, scheduled, or background-running automations (e.g., triggers, workflows, cron-like jobs) — it only provides interfaces for on-demand vault access. missing for 10: any documented scheduling/trigger/workflow automation feature, evidence of background/autonomous execution, or vendor claims of persistent automation setup.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-9",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-builtin-assistant",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence shows Bitwarden offers an MCP server and CLI so external AI agents can query the vault, but there is no evidence of a built-in AI assistant inside the Bitwarden product that a user can delegate tasks to.",
    "evidenceIds": [
      "bitwarden-probe-3",
      "bitwarden-probe-rt-2",
      "bitwarden-docs-7"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-headless",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden ships an official CLI with API-key authentication explicitly documented as suitable for automated workflows/CI, plus a Public API for org automation and a headless 'bw serve' mode confirmed at runtime. missing for 10: no CI-specific tutorial/example pipeline (e.g., GitHub Actions) in evidence, and one community report notes CLI 'bw list' unexpectedly dumping plaintext secrets, a minor safety caveat for automation use.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-9",
      "bitwarden-docs-8",
      "bitwarden-probe-rt-1",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Bitwarden is a password/secrets manager, not an agent or orchestrator platform; the evidence shows it ships an official MCP *server* (bitwarden/mcp-server) so other agents can call its vault tools, not that Bitwarden itself acts as an MCP client that plugs in and consumes other servers' tools. Consuming external MCP tool servers is not a capability class this product category would offer, so the axis is a category mismatch here rather than a missing feature.",
    "evidenceIds": [
      "bitwarden-probe-3",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-mcp-server",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Bitwarden ships a first-party, GPL-3.0 MCP server (bitwarden/mcp-server) published to npm, and a runtime probe confirms it completes a full stdio handshake, showing it works as documented rather than just being an announcement. Missing for 10: independent third-party review of the MCP server's tool set/security beyond the vendor probe.",
    "evidenceIds": [
      "bitwarden-probe-3",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-nl-commands",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "Bitwarden ships an official MCP server (bitwarden/mcp-server) that completed a live stdio handshake, letting AI agents/assistants issue natural-language commands to manage the vault, backed by a full-featured CLI and llms.txt for AI-friendly docs. Missing for 10: no independent hands-on demonstration of a natural-language command actually retrieving/creating vault items via the MCP server, and community feedback flags CLI output risks (e.g., plaintext dumps) that complicate safe agentic use.",
    "evidenceIds": [
      "bitwarden-probe-3",
      "bitwarden-probe-rt-2",
      "bitwarden-docs-7",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-1",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-official-cli",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Bitwarden ships a documented, fully-featured official CLI (bw) with vault management, API key auth for automated workflows, and a runtime-verified 'bw serve' mode exposing a local REST API well-suited to agentic/AI use. missing for 10: independent third-party benchmarking of agent integration quality beyond one community anecdote about plaintext output behavior.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-9",
      "bitwarden-probe-4",
      "bitwarden-probe-rt-1",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-public-api",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden documents a Public API for organization management (bitwarden-docs-8), a personal API key for automated/programmatic access (bitwarden-docs-9), and a full-featured CLI (bitwarden-docs-7, bitwarden-probe-4) with a documented `bw serve` REST mode enabling agent-driven vault access (bitwarden-probe-rt-1); this constitutes a documented public API surface an AI-native user could drive. missing for 10: a public OpenAPI/swagger spec resolves 404 on probed endpoints (bitwarden-probe-2), and one community report flags a CLI safety/UX issue (bitwarden-comm-13) showing rough edges in automation ergonomics.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-2",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-scoped-keys",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Bitwarden documents a personal API key for CLI/automated workflows and a Public API/CLI (including `bw serve` and an official MCP server) that an agent could use, but there's no evidence of fine-grained, least-privilege scoping (e.g., read-only, per-item, or per-collection API keys) — the personal API key and CLI access appear to grant broad vault access rather than scoped permissions, and a hands-on report shows `bw list` dumping full plaintext secrets rather than a restricted subset. missing for 10: documented scoped/restricted API key types, per-agent permission grants, or evidence that MCP/CLI access can be limited to specific vault items rather than the whole vault.",
    "evidenceIds": [
      "bitwarden-docs-9",
      "bitwarden-docs-8",
      "bitwarden-probe-rt-1",
      "bitwarden-probe-rt-2",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-sdks",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Evidence shows Bitwarden exposes a Public API, CLI, personal API keys for automation, and an official MCP server (all of which an AI-native builder could integrate against), but there is no evidence of a dedicated, language-specific 'official SDK' (e.g., a bitwarden/sdk repo) and the OpenAPI/swagger spec probes all returned 404, suggesting no machine-readable API contract is published. missing for 10: explicit official SDK repositories/language bindings, published OpenAPI spec, independent developer corroboration of SDK usage.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-probe-2",
      "bitwarden-probe-3",
      "bitwarden-probe-rt-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "agentic-webhooks",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden's evidence covers event logs via the Public API and a CLI/MCP server for vault access, but nothing describes webhook subscriptions for events—no documented webhook endpoints, registration API, or push-event mechanism.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden documents a Public API for org management (bitwarden-docs-8) but there is no evidence of an interactive API reference with runnable examples (e.g., Swagger/OpenAPI explorer); a direct probe for openapi.json/swagger.json endpoints returned 404 on all candidate paths (bitwarden-probe-2), indicating no such interactive reference is exposed.",
    "evidenceIds": [
      "bitwarden-docs-8",
      "bitwarden-probe-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Bitwarden documents a Public API and CLI, but a probe for common OpenAPI/Swagger spec URLs (openapi.json, swagger.json, .well-known/openapi.json) all returned 404, and no evidence pack item shows a downloadable machine-readable API spec. Missing for 10: any documented OpenAPI/Swagger file, spec download link, or API reference generator output.",
    "evidenceIds": [
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-probe-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "api-sandbox",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence of a sandbox/test environment offering for Bitwarden—docs and probes cover CLI, MCP server, import/export, TOTP, and self-hosting, but nothing describes a dedicated sandbox distinct from production data for testing purposes.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden documents a Public API and CLI/personal API key access, but there is no evidence of API versioning scheme or a documented deprecation policy; probes for an OpenAPI spec (bitwarden-probe-2) all returned 404s, and no docs mention version headers, breaking-change policy, or sunset timelines.",
    "evidenceIds": [
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-probe-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "app-lock",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "No official documentation in the evidence pack describes a PIN/biometric app-lock feature; the only signal is an indirect community comment implying fingerprint unlock already exists on some platforms but is missing on Linux, which weakly corroborates the capability without detailing scope or coverage. Missing for 10: first-party docs on biometric/PIN unlock, mobile-specific confirmation, and independent hands-on validation of the lock behavior.",
    "evidenceIds": [
      "bitwarden-comm-11"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "automation-bulk-operations",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "The CLI (bw list/create/edit/delete) and Public API expose scriptable, item-level access that can be chained for bulk operations, and import/export functions handle whole-vault bulk transfers of many items at once; community evidence (bw list dumping the entire vault) confirms bulk read actually works. However, there is no first-party documentation of a dedicated bulk-edit/bulk-tag/bulk-delete command or batch endpoint — bulk operations require the user to script them themselves rather than a built-in bulk API. Missing for 10: documented native bulk-update/bulk-delete commands, batch API endpoints for many items, and independent hands-on confirmation of large-scale automated edits succeeding.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-docs-5",
      "bitwarden-docs-6",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "automation-rules-engine",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden's evidence shows CLI, API, MCP server, and vault health reports, but nothing about defining rules that automatically trigger actions on events (e.g., breach detected → auto-rotate password, or policy-triggered workflows). This is a fair automation axis for a security product, but no evidence of any rule-based/event-triggered automation engine.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Bitwarden is a password manager; scheduling recurring jobs/workflows is not a capability of its product category (CLI, MCP server, and API are for vault access, not job scheduling). This is a category mismatch rather than a missing feature.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Bitwarden is a password manager, not an automation/workflow platform; there is no concept of 'automations' to version, review, or roll back within its product scope. The CLI/API/MCP evidence relates to vault access, not automation workflow versioning.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "breach-alerting",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Bitwarden's Vault Health Reports (docs-11/17) explicitly check for reused and weak passwords locally on the client, covering part of the story, but no evidence in the pack documents breach monitoring (e.g., known data-breach alerts) or an 'exposed passwords' check against breach databases. Missing for 10: evidence of breach/exposure alerts for compromised services, and any exposed-credential detection feature.",
    "evidenceIds": [
      "bitwarden-docs-11",
      "bitwarden-docs-17"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "browser-extension-autofill",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs confirm browser extension autofills matching credentials on login pages (docs-12), autofills stored passkeys across apps/websites (docs-4), and generates/syncs TOTP codes (docs-1, docs-2) which are surfaced during autofill in the extension. One community mention notes TOTP setup friction, but no concrete evidence contradicts the core autofill-of-TOTP/passkeys capability. Missing for 10: independent hands-on confirmation specifically that TOTP codes (not just passwords/passkeys) are auto-filled into login forms without manual copy-paste.",
    "evidenceIds": [
      "bitwarden-docs-12",
      "bitwarden-docs-4",
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-comm-12"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "competitor-import",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden's official docs explicitly support bulk import of TOTP/authenticator tokens from Google Authenticator (QR), LastPass Authenticator (JSON), and 2FAS (.2fas) backups, directly enabling power users to migrate accounts without re-enrolling each one by hand. This is a first-party, documented dedicated import flow, not a workaround.\n\nmissing for 10: independent hands-on confirmation of the bulk import UX working smoothly, and coverage of additional popular authenticator export formats (e.g., Authy, Microsoft Authenticator).",
    "evidenceIds": [
      "bitwarden-docs-3",
      "bitwarden-docs-14"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "desktop-app",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Evidence confirms TOTP codes sync across 'Bitwarden apps' and vault access is available via browser extension and CLI on a computer, implying desktop-class access, but no citation explicitly documents a native desktop application (GUI) separate from the browser extension/CLI. Missing for 10: explicit desktop app documentation, screenshots/feature parity claims, and independent confirmation that a first-class desktop GUI (not just extension/CLI) exists and works well.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-docs-7",
      "bitwarden-docs-12",
      "bitwarden-probe-rt-1"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "device-to-device-transfer",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden's cloud vault syncs logins, passkeys, and TOTP codes across devices automatically (docs-1, docs-2, docs-4), so logging into a new phone with the same account would pull in tokens without manual export/import — effectively delivering the outcome. However, no evidence describes a dedicated 'guided' new-device setup wizard, and one community report (bitwarden-comm-9) describes lost generated data tied to connectivity issues, raising reliability caveats for a seamless one-step transfer. Missing for 10: documented guided device-migration flow/wizard, and independent hands-on confirmation that TOTP/passkeys transfer flawlessly to a new phone.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-docs-4",
      "bitwarden-comm-9"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "e2ee-backup",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Docs confirm Bitwarden supports vault export/import and mention an 'encrypted exports' option (bitwarden-docs-5, bitwarden-docs-6, bitwarden-docs-16), implying some backups can be encrypted, but no evidence pack item documents the underlying encryption design, key derivation, or explicitly states the vendor cannot access backup contents. missing for 10: a linked security whitepaper or architecture doc describing zero-knowledge key management for exports, explicit vendor-can't-decrypt-backups statement, and independent verification of the encrypted export format.",
    "evidenceIds": [
      "bitwarden-docs-5",
      "bitwarden-docs-6",
      "bitwarden-docs-16"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "lost-phone-recovery",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden's docs show that TOTP codes are synced across the Bitwarden apps (docs-2) and that vault data (including logins) can be exported/imported to restore to a new install (docs-5, docs-6), which together give a de facto path to recover accounts/tokens on a new device after losing a phone. However there is no explicit 'lost my phone' recovery guide, and community reports mention TOTP/sync reliability problems (bitwarden-comm-12, bitwarden-comm-9) that add real-world caveats. Missing for 10: a dedicated 'device loss/account recovery' doc, evidence of automatic cloud vault sync restoring a fresh install without manual export/import, and confirmation that community-reported sync/TOTP glitches don't block this flow.",
    "evidenceIds": [
      "bitwarden-docs-2",
      "bitwarden-docs-5",
      "bitwarden-docs-6",
      "bitwarden-comm-12",
      "bitwarden-comm-9"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "multi-device-sync",
    "verdict": "disputed",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden's docs describe cloud-based vault sync (TOTP codes staying synchronized across apps, passkeys usable across browser extension and mobile apps, auto-fill working consistently) which underlies cross-device availability of stored items (bitwarden-docs-2, bitwarden-docs-4, bitwarden-docs-12). However, a hands-on community report describes losing a generated password due to sync failures on bad connections, calling it 'quite common' (bitwarden-comm-9), directly contradicting the claim of seamless automatic sync. missing for 10: independent verification of reliable real-time sync across phone/tablet/computer simultaneously, and resolution/acknowledgment of the reported data-loss-on-sync issue.",
    "evidenceIds": [
      "bitwarden-docs-2",
      "bitwarden-docs-4",
      "bitwarden-docs-12",
      "bitwarden-comm-9"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence only describes Bitwarden's standard TOTP support (six-digit SHA-1 codes rotating every 30 seconds) with no mention of Steam Guard tokens, HOTP counters, or custom periods/digit lengths anywhere in the docs, community, or probe items.",
    "evidenceIds": [
      "bitwarden-docs-1"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "offline-code-generation",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Bitwarden's TOTP generation is tightly coupled to the vault: codes are stored and computed inside a Bitwarden vault item, which requires a Bitwarden account/vault (docs-1, docs-2) and typically syncs across the vendor's cloud infrastructure. No evidence describes a standalone, account-free offline TOTP mode; self-hosting (docs-10) still requires an account/server setup, not a vendor-free path. missing for 10: evidence of a no-account, no-vendor-server offline TOTP mode; confirmation that code generation works without ever creating/authenticating a Bitwarden account.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-docs-10"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "open-format-export",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Bitwarden documents a general vault export (JSON/CSV) for 'logins and notes' and back-up/transfer purposes, but the evidence never explicitly confirms that TOTP secrets are included in that export or specifies an open, human-readable format for them — only import paths for other authenticators (Google Authenticator QR, LastPass JSON, 2FAS) are detailed, which is the opposite direction (lock-in mitigation on entry, not exit). Missing for 10: explicit confirmation that TOTP seeds are present in the standard export file, documentation of the exact readable TOTP export format, and any independent/hands-on verification that exported TOTP secrets can be reimported elsewhere.",
    "evidenceIds": [
      "bitwarden-docs-5",
      "bitwarden-docs-16",
      "bitwarden-docs-3",
      "bitwarden-docs-14"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "open-source-clients",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden markets itself as 'the most trusted open source password manager' and community members explicitly cite open-source clients as the reason they trust it with secrets (bitwarden-probe-1, bitwarden-comm-15). However, the evidence also documents a real controversy where SDK code (used by clients) was briefly relicensed away from a fully open license before being reverted after community pressure, which shows scrutiny worked but also that openness has not always been airtight (bitwarden-comm-1, bitwarden-comm-3, bitwarden-comm-4). Missing for 10: direct links to client-app GitHub repos, explicit confirmation that seed/TOTP-handling code specifically is open and audited, and independent third-party code audits corroborating the open-source claim.",
    "evidenceIds": [
      "bitwarden-probe-1",
      "bitwarden-comm-15",
      "bitwarden-comm-1",
      "bitwarden-comm-3",
      "bitwarden-comm-4"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "openness-api-parity",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden ships a fully-featured CLI and a Vault Management API (`bw serve`) covering item/vault CRUD, TOTP retrieval, and org management via a Public API and personal API key for automated workflows, giving strong but not fully documented parity with the UI. There's no explicit vendor claim or evidence that every UI feature (e.g., passkey autofill, browser-context auto-fill, vault health reports) is exposed via API/CLI, and a hands-on report shows the CLI's `bw list` behaves differently than expected (dumping all secrets) rather than mirroring UI workflows cleanly. missing for 10: explicit API/CLI equivalents for passkey autofill and browser-based auto-fill, API access to vault health reports, and a documented feature-parity statement.",
    "evidenceIds": [
      "bitwarden-docs-7",
      "bitwarden-docs-8",
      "bitwarden-docs-9",
      "bitwarden-probe-rt-1",
      "bitwarden-comm-13"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "openness-full-export",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Bitwarden's docs explicitly support exporting full vault data (logins, notes) for backup or transfer, plus separate authenticator/TOTP export in open formats (JSON), and CLI/API access for automated bulk export. This directly satisfies the 'export all data in open formats and leave' story with strong first-party documentation. Missing for 10: no independent/hands-on confirmation of export format fidelity or completeness verification by a third party.",
    "evidenceIds": [
      "bitwarden-docs-5",
      "bitwarden-docs-16",
      "bitwarden-docs-3",
      "bitwarden-docs-14",
      "bitwarden-docs-7",
      "bitwarden-docs-6"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "openness-open-license",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Community evidence and the MCP server repo confirm Bitwarden ships components under open licenses (e.g., bitwarden/mcp-server is GPL-3.0) and is broadly known/marketed as 'the most trusted open source password manager,' and users cite valuing its open client source. However, the same evidence documents a real controversy where Bitwarden relicensed its SDK away from a fully open license, only reversing course after backlash — a concrete counter-example to unconditional openness. missing for 10: explicit license file/repo evidence for the core vault clients, resolution details confirming all components are now uniformly open-licensed, independent audit confirming no remaining non-open components.",
    "evidenceIds": [
      "bitwarden-probe-rt-2",
      "bitwarden-comm-1",
      "bitwarden-comm-3",
      "bitwarden-comm-4",
      "bitwarden-comm-15",
      "bitwarden-probe-1"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "openness-self-host",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Bitwarden provides official, well-documented on-premise/self-hosting instructions for Linux servers, and it is open-source, aligning strongly with an AI-native user's openness needs. missing for 10: independent hands-on verification of self-hosted deployment specifically (evidence is docs-only, not community confirmation of self-hosting success).",
    "evidenceIds": [
      "bitwarden-docs-10",
      "bitwarden-probe-1"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "org-policy-controls",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "The evidence only shows that Bitwarden's Public API lets organizations manage 'members, collections, groups, event logs, and policies,' implying policy management exists, but there is no documentation shown for specific policies like app-lock enforcement, export restriction, or master-password strength requirements. Missing for 10: explicit documentation of individual policy types (master password strength, disable personal vault export, require app lock/timeout), admin console UI screenshots or workflow, and any hands-on confirmation that these policies are enforced across all members' apps.",
    "evidenceIds": [
      "bitwarden-docs-8"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden explicitly stores passkeys in the vault and lets the browser extension and mobile apps autofill them across apps and sites, which is the platform-agnostic model (unlike Apple/Google's device-locked passkey sync) [bitwarden-docs-4]. However, the docs only call out browser extension and mobile apps, not desktop apps on Windows/Linux specifically, and there's no independent hands-on confirmation of passkey sync working seamlessly across all five named platforms. Missing for 10: explicit desktop (Windows/Linux) passkey autofill documentation, and independent/community verification of cross-platform passkey sync reliability.",
    "evidenceIds": [
      "bitwarden-docs-4"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "passkey-storage-signin",
    "verdict": "full",
    "quality": 8,
    "confidence": "medium",
    "rationale": "Bitwarden documents storing passkeys in the vault and using the browser extension or mobile apps to autofill/sign in with them across websites and apps, going beyond TOTP-only support (bitwarden-docs-4), which aligns directly with the story's requirement of passkey-based sign-in, not just TOTP codes. Missing for 10: independent/hands-on user reports specifically confirming passkey sign-in reliability (community evidence only discusses TOTP/autofill issues, not passkeys) and detail on cross-platform (desktop app) passkey support beyond browser/mobile.",
    "evidenceIds": [
      "bitwarden-docs-4",
      "bitwarden-docs-1",
      "bitwarden-docs-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack item mentions data residency, region selection, or self-hosting for regional compliance beyond a generic on-premise Linux install guide, which does not address choosing a storage region. Missing for 10: any documentation of region/data-residency selection (e.g., EU vs US data centers), enterprise residency options, or explicit control over where vault data is stored.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "privacy-no-training",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "The evidence pack contains no documentation, policy statement, or setting from Bitwarden addressing whether vault data or user data is used to train AI models, nor any opt-out mechanism for such use. This is a fair privacy-posture question for a SaaS handling sensitive personal data, but nothing in the pack confirms or denies a stance, so it cannot be credited as delivered.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "Bitwarden docs show users can export their vault data (for backup or account transfer) and community evidence indicates an account-deletion path exists (export → delete account → recreate), but there is no dedicated, first-party documentation on data retention policies, granular deletion controls, or how these apply to AI/agent access (e.g., MCP server or CLI-served vault data). Missing for 10: explicit retention policy documentation, dedicated account/vault deletion docs, and clarity on data lifecycle when accessed via CLI/MCP for AI agents.",
    "evidenceIds": [
      "bitwarden-docs-5",
      "bitwarden-docs-16",
      "bitwarden-comm-2"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "privacy-telemetry-optout",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack contains no documentation, settings, or community reports describing a telemetry/usage-tracking opt-out control in Bitwarden clients, CLI, or self-hosted server. While the axis is fair to ask of any privacy-focused product, nothing here confirms such a toggle exists or how it works.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack items reference independent third-party security audits, penetration tests, or cryptographic/protocol reviews of Bitwarden's app or sync protocol; the pack only covers docs on features (TOTP, autofill, CLI, import/export) and community sentiment/complaints unrelated to audits. Missing for 10: published audit reports (e.g., Cure53), audit scope/dates, sync protocol review findings, remediation disclosures.",
    "evidenceIds": []
  },
  {
    "productId": "bitwarden",
    "storyId": "qr-totp-enrollment",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Docs confirm Bitwarden's integrated authenticator automatically generates rotating TOTP codes once a key/QR is added to a login item (bitwarden-docs-1, bitwarden-docs-13), which covers the core capability, but the pack lacks explicit documentation of the actual camera-scan-QR flow for a brand-new account (only QR-based *import* from another authenticator app is documented, bitwarden-docs-3/14). One community report also describes difficulty getting TOTP working at all (bitwarden-comm-12), though it's anecdotal and not a concrete reproducible failure. missing for 10: explicit doc/screenshot of scanning a QR to add a brand-new TOTP secret (not import), and independent hands-on confirmation that codes generate immediately after scan.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-13",
      "bitwarden-docs-3",
      "bitwarden-comm-12"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "self-host-sync-server",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Bitwarden provides official documentation for installing and deploying the self-hosted server on a Linux server, keeping vault data on the admin's own infrastructure — the core of this story. Missing for 10: independent hands-on verification of a real-world self-hosted deployment and details on ongoing maintenance/upgrade complexity for self-hosted instances.",
    "evidenceIds": [
      "bitwarden-docs-10"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "team-shared-vaults",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Bitwarden's docs confirm built-in TOTP generation/sync (bitwarden-docs-1, bitwarden-docs-2) and its Public API supports managing organization members, collections, and groups (bitwarden-docs-8), and a real-world team user cites 'safer account sharing, including 2FA' as a killer feature (bitwarden-comm-8). However, the evidence pack lacks explicit documentation tying TOTP fields to collection-level per-member permissions/access control, so the granular sharing mechanics aren't directly evidenced. Missing for 10: dedicated docs on collection permission levels (view/edit/manage) applied to TOTP-containing items, and independent confirmation of this exact workflow.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-docs-8",
      "bitwarden-comm-8"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "token-organization",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Docs confirm Bitwarden generates and syncs TOTP codes across devices and lets users import/export authenticator data (bitwarden-docs-1, bitwarden-docs-2, bitwarden-docs-3), which supports storing many tokens, but nothing in the evidence pack speaks to search, folders/groups, or service icons specifically for TOTP entries — organization is only implied through the general vault (login) item structure. missing for 10: explicit documentation of folder/collection organization for TOTP items, search functionality across TOTP entries, and service icon display for stored codes.",
    "evidenceIds": [
      "bitwarden-docs-1",
      "bitwarden-docs-2",
      "bitwarden-docs-3"
    ]
  },
  {
    "productId": "bitwarden",
    "storyId": "watch-codes",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence pack covers TOTP generation, syncing, browser extension, CLI, and API features, but contains no mention of a smartwatch app, Wear OS/watchOS companion, or any glanceable code display for wearables. This is a fair capability question for a password manager with a built-in authenticator, but no evidence shows it is delivered.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agent-code-retrieval",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only shows a CLI for exporting/backing up and decrypting Ente Auth data (ente-auth-docs-11, ente-auth-probe-rt-1), not for programmatically retrieving a live/current TOTP code for use in an automated 2FA login. No API, CLI subcommand, or docs describe generating a real-time code for agent consumption.",
    "evidenceIds": [
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1",
      "ente-auth-probe-3"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agent-local-endpoint",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any local API, IPC endpoint, or programmatic interface for querying codes; the only related tooling is the export/backup CLI (docs-11, probe-rt-1), which produces files rather than a queryable local endpoint an agent could hit live. No OpenAPI/local server documentation was found (probe-3 confirms no openapi endpoint).",
    "evidenceIds": [
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1",
      "ente-auth-probe-3"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agent-vault-provisioning",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence shows only manual QR-scan/setup-key entry, GUI import/export, and a CLI limited to exporting and decrypting backups—no documented API, SDK, or CLI subcommand for programmatically creating or updating vault entries. No OpenAPI/API surface was found (ente-auth-probe-3 confirms no openapi.json), so an agent has no documented programmatic surface to seed or update TOTP secrets.",
    "evidenceIds": [
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1",
      "ente-auth-probe-3",
      "ente-auth-docs-1",
      "ente-auth-docs-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-agent-docs",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente serves a live llms.txt at ente.com/llms.txt confirmed by two independent probes, giving an agent a fair entry point; however, docs-as-markdown and OpenAPI endpoints 404, so agent-oriented documentation beyond the single llms.txt file is thin. missing for 10: markdown-served docs pages, OpenAPI/agent-consumable API spec, broader agent-oriented doc structure beyond one root file.",
    "evidenceIds": [
      "ente-auth-probe-1",
      "ente-auth-probe-rt-2",
      "ente-auth-probe-2",
      "ente-auth-probe-3"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-ai-insights",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/authenticator app; there is no evidence of any AI-generated insights or suggestions feature, and this is not a category where such analytics would be a fair expected axis — the product's scope is encrypted TOTP/HOTP code storage and sync, not data analysis.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/authenticator app with no AI assistant or agent-delegation feature of any kind in its evidence; delegating tasks to a built-in AI assistant is outside this product's category entirely.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-headless",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "Ente provides an official CLI (ente-cli) that can run headlessly to export/backup Auth codes, which is scriptable and could be used in automation/CI contexts, but evidence only documents it for exporting/decrypting backups, not for generic headless operation, generating TOTP codes on demand, or CI-integrated workflows. Missing for 10: documentation of CLI usage for retrieving/generating codes programmatically, CI-specific examples, and any first-party statement about automation/agentic use beyond backup.",
    "evidenceIds": [
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/authenticator app; MCP server plugin capability is unrelated to its product category and no evidence suggests otherwise.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-official-cli",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Ente ships an official CLI (github.com/ente/ente/tree/main/cli) confirmed to be packaged via Homebrew as 'ente-cli', documented as scriptable tooling to 'automatically backup your Auth codes' and decrypt exports — this is a real, official, automatable interface. However it is scoped narrowly to backup/export/decrypt operations rather than full account/code management or general agentic control. Missing for 10: broader CLI command coverage (add/edit/delete codes, sharing, sync), first-party docs detailing CLI usage beyond export, and independent hands-on reports of using it in automated/agentic workflows.",
    "evidenceIds": [
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-public-api",
    "verdict": "partial",
    "quality": 3,
    "confidence": "medium",
    "rationale": "Ente provides a CLI (ente-cli) for exporting/backing up Auth codes and a documented deep-link scheme (enteauth://search), but there is no documented public REST/GraphQL API or SDK for driving the product programmatically — OpenAPI probes returned 404s. missing for 10: a documented public API/SDK covering core operations (add/edit/delete codes, sharing, sync), API authentication docs, and independent developer corroboration of API usage.",
    "evidenceIds": [
      "ente-auth-probe-rt-1",
      "ente-auth-docs-11",
      "ente-auth-docs-42",
      "ente-auth-probe-3"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-sdks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "agentic-webhooks",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/authenticator app with no evidence of any event-driven webhook or subscription API; webhooks are not a fit category axis for this type of product (offline/encrypted code storage tool), and no evidence suggests it exposes such a system.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of an interactive API reference or runnable examples; OpenAPI/swagger probes returned 404s and no developer API docs are mentioned anywhere in the pack.",
    "evidenceIds": [
      "ente-auth-probe-3",
      "ente-auth-probe-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Probe results explicitly show all candidate OpenAPI/Swagger paths return 404, and there is no documented machine-readable API spec anywhere in the evidence pack; missing for 10: any published OpenAPI/Swagger file, API reference docs, or equivalent machine-readable spec.",
    "evidenceIds": [
      "ente-auth-probe-3"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA code manager, not an API/platform product with sandbox/test environments; the notion of testing against a sandbox vs production data is a category mismatch for this type of app.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA authenticator app; there is no evidence of a public API, API versioning scheme, or documented deprecation policy — OpenAPI probes 404 and no API docs exist in the evidence pack.",
    "evidenceIds": [
      "ente-auth-probe-3",
      "ente-auth-probe-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "app-lock",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs explicitly confirm FaceID lock (Settings → Security → Lockscreen) and a custom lock screen supporting PINs and passwords, directly matching the story's biometric/PIN app-lock requirement. missing for 10: no independent/hands-on confirmation that the lock actually blocks access on a borrowed device, and no mention of Android biometric or desktop lock parity beyond FaceID/PIN.",
    "evidenceIds": [
      "ente-auth-docs-32",
      "ente-auth-docs-19"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "automation-bulk-operations",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Ente Auth documents bulk import from other 2FA apps and a CLI tool for scripted export/backup of all codes, which supports some automation-depth for a bulk operation, but there is no evidence of programmatic bulk editing, deleting, or tagging across many stored codes at once (only single-item edit/delete via long-press is documented). missing for 10: bulk edit/delete/tag API or CLI beyond import/export, evidence of scripted multi-item management, independent hands-on confirmation of bulk workflows.",
    "evidenceIds": [
      "ente-auth-docs-26",
      "ente-auth-docs-3",
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1",
      "ente-auth-docs-33"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/TOTP authenticator app; it has no rule engine, event triggers, or automation/workflow features—this is a category mismatch, not a missing feature of an automation product.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/TOTP code manager; scheduling recurring jobs or workflows is not a fair capability for this product category — it has no workflow/automation engine.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a 2FA/authenticator app, not an automation platform; there is no concept of 'automations' to version, review, or roll back in this product's domain.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "breach-alerting",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth is a TOTP/HOTP authenticator app; nothing in the evidence pack shows breach-monitoring, weak/reused-credential detection, or exposure alerts — its documented features are around code storage, import/export, sharing, and lockscreen security.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "browser-extension-autofill",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of a browser extension for Ente Auth; the product is described as apps for mobile, desktop and web with manual QR-scan/setup-key entry, not autofill via a browser extension for TOTP or passkeys during login.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "competitor-import",
    "verdict": "full",
    "quality": 9,
    "confidence": "high",
    "rationale": "Ente Auth has a dedicated bulk-import feature and docs listing native support for many 2FA providers (2FAS, Aegis, andOTP, Bitwarden, Google Authenticator, LastPass, Proton, Raivo OTP) plus conversion paths for others like Authy, with community testimony confirming easy export/import migration from Aegis. missing for 10: no independent hands-on walkthrough of the bulk-import UI itself, only docs and one community mention.",
    "evidenceIds": [
      "ente-auth-docs-3",
      "ente-auth-docs-26",
      "ente-auth-docs-39",
      "ente-auth-docs-4",
      "ente-auth-docs-5",
      "ente-auth-comm-6"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "desktop-app",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente Auth explicitly ships native desktop clients (Flathub Linux app, plus 'app for every platform: Mobile, desktop and web' with full sync) and desktop-specific UI features like right-click code editing, matching a first-class desktop experience; a HN user corroborates switching to it specifically for its desktop app after Authy dropped theirs. missing for 10: explicit list/docs of Windows/Mac desktop builds beyond Flathub, and an independent hands-on review confirming full feature parity with mobile.",
    "evidenceIds": [
      "ente-auth-docs-20",
      "ente-auth-docs-27",
      "ente-auth-docs-33",
      "ente-auth-comm-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "device-to-device-transfer",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente Auth syncs codes end-to-end encrypted across all devices (docs-27, docs-34), so on a new phone a user simply logs into their existing account and their tokens reappear automatically—effectively a single guided step. Community feedback corroborates that switching devices via export/import was 'very easy' (ente-auth-comm-6), and offline-mode users can restore via password-protected local/CLI backups (docs-7, docs-8, docs-9, docs-11, ente-auth-probe-rt-1).\nMissing for 10: no explicit first-party step-by-step 'new phone setup/restore' walkthrough, and no independent hands-on account of the exact new-device login-and-sync flow.",
    "evidenceIds": [
      "ente-auth-docs-27",
      "ente-auth-docs-34",
      "ente-auth-docs-7",
      "ente-auth-docs-8",
      "ente-auth-docs-11",
      "ente-auth-comm-6",
      "ente-auth-probe-rt-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "e2ee-backup",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Ente docs state cloud backups are end-to-end encrypted (docs-27, docs-34) and local backups are encrypted with a password-derived key that Ente cannot recover (docs-9, docs-12), plus open-source apps/server are confirmed (probe-rt-2), supporting a 'vendor never holds key' claim. However there is no detailed cryptographic design doc (key derivation algorithm, protocol specifics, audit report) in the evidence, only high-level marketing/FAQ statements. Missing for 10: a published encryption whitepaper or technical spec, and independent security audit/corroboration of the E2E design.",
    "evidenceIds": [
      "ente-auth-docs-27",
      "ente-auth-docs-34",
      "ente-auth-docs-9",
      "ente-auth-docs-12",
      "ente-auth-probe-rt-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "lost-phone-recovery",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Ente Auth documents end-to-end encrypted cloud sync/backups so codes restore on a new device after login, plus a recovery key to bypass 2FA lockouts, local encrypted backups, and a CLI export tool as additional restore paths. missing for 10: no independent hands-on account of a real device-loss recovery walkthrough, and no detail on exact steps to restore cloud-synced codes on a fresh device beyond general sync claims.",
    "evidenceIds": [
      "ente-auth-docs-27",
      "ente-auth-docs-34",
      "ente-auth-docs-13",
      "ente-auth-docs-8",
      "ente-auth-docs-9",
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1",
      "ente-auth-comm-7"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "multi-device-sync",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Ente Auth explicitly advertises multi-platform apps (mobile, desktop, web) with end-to-end encrypted cloud sync so codes stay in sync across devices, and community evidence corroborates real-world use across app switches without complaint about sync failures. Missing for 10: independent hands-on confirmation of real-time multi-device sync latency/reliability and any edge-case sync bugs reported by users.",
    "evidenceIds": [
      "ente-auth-docs-27",
      "ente-auth-docs-34",
      "ente-auth-comm-1",
      "ente-auth-comm-6"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "nonstandard-token-support",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Evidence confirms HOTP entries are supported (the changelog notes sharing is now limited to TOTP and hidden for HOTP entries), implying native HOTP counter support. However, there is no mention anywhere in the evidence pack of Steam Guard token support, or of custom period/digit-length configuration for TOTP entries. missing for 10: explicit Steam Guard support, custom period/digit-length configuration, and any hands-on confirmation beyond the changelog note.",
    "evidenceIds": [
      "ente-auth-docs-30"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "offline-code-generation",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs explicitly confirm offline mode with no account required, codes stored only on-device, and no network dependency for viewing codes. Missing for 10: independent hands-on verification (e.g. airplane-mode test) beyond vendor docs, and no detail on how backups/imports work fully offline without any cloud touchpoint.",
    "evidenceIds": [
      "ente-auth-docs-7",
      "ente-auth-docs-37"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "open-format-export",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Ente Auth does offer local encrypted backups and a CLI ('ente-cli') that can export and decrypt Auth data (docs-8/9/11, probe-rt-1), and Authy-specific tooling explicitly produces a 'plaintext export format' for importing into Ente (docs-5/40) — but this is import-facing, not an open export for leaving Ente. A hands-on community report explicitly states the opposite of the 'no lock-in' claim: 'You cant easily export your codes into a different format using this app, meaning that it is difficult to migrate away once you have already moved your codes over' (comm-2), while other users only describe importing into Ente, not exporting out to a different app's format. Missing for 10: documented open/standard export format usable directly by other authenticator apps, and independent confirmation that migrating away (not just in) is easy.",
    "evidenceIds": [
      "ente-auth-docs-8",
      "ente-auth-docs-9",
      "ente-auth-docs-11",
      "ente-auth-docs-5",
      "ente-auth-probe-rt-1",
      "ente-auth-comm-2",
      "ente-auth-comm-7"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "open-source-clients",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente's own llms.txt explicitly states 'Ente's apps and server are open source,' and a community poster on HN independently confirms 'thank you for releasing it open source,' corroborating that the client code is publicly available for inspection. Missing for 10: a direct link/reference to the actual auth client source repo, and independent evidence of community security review or audits of the seed-handling code.",
    "evidenceIds": [
      "ente-auth-probe-rt-2",
      "ente-auth-comm-4"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "openness-api-parity",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Ente Auth exposes only a CLI for exporting/decrypting backups, not a general API covering all UI actions (add/edit/share/organize codes, etc.); probes for OpenAPI/API docs all returned 404, and no documentation describes a comprehensive API surface.",
    "evidenceIds": [
      "ente-auth-probe-3",
      "ente-auth-probe-rt-1",
      "ente-auth-docs-11"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "openness-full-export",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Ente ships an official CLI to export and decrypt Auth data and documents password-encrypted local backups, and some HN commenters confirm easy export/import between apps (comm-6,7,8; probe-rt-1). But a first-hand HN commenter explicitly states 'You cant easily export your codes into a different format using this app, meaning that it is difficult to migrate away' (comm-2), directly contradicting the frictionless open-format export claim. Missing for 10: a documented plain/open (non-proprietary) full export format, resolution of the lock-in complaint, and independent verification that CLI-exported data is usable outside Ente.",
    "evidenceIds": [
      "ente-auth-docs-8",
      "ente-auth-docs-9",
      "ente-auth-docs-11",
      "ente-auth-docs-12",
      "ente-auth-probe-rt-1",
      "ente-auth-comm-2",
      "ente-auth-comm-6",
      "ente-auth-comm-8"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "openness-open-license",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente's own llms.txt explicitly states 'Ente's apps and server are open source,' and a GitHub repo (ente/ente) is referenced for the CLI/export tooling; independent HN commentary corroborates ('thank you for releasing it open source'). Missing for 10: explicit license name/text and a direct link to the license file are not shown in the evidence pack.",
    "evidenceIds": [
      "ente-auth-probe-1",
      "ente-auth-probe-rt-2",
      "ente-auth-comm-4",
      "ente-auth-docs-11"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "openness-self-host",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Ente explicitly documents self-hosting instructions, pointing users to run Ente Auth at localhost/machine-ip:3003, and the product is described as open source, consistent with independent verification via the llms.txt runtime probe. missing for 10: independent hands-on report of a full self-hosted deployment (beyond docs/probe), and details on self-hosting server setup/requirements beyond the port reference.",
    "evidenceIds": [
      "ente-auth-docs-15",
      "ente-auth-probe-1",
      "ente-auth-probe-rt-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any org-wide admin console, centralized policy enforcement, mandated master password strength, or app lock/export restrictions applied across members — Ente Auth is a personal/individual authenticator with local lock screen (per-device) and personal backup/export options, not a managed enterprise policy tool.",
    "evidenceIds": [
      "ente-auth-docs-19",
      "ente-auth-docs-9",
      "ente-auth-docs-11"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Ente Auth is a TOTP/2FA code manager; the only passkey mention in evidence (doc-14) refers to passkey login for the separate Ente Photos account, not Ente Auth storing/syncing passkeys as credentials across iOS/Android/Windows/Linux/browsers. No evidence shows Ente Auth itself functions as a cross-platform passkey vault.",
    "evidenceIds": [
      "ente-auth-docs-14",
      "ente-auth-docs-27"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "passkey-storage-signin",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "privacy-data-residency",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Ente Auth offers self-hosting instructions (running your own Ente Auth server) and an offline mode that keeps codes only on-device, both of which let a user control where their data lives rather than being forced into a fixed cloud region. However, there's no explicit region/residency selection (e.g., choosing an EU vs US data center) for its hosted cloud service. Missing for 10: explicit multi-region cloud storage options, documented data-residency guarantees for the hosted service.",
    "evidenceIds": [
      "ente-auth-docs-15",
      "ente-auth-docs-7",
      "ente-auth-probe-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "privacy-no-training",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Ente Auth stores codes with end-to-end encryption, meaning Ente itself cannot access plaintext data, which structurally prevents it from being used to train AI models — but there is no explicit policy statement addressing AI training use of data. Missing for 10: an explicit AI-training data-use policy/statement, and any independent confirmation of this posture beyond the general E2E encryption claim.",
    "evidenceIds": [
      "ente-auth-docs-34",
      "ente-auth-docs-12",
      "ente-auth-probe-2"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Ente Auth lets users delete/trash codes with recovery or permanent deletion (docs-18/33/38), control backup location and encryption (docs-9/10), run fully offline with no cloud retention (doc-7), and export/decrypt all data via the official CLI for full portability (docs-11, probe-rt-1). However there's no explicit documentation on cloud-side account/data deletion policies or retention periods for encrypted server backups. Missing for 10: documented cloud account deletion/retention policy, independent confirmation of full data erasure on request.",
    "evidenceIds": [
      "ente-auth-docs-18",
      "ente-auth-docs-33",
      "ente-auth-docs-38",
      "ente-auth-docs-7",
      "ente-auth-docs-9",
      "ente-auth-docs-10",
      "ente-auth-docs-11",
      "ente-auth-probe-rt-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "privacy-telemetry-optout",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack mentions any telemetry, analytics, or usage-tracking settings, opt-out toggles, or privacy policy statements about data collection in Ente Auth; the evidence covers import/export, backups, and sync features only.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence pack item references any independent security audit of Ente Auth or its sync protocol; documentation focuses on features, encryption claims, and migration, not third-party audit reports.",
    "evidenceIds": []
  },
  {
    "productId": "ente-auth",
    "storyId": "qr-totp-enrollment",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs explicitly describe scanning a QR code shown by a service to add a new account, both generally (docs-1) and for specific migration flows (docs-6/41), which immediately generates TOTP codes in the app. This core flow is directly and simply documented as the primary onboarding method. Missing for 10: independent hands-on confirmation of the exact scan-to-code-generation moment and any UX friction reports.",
    "evidenceIds": [
      "ente-auth-docs-1",
      "ente-auth-docs-2",
      "ente-auth-docs-6",
      "ente-auth-docs-41"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "self-host-sync-server",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Ente explicitly documents running the Auth server locally (e.g. at http://localhost:3003) and its server code is confirmed open source, supporting self-hosting for IT admins wanting to keep secrets in-perimeter. However, the evidence pack lacks detailed self-hosting setup docs (Docker/compose instructions, hardware requirements, upgrade/security guidance) and no independent community reports specifically about self-hosting the Auth server (only cloud usage is discussed in community threads). Missing for 10: full self-hosting deployment guide, independent hands-on verification of self-hosted Auth server, and security/perimeter assurances specific to self-hosted mode.",
    "evidenceIds": [
      "ente-auth-docs-15",
      "ente-auth-probe-rt-2",
      "ente-auth-probe-1"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "team-shared-vaults",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Ente Auth documents sharing individual TOTP codes via temporary, end-to-end encrypted links with teammates (docs-16, docs-35), and explicitly restricts sharing to TOTP (not HOTP) entries (docs-30), which covers the core 'share TOTP logins with team' idea. However there is no evidence of a vault/collection construct or per-member access control (e.g., role-based permissions, group vaults, admin-managed membership) — sharing appears to be per-code link generation rather than an admin-managed shared vault. Missing for 10: evidence of collection/vault-based sharing, per-member access control or roles, and admin management console for team access.",
    "evidenceIds": [
      "ente-auth-docs-16",
      "ente-auth-docs-35",
      "ente-auth-docs-30"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "token-organization",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Ente Auth's marketing docs confirm search (deep-link search feature), service icons, and favoriting/organizing features ('Organize with ease', 'Favorite services to the top', 'Don't scroll'), directly supporting quick access to tokens. However, there is no concrete evidence of folder or group/category organization for large token sets — only vague 'organize with ease' copy and free-text notes (500-char annotations), not structured grouping. Missing for 10: explicit folder/category/tagging feature documentation, evidence of grouping many tokens, independent hands-on confirmation of organization UX at scale.",
    "evidenceIds": [
      "ente-auth-docs-21",
      "ente-auth-docs-22",
      "ente-auth-docs-23",
      "ente-auth-docs-24",
      "ente-auth-docs-25",
      "ente-auth-docs-42",
      "ente-auth-docs-17"
    ]
  },
  {
    "productId": "ente-auth",
    "storyId": "watch-codes",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The evidence pack covers mobile/desktop/web platform support, import/export, sharing, and lockscreen features, but contains no mention of smartwatch (e.g. Wear OS, watchOS) support or companion app for viewing codes without pulling out a phone.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agent-code-retrieval",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a mobile/PAM app with no documented CLI or API for programmatic TOTP retrieval; evidence only covers manual app UI actions (sync, QR export, editing codes) and community complaints about backup/sync issues, none of which show agent-accessible code fetching.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agent-local-endpoint",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agent-vault-provisioning",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-agent-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-ai-insights",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a single-purpose OTP code generator with no data analytics or AI-generated insights feature; this axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a 2FA code generator utility, not an AI-agent or assistant platform; delegating tasks to a built-in AI assistant is outside its product category entirely.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-headless",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a simple OTP code generator app with no plugin/tool ecosystem or agent-integration capability; MCP server integration is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-official-cli",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-public-api",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-sdks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "agentic-webhooks",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a standalone TOTP/HOTP code-generator app with no API or event system; webhook subscriptions are a wrong axis for this product category.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "api-interactive-docs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a mobile 2FA code-generator app, not a developer platform or API product; an interactive API reference with runnable examples is a category mismatch for this kind of product.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "api-machine-spec",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a consumer mobile 2FA app with no programmatic API surface; a machine-readable API spec is not a relevant axis for this product category.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a simple TOTP/HOTP code generator app, not a developer platform or API service with a sandbox/testing environment concept; this axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "app-lock",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Google's own docs describe a 'Privacy Screen' feature requiring PIN, pattern, or biometric verification before the app can be used, directly matching the story. No community evidence contradicts this specific lock-screen feature (complaints focus on sync/backup, not app-lock). Missing for 10: independent hands-on confirmation of the Privacy Screen feature working reliably across devices.",
    "evidenceIds": [
      "google-authenticator-docs-9"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "automation-bulk-operations",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a static OTP-code generator app with no rules engine, event triggers, or automation/workflow capability; this axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a 2FA code generator app with no workflow/job-scheduling capability; scheduling recurring automation is outside its product category entirely.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Google Authenticator is a 2FA code generator, not an automation/workflow tool; versioning, reviewing, or rolling back automations is not a category concern for this product.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "breach-alerting",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "browser-extension-autofill",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "competitor-import",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence only covers transferring/syncing Google Authenticator codes between devices running Google Authenticator itself (QR export/import, Google Account sync), not bulk import of tokens originating in other authenticator apps (e.g., Authy, Microsoft Authenticator). No documentation or community report describes cross-app bulk import.",
    "evidenceIds": [
      "google-authenticator-docs-3",
      "google-authenticator-docs-4",
      "google-authenticator-docs-11",
      "google-authenticator-comm-18"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "desktop-app",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of a desktop application; Google Authenticator is documented and discussed only as a mobile app with QR-based transfer/sync between phones, not a desktop client or vault.",
    "evidenceIds": [
      "google-authenticator-docs-1",
      "google-authenticator-docs-3",
      "google-authenticator-gh-2"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "device-to-device-transfer",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Google's own docs describe a guided one-step transfer via signing into a Google Account (auto-sync) or scanning a QR export code between old/new devices, which matches the story closely. However, multiple hands-on community reports concretely contradict this working reliably in practice—users report app upgrades wiping all tokens, phone replacements losing TOTP keys despite expecting sync/backup, and account bans erasing synced codes entirely. missing for 10: independent verification that the guided transfer works consistently without data loss, and resolution of documented upgrade/sync failures.",
    "evidenceIds": [
      "google-authenticator-docs-3",
      "google-authenticator-docs-4",
      "google-authenticator-comm-1",
      "google-authenticator-comm-13",
      "google-authenticator-comm-14",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "e2ee-backup",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Docs only describe syncing codes via a Google Account (google-authenticator-docs-1,4) with no mention of end-to-end encryption or a vendor-blind key, and community reports explicitly note that storing codes in 'google cloud doesn't satisfy me' and that losing access to the Google account means losing all 2FA data, implying no such E2E encryption exists.",
    "evidenceIds": [
      "google-authenticator-docs-1",
      "google-authenticator-docs-4",
      "google-authenticator-comm-6",
      "google-authenticator-comm-7",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "lost-phone-recovery",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Google's own docs describe two documented recovery paths — signing into your Google Account to auto-sync codes across devices, or scanning a QR-code export to transfer codes to a new device (google-authenticator-docs-1/3/4/11) — which is exactly the story's ask. However, multiple hands-on community reports concretely contradict reliability of this recovery: users report app upgrades wiping all tokens with no recovery (comm-13, comm-14), phone backups explicitly excluding Authenticator data (comm-1, comm-8), and losing all codes permanently if the tied Google Account is banned/deleted (comm-7, comm-12). Missing for 10: independent verification that account-sync recovery works consistently across real device-loss scenarios, and resolution of the backup-exclusion/account-ban failure modes.",
    "evidenceIds": [
      "google-authenticator-docs-1",
      "google-authenticator-docs-3",
      "google-authenticator-docs-4",
      "google-authenticator-docs-11",
      "google-authenticator-comm-1",
      "google-authenticator-comm-8",
      "google-authenticator-comm-13",
      "google-authenticator-comm-14",
      "google-authenticator-comm-7",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "multi-device-sync",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Google's docs confirm automatic cross-device sync via Google Account sign-in, works offline, and supports multiple accounts (docs-1,4,5,10), but Authenticator is a mobile-only app with no native desktop/computer client, so the 'computer' leg of the story is unsupported. Community reports also cite historical sync/backup failures and account-loss risk tying codes to a Google Account (comm-1, comm-7, comm-12, comm-13), showing real caveats even if not disproving the current sync feature outright. Missing for 10: a computer/desktop client, independent hands-on confirmation the modern sync feature works reliably across all device types without data loss.",
    "evidenceIds": [
      "google-authenticator-docs-1",
      "google-authenticator-docs-4",
      "google-authenticator-docs-5",
      "google-authenticator-docs-10",
      "google-authenticator-comm-1",
      "google-authenticator-comm-7",
      "google-authenticator-comm-12",
      "google-authenticator-comm-13"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "nonstandard-token-support",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "The GitHub docs confirm the underlying library supports HOTP (RFC 4226) and TOTP (RFC 6238) algorithms, giving some basis for HOTP counter support, but there is no evidence anywhere in the pack that the consumer app exposes Steam Guard mode, custom periods, or custom digit lengths — the mobile app UI evidence only shows scanning QR codes, editing username, and deleting entries. missing for 10: Steam Guard token support, custom period configuration, custom digit-length configuration, and any UI/setting for manual HOTP counter entry.",
    "evidenceIds": [
      "google-authenticator-gh-1",
      "google-authenticator-gh-2",
      "google-authenticator-docs-6"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "offline-code-generation",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs explicitly state you can 'Use without an account' at setup and that codes generate 'without an internet connection or mobile service,' confirming fully offline, account-free TOTP generation (core RFC 6238 implementation per GitHub). Community discussion focuses on backup/sync/account-loss risks, not on offline generation failing, so no contradiction of this specific axis. Missing for 10: independent hands-on confirmation specifically testing offline-without-account code generation.",
    "evidenceIds": [
      "google-authenticator-docs-2",
      "google-authenticator-docs-10",
      "google-authenticator-gh-1"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "open-format-export",
    "verdict": "disputed",
    "quality": 3,
    "confidence": "medium",
    "rationale": "Docs and community posts confirm a QR-code 'export' exists, but it is a proprietary migration QR built for transferring to another Google Authenticator instance, not an open/readable text format, and users explicitly report Google 'makes it stupendously difficult to just get a simple text export to a file' and that codes cannot be included in backups. This directly contradicts the story's requirement of an open, readable, portable export for switching apps freely. Missing for 10: an official plain-text/otpauth-URI export, documented compatibility with third-party apps, and confirmation the QR format is standardized/open rather than proprietary.",
    "evidenceIds": [
      "google-authenticator-docs-3",
      "google-authenticator-docs-11",
      "google-authenticator-comm-9",
      "google-authenticator-comm-18",
      "google-authenticator-comm-6",
      "google-authenticator-comm-17"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "open-source-clients",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "The GitHub repo (google/google-authenticator) documents open-source implementations of HOTP/TOTP and a PAM module, giving some basis for code review, but the evidence pack has no confirmation that the current shipped Android/iOS apps (which now handle cloud sync of seeds) actually correspond to this repo or receive active community review. missing for 10: evidence that the live mobile app source matches the published repo, evidence of active maintenance/community audits of the seed-handling code, and independent confirmation of code correctness.",
    "evidenceIds": [
      "google-authenticator-gh-1",
      "google-authenticator-gh-2",
      "google-authenticator-gh-3"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "openness-api-parity",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "openness-full-export",
    "verdict": "disputed",
    "quality": 3,
    "confidence": "medium",
    "rationale": "Docs show a QR-code based transfer/export feature for moving codes between devices (docs-3, docs-11, comm-9, comm-18), but this is a proprietary re-import-only format tied to Google Authenticator itself, not an open, portable format usable elsewhere. Community evidence explicitly contradicts any 'open format export' claim: users report Google 'makes it stupendously difficult to just get a simple text export to a file' and that 'Google Authenticator does not allow you to include your codes in your backup, even when it's encrypted,' with data tied to a Google Account that can vanish if banned. Missing for 10: any documented open/standard export format (e.g., plain TOTP URI list, CSV, encrypted portable file), and evidence of true account-independent data portability.",
    "evidenceIds": [
      "google-authenticator-docs-3",
      "google-authenticator-docs-11",
      "google-authenticator-comm-6",
      "google-authenticator-comm-17",
      "google-authenticator-comm-9",
      "google-authenticator-comm-18",
      "google-authenticator-comm-7",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "openness-open-license",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "The official GitHub repo (google/google-authenticator) publicly hosts source for HOTP/TOTP implementations across platforms and a PAM module, suggesting some source is open, but the evidence never states an explicit open-source license nor confirms the current mobile app's source is included/maintained there. missing for 10: explicit license text (e.g., Apache 2.0) confirmation, evidence the current Android/iOS app source (not just legacy PAM/CLI code) is published, and any independent corroboration of license terms.",
    "evidenceIds": [
      "google-authenticator-gh-1",
      "google-authenticator-gh-2",
      "google-authenticator-gh-3"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "openness-self-host",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Google Authenticator's core mobile app is closed-source and tied to Google account infrastructure for sync (docs-1, docs-4); the only open-source artifacts on GitHub are OTP-generator libraries and a PAM module, not the actual app users run, and there's no documented way to self-host the core product. Community threads reinforce this, complaining about lack of control over codes and dependency on Google's cloud (comm-6, comm-7, comm-12).",
    "evidenceIds": [
      "google-authenticator-docs-1",
      "google-authenticator-docs-4",
      "google-authenticator-gh-1",
      "google-authenticator-gh-3",
      "google-authenticator-comm-6",
      "google-authenticator-comm-7",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "passkey-storage-signin",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "All evidence describes Google Authenticator solely as a TOTP/HOTP code generator with cloud sync of codes; there is no mention of passkey storage or passkey-based sign-in anywhere in the docs, GitHub description, or community discussion.",
    "evidenceIds": [
      "google-authenticator-gh-1",
      "google-authenticator-docs-1",
      "google-authenticator-docs-4"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "privacy-no-training",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Google Authenticator lets users delete individual codes (swipe to delete), edit/reassign codes, and use the app without a Google account (avoiding cloud retention entirely), giving some control over what data is stored and removed. However, there is no documented account-level 'delete all my data' or data-export-to-file control, and community reports describe difficulty exporting/backing up codes and total data loss if a Google account is banned or deleted, undermining full user control over retention. missing for 10: explicit data export/portability controls, account-wide deletion/retention settings, and confirmation that deleting codes removes them from Google's backend, not just the local view.",
    "evidenceIds": [
      "google-authenticator-docs-8",
      "google-authenticator-docs-2",
      "google-authenticator-docs-9",
      "google-authenticator-comm-6",
      "google-authenticator-comm-17",
      "google-authenticator-comm-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "privacy-telemetry-optout",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any independent security audit of the app or its cloud sync protocol; a notable 2023 independent security researcher analysis found the sync data was unencrypted, but no formal published audit exists in the evidence pack, only community complaints about sync/backup reliability and trust concerns.",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "qr-totp-enrollment",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs and GitHub evidence confirm the app scans QR codes to add accounts and generates RFC 6238 TOTP codes, including offline (docs-3, docs-10, gh-1). Community feedback criticizes backup/sync/loss issues, not the basic scan-and-generate flow, so the core story is undisputed. Missing for 10: independent hands-on confirmation of the exact scan-to-first-code experience and no first-party UX walkthrough beyond support docs.",
    "evidenceIds": [
      "google-authenticator-docs-3",
      "google-authenticator-docs-10",
      "google-authenticator-gh-1",
      "google-authenticator-gh-2"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "self-host-sync-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "team-shared-vaults",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "google-authenticator",
    "storyId": "token-organization",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence only shows basic manual reordering (drag-to-reorder), swipe-to-edit/delete, and username/account editing — there is no mention of search, folders/groups, or service icons for organizing many tokens. missing for 10: search functionality, folder/group organization, service icons, any at-scale organization feature for dozens of tokens.",
    "evidenceIds": [
      "google-authenticator-docs-6",
      "google-authenticator-docs-7",
      "google-authenticator-docs-8",
      "google-authenticator-docs-12"
    ]
  },
  {
    "productId": "google-authenticator",
    "storyId": "watch-codes",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agent-code-retrieval",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a mobile app with no documented CLI or API for programmatic TOTP retrieval; evidence even indicates its QR codes are non-standard and reject other TOTP clients, and probes confirm no API/OpenAPI surface exists. No evidence of any automation-friendly access to codes.",
    "evidenceIds": [
      "microsoft-authenticator-comm-6",
      "microsoft-authenticator-probe-3",
      "microsoft-authenticator-probe-1"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agent-local-endpoint",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any local API, CLI, or programmatic endpoint for querying codes/secrets; probes confirm no llms.txt, docs-md, or OpenAPI endpoints exist, and the app is designed as a closed mobile experience with screen-capture disabled by default.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3",
      "microsoft-authenticator-docs-7"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agent-vault-provisioning",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any API, CLI, or programmatic surface for creating/updating vault entries or TOTP secrets; Microsoft Authenticator is a manual mobile app with QR-based account addition, and probes for API/docs endpoints returned 404s. missing for 10: any documented API/SDK/CLI for programmatic vault management, evidence of agent-accessible interfaces, confirmation of automated secret seeding.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3",
      "microsoft-authenticator-docs-8"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-agent-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Probes show no llms.txt, no markdown docs, and no OpenAPI spec available for Microsoft Authenticator's documentation site; there is no evidence of agent-oriented documentation format.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-ai-insights",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is an authentication/security app with no data-analysis or AI-insights feature set; generating AI-driven insights from user data is outside its category.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is an authentication/security app, not an AI assistant platform; no evidence of any built-in AI assistant or agent delegation feature. This capability is entirely outside the product's category.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-headless",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer authentication/MFA app, not an AI agent or platform with tool-use capability; plugging in MCP servers is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-official-cli",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-public-api",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer mobile app with no evidence of a documented public API for programmatic/AI-driven control; probes for llms.txt, docs-md, and OpenAPI specs all returned 404s.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-sdks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "agentic-webhooks",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer mobile authentication app, not a platform with an event/webhook subscription API; webhook subscriptions are a wrong axis for this product category.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "api-interactive-docs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer mobile authentication app, not a developer API/platform product; an interactive API reference with runnable examples is not a relevant axis for this product category.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer mobile app for authentication, not an API product, and no OpenAPI/machine-readable spec is offered; probes for openapi.json, llms.txt, and docs-md endpoints all returned 404.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer/enterprise authentication app, not a developer platform or API product; there is no concept of a sandbox environment for testing against it. This is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "app-lock",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs explicitly describe App Lock requiring device PIN or biometric authentication every time Authenticator is opened, directly matching the story. Missing for 10: independent/hands-on confirmation of App Lock reliability and default-on status.",
    "evidenceIds": [
      "microsoft-authenticator-docs-6",
      "microsoft-authenticator-docs-1"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "automation-bulk-operations",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is an authentication/MFA app, not a rules-engine or automation platform; there is no concept of user-defined event-triggered rules in its feature set. This axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is an identity/authentication app, not a workflow automation or job-scheduling tool; scheduling recurring jobs is outside its product category.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is an authentication app, not an automation/workflow tool with versionable automations to review or roll back — this axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "breach-alerting",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence that Microsoft Authenticator monitors for breached services or evaluates stored credentials for weakness/reuse/exposure; its password autofill feature is even being discontinued rather than expanded with security scanning. Missing for 10: breach monitoring, weak/reused password detection, exposed credential alerts.",
    "evidenceIds": [
      "microsoft-authenticator-comm-11"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "browser-extension-autofill",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence shows Microsoft Authenticator is a mobile app generating OTP codes and offering an in-app password Autofill feature, but there is no mention of a browser extension that autofills TOTP codes or passkeys, and community evidence indicates the password autofill feature itself is being discontinued entirely (comm-11), not extended to TOTP/passkey autofill.",
    "evidenceIds": [
      "microsoft-authenticator-docs-10",
      "microsoft-authenticator-docs-14",
      "microsoft-authenticator-comm-11"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "competitor-import",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack only covers backing up/restoring Authenticator's own accounts via cloud backup, exporting passwords, and standard account setup via QR/manual entry — there is no mention of any bulk-import feature for pulling tokens from other authenticator apps (e.g., Google Authenticator, Aegis) into Microsoft Authenticator. Community evidence even suggests the opposite direction problem (comm-6: MS's QR codes are non-standard so other apps reject them), reinforcing that cross-app portability isn't supported.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-6"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "desktop-app",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "All evidence describes Microsoft Authenticator as a mobile app (phone/wearable), with no mention of a desktop application for codes or vault access; the product is explicitly mobile-only.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "device-to-device-transfer",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Docs describe a guided backup/restore flow (enable Cloud Backup, then restore accounts on a new device) via microsoft-authenticator-docs-9/13, which is the core mechanism for the story. However, hands-on community evidence reports the process failing catastrophically — one user's update wiped all data and locked them out of every account (microsoft-authenticator-comm-1), while another user reports no such issue (microsoft-authenticator-comm-2), showing the reliability of the 'one guided step' transfer is contested rather than confirmed. Missing for 10: independent verification that restore reliably works across devices/OS versions, and no acknowledgment/fix from Microsoft for the reported data-loss bug.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-1",
      "microsoft-authenticator-comm-2"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "e2ee-backup",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Docs confirm a Cloud Backup feature exists (microsoft-authenticator-docs-9, -13) but provide no description of end-to-end encryption or a vendor-inaccessible key, and no encryption design documentation is cited anywhere. Community commentary even contrasts Microsoft's backup with an alternative app that explicitly offers 'encrypted backups' (microsoft-authenticator-comm-4), implying this property isn't established for Microsoft Authenticator.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-4"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "lost-phone-recovery",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Microsoft documents a Cloud Backup feature explicitly designed to restore accounts on a new device after phone loss (docs-9, docs-13), which matches the story's claim of a documented recovery path. However, a concrete hands-on community report describes the opposite outcome — an app update wiped all backed-up data and locked the user out of every account, with the poster citing it as a known reliability issue (comm-1, comm-3) — directly contradicting the documented recovery guarantee. missing for 10: independent verification that Cloud Backup restore reliably works, resolution of the reported wipe/lockout bug, and clarity on how backup interacts with app updates.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-1",
      "microsoft-authenticator-comm-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "multi-device-sync",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Docs describe Cloud Backup that lets you restore accounts to a new device (docs-9, docs-13), but this is backup/restore rather than true simultaneous multi-device sync across phone, tablet, and computer — there's no evidence of a tablet or desktop client. Community reports directly contradict reliability of this backup: users report Authenticator updates wiping all account data and causing lockouts (comm-1, comm-3), undermining the claim that data stays reliably available across devices. Missing for 10: evidence of simultaneous real-time sync across phone/tablet/desktop clients, and resolution of documented data-loss/backup failure reports.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-1",
      "microsoft-authenticator-comm-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "No evidence anywhere in the pack indicates Microsoft Authenticator supports HOTP counters, Steam Guard, or custom period/digit-length TOTP tokens; docs only describe standard push/OTP sign-in flows. Community evidence even suggests the opposite — its QR codes are non-standard TOTP and rejected by other clients, implying inflexibility rather than support for non-standard token types.",
    "evidenceIds": [
      "microsoft-authenticator-docs-12",
      "microsoft-authenticator-comm-6"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "offline-code-generation",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Microsoft's own docs claim codes work without an internet connection or phone service (microsoft-authenticator-docs-2), but hands-on community reports contradict this for real-world enterprise use: one user reports 'ms authenticator doesn't generate a code until I first log into the vpn using exchange creds' (microsoft-authenticator-comm-10), and another notes the app issues non-standard QR codes that lock users into the vendor's app rather than plain TOTP (microsoft-authenticator-comm-6), undermining the 'no vendor account required' and pure-offline claims for many real deployments. Missing for 10: independent technical verification of offline TOTP generation across account types, and confirmation that no Microsoft account/login is ever required to view codes.",
    "evidenceIds": [
      "microsoft-authenticator-docs-2",
      "microsoft-authenticator-comm-10",
      "microsoft-authenticator-comm-6",
      "microsoft-authenticator-comm-9"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "open-format-export",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Docs describe cloud backup/restore and password export/import, but none of this covers exporting TOTP secrets in an open format for use in another app; community evidence explicitly states Microsoft issues non-standard QR codes that other TOTP clients reject, indicating deliberate lock-in rather than portability.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-docs-10",
      "microsoft-authenticator-comm-6",
      "microsoft-authenticator-comm-4"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "open-source-clients",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence that Microsoft Authenticator's client code is open source; it is a closed, proprietary Microsoft product with no public repository or community code review mentioned anywhere in the evidence pack.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "openness-api-parity",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a consumer mobile app with no evidence of any public API for programmatic control of authentication actions; probes for API/docs endpoints all 404. No evidence supports API parity with UI functionality.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "openness-full-export",
    "verdict": "partial",
    "quality": 3,
    "confidence": "medium",
    "rationale": "Microsoft documents an 'Export Passwords' feature for autofill data, but this covers only saved passwords, not the OTP/account seeds this app is centrally used for; TOTP/account data is only preserved via proprietary encrypted 'Cloud Backup' tied to a Microsoft account, not an open, portable format. Community evidence goes further, describing non-standard QR codes that other TOTP clients reject and users switching to open-source alternatives (Aegis) specifically because Authenticator lacks true open-format export/backup. missing for 10: open-format export of TOTP secrets/accounts, documented data-portability/leave workflow, independent confirmation that exported data works outside Microsoft's ecosystem.",
    "evidenceIds": [
      "microsoft-authenticator-docs-10",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-docs-14",
      "microsoft-authenticator-comm-4",
      "microsoft-authenticator-comm-6"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "openness-open-license",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is closed-source proprietary software; no evidence of any open-license source availability, and probes for docs/API artifacts also failed.",
    "evidenceIds": [
      "microsoft-authenticator-probe-1",
      "microsoft-authenticator-probe-2",
      "microsoft-authenticator-probe-3"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "openness-self-host",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence only hints that notifications may be gated 'if allowed by your administrator' and that location-sharing is required for conditional access, but there is no documentation of an admin console or policy set that lets IT enforce app lock, restrict export, or mandate strong master credentials across all org members. Community evidence even suggests admins lack granular control tools (comm-6), reinforcing the absence of such enterprise policy enforcement in this pack.",
    "evidenceIds": [
      "microsoft-authenticator-docs-3",
      "microsoft-authenticator-docs-6",
      "microsoft-authenticator-docs-15",
      "microsoft-authenticator-comm-6"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack covers Microsoft Authenticator's TOTP codes, push-notification MFA, cloud backup, and password autofill (now being discontinued), but contains no mention of passkey creation, storage, or cross-platform/cross-vendor passkey syncing across iOS, Android, Windows, Linux, or browsers. Passkey sync is a fair axis for an authenticator app, but nothing in the pack demonstrates it.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-11"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "passkey-storage-signin",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "The evidence pack describes password-based sign-in removal, TOTP codes, push notifications, and password autofill/export, but nowhere mentions passkeys (FIDO2/WebAuthn credentials) being stored or used to sign into websites/apps. Missing for 10: any documentation of passkey creation, storage, or sign-in via Authenticator, and any independent confirmation of passkey support.",
    "evidenceIds": [
      "microsoft-authenticator-docs-1",
      "microsoft-authenticator-docs-11",
      "microsoft-authenticator-docs-12"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "phishing-resistant-push",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Evidence confirms admin-enforced push MFA policies (docs-3, comm-8, comm-9) and location-based context checks (docs-15), but there is no explicit mention of number matching as a phishing-resistant feature anywhere in the pack, and community threads focus on other issues (backup bugs, forced adoption) rather than validating anti-phishing controls. Missing for 10: number matching feature documentation, independent verification of phishing-resistance efficacy, and conditional access/policy configuration details for admins.",
    "evidenceIds": [
      "microsoft-authenticator-docs-3",
      "microsoft-authenticator-docs-15",
      "microsoft-authenticator-comm-8",
      "microsoft-authenticator-comm-9"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence Microsoft Authenticator offers any data residency/region selection controls for AI-native users; this is an authentication app, not a data-storage platform, but the story is arguably still applicable since it stores backups (cloud backup, account data) somewhere. No documentation mentions region choice or residency options.",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "privacy-no-training",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "The app offers a toggle for sharing non-personal usage data and lets users enable/disable cloud backup or export/delete stored passwords, giving some control over what data is retained, but there is no documented account/data deletion policy, retention period, or explicit 'delete my data' feature, and community reports note unexpected data loss/location tracking rather than user-controlled retention. missing for 10: explicit data retention/deletion policy, dedicated 'delete my account data' control, independent verification that deletion actually removes backend data.",
    "evidenceIds": [
      "microsoft-authenticator-docs-16",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-comm-5",
      "microsoft-authenticator-comm-1"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "privacy-telemetry-optout",
    "verdict": "disputed",
    "quality": 4,
    "confidence": "low",
    "rationale": "Microsoft's own docs mention an opt-in 'Usage Data' toggle that lets users control sharing of additional non-personal usage data, suggesting some telemetry control (microsoft-authenticator-docs-16). However, independent community reporting citing an Exodus Privacy audit says the app 'tracks your position all the time,' contradicting the notion that users can fully opt out of tracking (microsoft-authenticator-comm-5), and there is no documentation of a comprehensive telemetry/diagnostics opt-out beyond that single toggle. Missing for 10: explicit documentation of a full telemetry/diagnostics opt-out, first-party clarification of the location-tracking discrepancy, and independent verification that the toggle actually stops all usage tracking.",
    "evidenceIds": [
      "microsoft-authenticator-docs-16",
      "microsoft-authenticator-comm-5"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any published independent security audit of Microsoft Authenticator or its sync protocol; documentation only covers feature descriptions, and community threads discuss bugs, privacy concerns, and forced adoption but never an audit report. Missing for 10: any third-party audit report, pen-test disclosure, or vendor reference to an independent security assessment of the app or backup/sync protocol.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13",
      "microsoft-authenticator-comm-4",
      "microsoft-authenticator-comm-5"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "qr-totp-enrollment",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Microsoft's own docs confirm the app supports one-time-password codes for two-step verification (docs-12), implying QR-based account setup generates TOTP codes offline. However, hands-on community reports describe a known QR-scan bug that forces users to cancel the dialog and add accounts manually without the QR code (comm-3), and another user notes the QR codes Microsoft issues for its own accounts are non-standard and rejected by other TOTP clients (comm-6), directly contradicting a smooth 'scan and immediately generate' experience. missing for 10: no first-party doc walking through the exact 'add account via QR scan' flow, and no resolution/acknowledgment of the reported scan failures.",
    "evidenceIds": [
      "microsoft-authenticator-docs-12",
      "microsoft-authenticator-comm-3",
      "microsoft-authenticator-comm-6"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "self-host-sync-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "team-shared-vaults",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Microsoft Authenticator is a personal/individual authenticator app with no evidence of shared vaults, collections, or per-member access control for teams; its passwords feature is even being discontinued. Missing for 10: shared vault/collection feature, per-member access control, admin sharing management console.",
    "evidenceIds": [
      "microsoft-authenticator-comm-11",
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-docs-13"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "token-organization",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "No evidence describes organizational features like search, folders/groups, or per-account service icons for managing many tokens; docs cover backup, passwordless sign-in, and notifications but not organization/search UX. Community evidence even suggests account list issues (duplicate/overwrite concerns) rather than robust organization tools. Missing for full credit: any mention of search, folder/grouping, or icon-based organization of accounts.",
    "evidenceIds": [
      "microsoft-authenticator-docs-9",
      "microsoft-authenticator-comm-7"
    ]
  },
  {
    "productId": "microsoft-authenticator",
    "storyId": "watch-codes",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Docs confirm Authenticator notifications can be mirrored to a wearable device, which implies some code/approval visibility without pulling out the phone, but there's no explicit confirmation that time-based OTP codes themselves are readable on a smartwatch screen, nor any hands-on/community corroboration of this specific wearable experience. missing for 10: explicit documentation that OTP codes (not just approval notifications) display on smartwatch, independent/hands-on confirmation of the wearable experience.",
    "evidenceIds": [
      "microsoft-authenticator-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agent-code-retrieval",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Proton Pass ships an official CLI documented for scripting/CI-CD use that can 'securely retrieve secrets and other items' (docs-1/14) and lists item types it can read (docs-15), but TOTP/2FA codes are not explicitly named among the retrievable item types, and no docs or community evidence confirm a CLI/API command that outputs a live TOTP code for use in an automated login flow. missing for 10: explicit CLI/API command or output field for TOTP codes, hands-on confirmation of an agent successfully pulling a 2FA code programmatically.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-docs-5",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agent-local-endpoint",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Proton Pass ships an official CLI that allows secure programmatic retrieval of secrets, passwords, SSH keys, and other items across scripts and CI/CD pipelines, which functions as a local endpoint an agent could query instead of screen-scraping the app. However, the docs don't explicitly confirm TOTP/2FA code retrieval via the CLI (2FA generation is only described in the app itself), and there is no mention of an agent-specific or MCP-style interface, nor independent hands-on verification of CLI use by AI agents. Missing for 10: explicit CLI support for TOTP code retrieval, agent/MCP-oriented interface documentation, independent corroboration of CLI usage in agentic workflows.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-docs-5",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agent-vault-provisioning",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Proton Pass CLI documentation shows programmatic create/read/update/delete of items (including passwords, secure notes, SSH keys) and vaults, which an agent could invoke via scripts. However, there's no explicit mention of TOTP secret seeding via the CLI, and no dedicated agent/AI integration or API/SDK beyond the CLI is documented, and no independent confirmation of these CLI capabilities working reliably. Missing for 10: explicit TOTP-seeding support via CLI, broader API/SDK for agents, and independent hands-on verification of programmatic write operations.",
    "evidenceIds": [
      "proton-pass-docs-2",
      "proton-pass-docs-15",
      "proton-pass-docs-14",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-agent-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No llms.txt or agent-oriented docs found; probes explicitly return 404 for llms.txt and docs.md endpoints, and no evidence mentions agent-readable documentation formats.",
    "evidenceIds": [
      "proton-pass-probe-1",
      "proton-pass-probe-2"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-ai-insights",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence only covers password/vault management, monitoring, and Sentinel's fraud-detection AI for account security — none of this provides AI-generated insights or suggestions derived from the user's stored data (e.g., summarization, pattern detection, recommendations beyond breach/weak-password alerts). No feature described as generating insights or suggestions from the data itself.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-autonomous-automation",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-builtin-assistant",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager; no built-in AI assistant for task delegation exists in the evidence, and this capability is outside the product's category (only AI-related mentions are Proton Sentinel's fraud-detection use of AI, not an assistant users can delegate tasks to).",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-headless",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Proton Pass ships an official CLI documented as designed for scripts, deployments, and CI/CD pipelines, supporting CRUD on vaults and items — a clear headless/automation capability. However, evidence is limited to vendor blog docs with no independent/hands-on corroboration of CI usage, no details on authentication flow for non-interactive/headless environments, and no community validation of real-world CI deployment. Missing for 10: independent hands-on CI usage reports, details on non-interactive auth/session handling for automation, and broader ecosystem examples (e.g., GitHub Actions integration).",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-mcp-client",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager, not an AI agent or agent-serving platform; there is no evidence of MCP server functionality, and this axis is a category error for this product type.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-mcp-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-nl-commands",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass offers a CLI for scripted secret retrieval and CRUD operations, but there is no evidence of natural-language command support, AI assistant integration, or conversational interface anywhere in the docs or community discussion. Missing for 10: any NL command parsing, chat/AI interface, or agentic natural-language control.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-official-cli",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Proton Pass has an official CLI documented in a first-party blog post that supports CRUD on vaults and items (including SSH keys) and secret retrieval for scripts/CI/CD pipelines, which is directly relevant to AI-native/agentic automation workflows. Missing for 10: independent/hands-on corroboration of the CLI's reliability, no mention of AI-agent-specific integrations or MCP-style tooling, and no detail on scripting API depth or language bindings.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-public-api",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Proton Pass offers a CLI for CRUD operations on vaults and items (passwords, notes, SSH keys, etc.) usable in scripts/CI pipelines, which provides programmatic access, but this is a CLI wrapper rather than a documented public REST/GraphQL API with SDKs, and llms.txt/docs.md probes both 404. missing for 10: a formal public API specification (REST/GraphQL/SDK), API reference docs, and independent developer corroboration of programmatic/agentic use beyond the CLI.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-2",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-probe-1",
      "proton-pass-probe-2",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-scoped-keys",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Proton Pass CLI supports retrieving secrets/items for CI/CD and vault-level CRUD, but there is no evidence of issuing scoped or least-privilege API credentials/tokens specifically for an AI agent (e.g., fine-grained scopes, agent-specific permission tiers). Vaults provide organizational grouping, not credential scoping mechanisms for automated agents.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-2",
      "proton-pass-docs-14",
      "proton-pass-docs-15"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-sdks",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Evidence shows only a CLI tool for secrets retrieval in CI/CD pipelines, not a developer SDK for building applications; no mention of SDKs, API libraries, or language bindings for programmatic integration exists in the evidence pack.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "agentic-webhooks",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any webhook or event subscription mechanism; Proton Pass offers a CLI for CRUD operations but nothing about push/webhook notifications. Missing for 10: any webhook API, event subscription mechanism, or documentation referencing such a feature.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "api-interactive-docs",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of an interactive API reference or runnable examples; documentation covers CLI usage and product features only, and probes for docs/llms.txt endpoints returned 404. Missing for 10: interactive API reference, runnable code examples, developer API docs portal.",
    "evidenceIds": [
      "proton-pass-probe-1",
      "proton-pass-probe-2",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "api-machine-spec",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of a machine-readable API spec (OpenAPI or similar); only a CLI tool for scripts/CI/CD is documented, and probes for llms.txt and docs-md endpoints both returned 404.",
    "evidenceIds": [
      "proton-pass-probe-1",
      "proton-pass-probe-2",
      "proton-pass-docs-1"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "api-sandbox",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager, not a platform with sandbox/staging environments for testing against production-like data; this axis is a category error for its product type.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "api-versioning-policy",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "app-lock",
    "verdict": "none",
    "quality": 0,
    "confidence": "low",
    "rationale": "No evidence pack item mentions app-level biometric or PIN lock for Proton Pass; the closest related items cover offline vault access, 2FA/TOTP generation, and encryption, but none address a lock screen or app-level authentication gate. Missing for 10: any mention of biometric unlock, app PIN lock, or auto-lock timeout feature.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "automation-bulk-operations",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "The official CLI supports scripted CRUD on vaults and items (passwords, notes, SSH keys, etc.) which could be used to script bulk operations, and the import/export tools allow migrating many items at once. However, there is no documented explicit 'bulk edit/delete/tag' feature or batch API, and no community evidence of anyone actually scripting bulk operations at scale. Missing for 10: dedicated bulk-action API/UI, documented batch limits, and independent confirmation of large-scale scripted use.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-docs-2",
      "proton-pass-docs-3",
      "proton-pass-docs-11"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "automation-rules-engine",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager; defining automation rules that trigger actions on events is outside its product category (no workflow/automation engine exists), so this axis does not apply.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "automation-scheduled-jobs",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager with a CLI for secret retrieval in scripts/CI, not a workflow/job scheduling platform; scheduling recurring jobs is outside its product category.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "automation-versioned-workflows",
    "verdict": "na",
    "quality": 0,
    "confidence": "high",
    "rationale": "Proton Pass is a password manager, not an automation/workflow tool; versioning, reviewing, and rolling back 'automations' is not a concept that applies to its product category.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "breach-alerting",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Pass Monitor explicitly scans the dark web for credential leaks (breach detection), checks password health (weak/reused detection), and flags accounts missing 2FA, directly matching the story; this is documented as a core built-in feature rather than a third-party tool. Missing for 10: independent hands-on verification of Pass Monitor's accuracy/coverage and detail on exposed-credential alerting granularity beyond docs claims.",
    "evidenceIds": [
      "proton-pass-docs-6",
      "proton-pass-docs-12",
      "proton-pass-docs-7",
      "proton-pass-docs-13"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "browser-extension-autofill",
    "verdict": "full",
    "quality": 8,
    "confidence": "high",
    "rationale": "Docs confirm TOTP code generation for saved logins and passkey support, and community evidence from an actual user confirms the browser extension autofills TOTP/2FA smoothly ('Proton Pass is my default for all 2FA. I love the browser extension, so easy and sleek'). Passkey autofill is documented but not independently corroborated with hands-on testing. Missing for 10: independent hands-on confirmation of passkey autofill specifically, and more detail on passkey UX in the extension.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-docs-8",
      "proton-pass-comm-12",
      "proton-pass-comm-2"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "competitor-import",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Proton Pass documents a general import tool that migrates passwords and other items from most major password managers, and it can generate TOTP codes for saved logins, but there is no explicit evidence of bulk import specifically from dedicated authenticator apps or of preserving TOTP secrets during that import process. missing for 10: explicit documentation of bulk TOTP import from authenticator apps, confirmation that the import tool carries over 2FA secrets rather than just passwords, independent or hands-on confirmation of successful token migration.",
    "evidenceIds": [
      "proton-pass-docs-3",
      "proton-pass-docs-10",
      "proton-pass-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "desktop-app",
    "verdict": "disputed",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Proton's own support docs describe a dedicated desktop app with offline vault access and TOTP code generation (docs-9, docs-16, docs-5), suggesting a first-class desktop experience. However, community hands-on reports explicitly state there was no desktop app for Proton Pass ('And no desktop app for proton pass, maybe some day though?' and 'Pity it's only available on iOS and Android as apps and as browser extensions elsewhere'), directly contradicting the vendor's desktop-app documentation. Missing for 10: independent corroboration that the desktop app actually exists and works as described, and resolution of the timeline discrepancy between docs and community reports.",
    "evidenceIds": [
      "proton-pass-docs-9",
      "proton-pass-docs-16",
      "proton-pass-docs-5",
      "proton-pass-comm-2",
      "proton-pass-comm-14"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "device-to-device-transfer",
    "verdict": "partial",
    "quality": 3,
    "confidence": "low",
    "rationale": "Proton Pass stores TOTP secrets in E2E-encrypted vaults that sync via the cloud (docs-5, docs-9, docs-16), which implies that logging into a new phone would pull down existing 2FA tokens, but no evidence explicitly documents a guided 'new device setup' or migration wizard for phones. The only explicit migration flows described are import/export between different password manager products (docs-3, docs-4, docs-11), not device-to-device transfer. missing for 10: explicit documentation of a phone-to-phone onboarding/migration step, confirmation that TOTP tokens sync automatically without manual re-entry, and any hands-on account of switching phones.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-docs-9",
      "proton-pass-docs-16"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "e2ee-backup",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Proton Pass documents that all vault data is end-to-end encrypted (docs-10) and offers a PGP-encrypted export option that could serve as a backup (docs-11), implying the vendor cannot read backed-up data. However, there is no dedicated 'backup' feature documentation (only export/import), and no detailed cryptographic architecture whitepaper or independent audit is cited to substantiate the zero-knowledge key design in depth.\n\nmissing for 10: dedicated backup-feature docs, detailed encryption architecture/whitepaper, independent security audit confirming vendor never holds keys",
    "evidenceIds": [
      "proton-pass-docs-10",
      "proton-pass-docs-11",
      "proton-pass-docs-16"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "lost-phone-recovery",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Proton Pass stores TOTP codes and other secrets inside end-to-end encrypted vaults that live on Proton's servers (docs-5, docs-10), and offers export (docs-4/11) and Emergency Access (docs-20) features that could serve as backup/recovery mechanisms, implying data isn't lost with a device. However, there is no explicit documentation in the pack describing a dedicated 'lost phone / new device' recovery flow, account recovery phrase, or step-by-step restoration of 2FA tokens after device loss. Missing for 10: explicit account-recovery/recovery-phrase documentation, explicit cross-device sync confirmation, and a stated process for restoring TOTP secrets specifically after losing a device.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-docs-10",
      "proton-pass-docs-4",
      "proton-pass-docs-11",
      "proton-pass-docs-20"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "multi-device-sync",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Docs confirm cross-platform clients (mobile apps, browser extensions, and a desktop app referenced in the desktop-app guide) and offline access that presumably reconciles when back online, implying cloud sync of vault items including TOTP tokens. However, no first-party documentation explicitly describes the sync mechanism or guarantees real-time multi-device consistency, and community comments note a historical lack of a desktop app and inconsistent browser-extension availability (e.g., Firefox ESR incompatibility), suggesting platform coverage has been uneven over time. Missing for 10: explicit sync/consistency documentation, independent verification that sync is truly automatic and near-instant across phone/tablet/computer.",
    "evidenceIds": [
      "proton-pass-docs-9",
      "proton-pass-docs-5",
      "proton-pass-comm-2",
      "proton-pass-comm-14",
      "proton-pass-comm-7"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "nonstandard-token-support",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "Evidence only confirms basic TOTP code generation for saved logins; no mention of Steam Guard tokens, HOTP counters, or custom period/digit length support anywhere in the docs or community discussion. Missing for 10: any documentation of Steam Guard support, HOTP counter-based tokens, or custom TOTP period/digit configuration.",
    "evidenceIds": [
      "proton-pass-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "offline-code-generation",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "Proton Pass is fundamentally an account-based, encrypted-vault service — using it at all requires creating and logging into a Proton account, and TOTP codes are stored as fields within account-synced vaults. Evidence only shows that once logged in, offline access to already-synced vaults works (proton-pass-docs-9), but nothing supports generating/viewing TOTP codes without ever creating or authenticating a vendor account, which the story explicitly requires.",
    "evidenceIds": [
      "proton-pass-docs-9",
      "proton-pass-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "open-format-export",
    "verdict": "partial",
    "quality": 5,
    "confidence": "low",
    "rationale": "Proton Pass docs confirm a general data-export feature with multiple output options (PGP-encrypted ZIP, unencrypted ZIP, CSV), which supports the 'open, readable format' portability need, but no evidence explicitly confirms that TOTP secrets/seeds specifically are included in these exports (as opposed to being locked to Proton's own TOTP display). No community or hands-on report verifies successful TOTP secret export and re-import elsewhere. missing for 10: explicit confirmation that TOTP seeds are included in CSV/JSON export, independent verification that exported TOTP secrets can be imported into another app.",
    "evidenceIds": [
      "proton-pass-docs-4",
      "proton-pass-docs-11",
      "proton-pass-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "open-source-clients",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Community evidence confirms Proton Pass clients are open source with a public GitHub repo (github.com/protonpass), directly supporting inspectability of the code handling secrets. However, other community comments show confusion/skepticism about finding or verifying this ('haven't been able to find the repository', 'it seems only the clients are open source'), and there's no first-party doc in the pack explicitly stating open-source status or citing security audits. Missing for 10: first-party documentation confirming open-source licensing/repo, evidence of independent security audits or community code review of the seed-handling logic, and clarity on scope (client-only vs. broader).",
    "evidenceIds": [
      "proton-pass-comm-6",
      "proton-pass-comm-3",
      "proton-pass-comm-4"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "openness-api-parity",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Proton Pass ships a CLI/API that supports CRUD on vaults and items (passwords, notes, cards, identities, SSH keys, custom items), enabling scripted/CI access similar to core UI functions. However, there's no evidence the CLI/API exposes other UI capabilities like vault sharing, TOTP generation, Pass Monitor/Sentinel checks, alias management, or emergency access. Missing for 10: API coverage for sharing, TOTP/2FA, monitoring, aliases, emergency access, and any independent confirmation of API completeness.",
    "evidenceIds": [
      "proton-pass-docs-1",
      "proton-pass-docs-2",
      "proton-pass-docs-14",
      "proton-pass-docs-15",
      "proton-pass-probe-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "openness-full-export",
    "verdict": "full",
    "quality": 7,
    "confidence": "medium",
    "rationale": "Proton Pass supports data export in multiple open, portable formats (unencrypted ZIP, CSV, PGP-encrypted JSON) allowing users to leave with their data, and also offers an import tool for migrating in from other managers. Missing for 10: independent hands-on verification of export completeness/fidelity, and no evidence of bulk API/CLI-based export for programmatic 'leave' workflows beyond CLI CRUD operations.",
    "evidenceIds": [
      "proton-pass-docs-4",
      "proton-pass-docs-11",
      "proton-pass-docs-3"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "openness-open-license",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Community evidence confirms Proton Pass client apps are open source on GitHub (protonpass org), but users note this covers only the clients, not the full product/server-side, and there was confusion over whether it was truly open-sourced. No first-party docs in the pack mention a license or open-source repo at all. Missing for 10: official documentation citing the open-source license, confirmation that server/backend code is open, and clarity on license terms.",
    "evidenceIds": [
      "proton-pass-comm-3",
      "proton-pass-comm-4",
      "proton-pass-comm-6"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "openness-self-host",
    "verdict": "none",
    "quality": 0,
    "confidence": "medium",
    "rationale": "No evidence anywhere in the docs pack of a self-hosted server option; Proton Pass is offered only as a hosted SaaS with client apps, and community comments confirm only the client apps are open source while the backend/server is closed ('only the clients are open source').",
    "evidenceIds": [
      "proton-pass-comm-3",
      "proton-pass-comm-4"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "org-policy-controls",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of org-wide admin policy controls (enforced app lock, export restrictions, mandated master password strength) for organization members; docs cover vaults, CLI, export, 2FA, sharing but nothing about admin-enforced policies across a team.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "passkey-cross-ecosystem",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Proton Pass confirms passkey support (proton-pass-docs-8) and offers apps across iOS, Android, browsers, and a desktop app (with offline access per proton-pass-docs-9), implying cross-platform sync of vault items including passkeys. However, there's no explicit documentation confirming passkeys specifically sync across all platforms (vs. just being stored), and community comments note desktop app limitations/lack thereof at the time (proton-pass-comm-2, proton-pass-comm-14), raising doubt about full ecosystem parity. Missing for 10: explicit cross-platform passkey sync confirmation, Linux/Windows native app evidence beyond browser extensions, and independent hands-on verification that passkeys created on one platform are usable on another.",
    "evidenceIds": [
      "proton-pass-docs-8",
      "proton-pass-docs-9",
      "proton-pass-comm-2",
      "proton-pass-comm-14"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "passkey-storage-signin",
    "verdict": "partial",
    "quality": 6,
    "confidence": "medium",
    "rationale": "Docs confirm Proton Pass supports passkeys for passwordless authentication and separately supports TOTP code generation, indicating both capabilities coexist rather than TOTP-only. However, there is no detailed description of the sign-in autofill flow for passkeys or independent/hands-on confirmation that passkey sign-in works reliably across sites/apps. Missing for 10: hands-on/community validation of passkey autofill and sign-in success, cross-platform passkey sync confirmation, and detail on browser/app integration for passkey use.",
    "evidenceIds": [
      "proton-pass-docs-8",
      "proton-pass-docs-5"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "phishing-resistant-push",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "privacy-data-residency",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence pack item mentions data residency, regional data storage options, or any control over where user data is physically stored; Proton Pass docs cover encryption, vaults, CLI, and export but not region selection. Missing for 10: any documentation of data residency/region choice, EU-only or multi-region storage options, or admin controls for data location.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "privacy-no-training",
    "verdict": "partial",
    "quality": 4,
    "confidence": "low",
    "rationale": "Proton Pass's end-to-end encryption of all vault fields (docs-10) structurally means Proton cannot access plaintext user data, which would prevent it from being used to train AI models, but there is no explicit policy statement addressing AI training data use. Missing for 10: an explicit privacy policy or documentation statement about AI training opt-out/data usage, and independent confirmation of this claim.",
    "evidenceIds": [
      "proton-pass-docs-10"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "privacy-retention-controls",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Docs show users can create/read/update/delete vaults and items via the CLI/app, and can export or migrate data before deleting it, giving concrete control over stored data. However there is no explicit documentation on account-level data retention policies, deletion timelines, or how long Proton retains deleted data, which is central to a full 'control retention and deletion' story. Missing for 10: explicit retention-period/account-deletion policy documentation, independent confirmation that deleted data is purged.",
    "evidenceIds": [
      "proton-pass-docs-2",
      "proton-pass-docs-15",
      "proton-pass-docs-4",
      "proton-pass-docs-11"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "privacy-telemetry-optout",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Community evidence confirms telemetry exists in the browser extension and can be disabled, but only via Proton account settings, not directly within the extension itself, indicating a real but limited opt-out mechanism (proton-pass-comm-13). No first-party documentation from Proton Pass describes a formal telemetry/opt-out policy or setting. missing for 10: official docs on telemetry settings, in-extension opt-out toggle, confirmation of no tracking by default.",
    "evidenceIds": [
      "proton-pass-comm-13"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "published-audits",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of any independent third-party security audit report, pentest, or audit of the sync protocol; evidence only covers feature docs (encryption claims, Sentinel, Monitor) and open-source status debates in community threads. Community comments even question whether the client is fully open source, but no audit report is cited or linked anywhere.",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "qr-totp-enrollment",
    "verdict": "partial",
    "quality": 5,
    "confidence": "medium",
    "rationale": "Docs confirm Proton Pass generates TOTP codes for saved logins (proton-pass-docs-5) and community reports use it as their default 2FA tool (proton-pass-comm-12), but no evidence explicitly describes scanning a QR code to add a new TOTP secret and instantly getting codes. Missing for 10: explicit QR-code scanning workflow documentation, mobile camera scan support evidence, and independent hands-on confirmation of the scan-to-code flow.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-comm-12"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "self-host-sync-server",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)",
    "evidenceIds": []
  },
  {
    "productId": "proton-pass",
    "storyId": "team-shared-vaults",
    "verdict": "partial",
    "quality": 5,
    "confidence": "low",
    "rationale": "Evidence confirms Proton Pass supports TOTP/2FA generation for saved logins (docs-5) and secure vault sharing plus vault-based organization of items (docs-16, docs-17), which together imply TOTP items can be shared via vaults. However, there is no documentation of granular per-member access control (roles/permissions) or 'collections' as a distinct sharing unit, and no team-admin console evidence for managing member access levels within shared vaults. Missing for 10: explicit permission-level (viewer/editor/admin) documentation for shared vaults, evidence of 'collections' as an admin feature, and any IT-admin console showing per-member access management.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-docs-16",
      "proton-pass-docs-17"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "token-organization",
    "verdict": "partial",
    "quality": 4,
    "confidence": "medium",
    "rationale": "Proton Pass supports TOTP generation tied to saved logins and vaults for organizing items into groups (e.g., personal vs. work), but there is no evidence of search functionality or service icons, and a community report explicitly notes the browser popup overlay was inadequate for managing hundreds of logins, suggesting scaling friction for power users. Missing for 10: dedicated TOTP search/filter feature, service icon display, and evidence of smooth navigation across dozens of tokens.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-docs-16",
      "proton-pass-comm-10"
    ]
  },
  {
    "productId": "proton-pass",
    "storyId": "watch-codes",
    "verdict": "none",
    "quality": 0,
    "confidence": "high",
    "rationale": "No evidence of a smartwatch app, watch companion, or complication for viewing TOTP codes; evidence only covers mobile, browser extension, and CLI surfaces, with community notes even lamenting lack of a desktop app. Missing for 10: any smartwatch app/companion, watch complication, or documentation of viewing codes without the phone.",
    "evidenceIds": [
      "proton-pass-docs-5",
      "proton-pass-comm-14"
    ]
  }
]
