{
  "fixes": {
    "slug": "haven",
    "name": "Haven",
    "listing": "https://www.anchorterminal.com/tools/haven",
    "markdown": "# Fix list: Haven\n\nFrom Anchor Terminal's listing at https://www.anchorterminal.com/tools/haven, the October 2026 research run, assessed 12 October 2026. Grade F, 22.2 out of 100.\n\nThis is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.\n\nFor a coding agent working on Haven: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.\n\n## 1. Schema \u0026 documentation, 4 out of 100, up to 15.6 more on the total\n\nWhy it scored 4: Haven has no API, MCP server or developer documentation on the pages read, so most lines score absent. No machine-readable contract (0). /llms.txt answered 404 (0). The FAQ and home page describe what the assistant does in general terms, with no account of which actions it takes or when (4 of 20). No typed inputs (0). No examples or error documentation, and the one help article we opened from the sitemap showed a not-found page (0). No versioning or changelog (0).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):\n\nAPIs and MCP servers.\n\n- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).\n- 10, llms.txt or Markdown docs served for agents.\n- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.\n- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.\n- 0 to 15, examples and documented error responses.\n- 15, versioning and a public changelog.\n\nModels are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.\n\n## 2. Agent ergonomics, 6 out of 100, up to 15.3 more on the total\n\nWhy it scored 6: No programmatic surface, so the lines are read against what an agent or its owner can do through the channels. Nothing sizes or filters replies (0 of 25, 0 of 20). No error documentation (0). No retry or idempotency guidance for tasks such as orders or sent messages (0). An account needs no setup beyond a call, text or email, and recurring tasks are set in plain language per the press release, with no SDK (6 of 15).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):\n\n- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).\n- 20, pagination, filtering and output-size controls.\n- 20, actionable, documented error responses, codes and messages an agent can recover from.\n- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.\n- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.\n\nModels are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.\n\n## 3. Security \u0026 auth, 13 out of 100, up to 15.2 more on the total\n\nWhy it scored 13: The sign-in method was not read, and no scopes, token storage or revocation for connected accounts were found. The privacy policy says credentials for connected services are shared with those providers and that the vendor's own keys sit in server-side environment variables (5 of 30). No read-only mode or approval control is documented. Outbound email is labelled as sent on the user's behalf and impersonation is forbidden (3 of 20). Haven reads mail and web pages, and no prompt-injection guidance was found beyond the home page's words safety tested (0 of 15). Memory can be browsed in the app, but no log of actions taken was found (2 of 15). Encryption in transit and at rest is claimed. No security.txt, disclosure policy, bounty or certification was found (3 of 20).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-security):\n\n- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.\n- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.\n- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.\n- 0 to 15, audit logs or per-call visibility for the operator.\n- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.\n\nModels are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.\n\n## 4. Reliability, 35 out of 100, up to 13 more on the total\n\nWhy it scored 35: Read with the hosted lines. Statuspage site at status.hellohaven.ai with eight components (20). In the 90 days to 12 October 2026 the feed has one incident, phone and app voice down on 15 August 2026 from a billing issue with a provider, with no duration given. Voice is one of six channels, so we read it between minor and major (15 of 30). The FAQ says there are no usage limits and no rate limit was found (0). No overload or retry guidance (0). No SLA, and the terms say there are no guarantees of delivery, accuracy or uninterrupted service (0). The service is in beta (0).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):\n\nHosted APIs, MCP servers, models and platforms.\n\n- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).\n- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.\n- 15, rate limits documented with numbers.\n- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.\n- 10, an SLA published for any paid tier.\n- 10, the surface agents use is generally available, not beta or preview.\n\nLocal packages, SDKs, frameworks and stdio MCP servers.\n\n- 20, installs from an official package with supported runtimes stated.\n- 25, a public CI and test suite, passing on the default branch.\n- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).\n- 15, semver discipline and breaking changes called out in a changelog.\n- 15, version 1.0 or later, or declared stable.\n\nProtocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.\n\n## 5. Payments \u0026 pricing, 30 out of 100, up to 8.8 more on the total\n\nWhy it scored 30: No machine payment protocol (0). The price today is published without a login (free in beta), and future prices are not set, which we read as public plan-only pricing (10). Free with no card (20). A person has to sign up with an invite code or phone the number, so no autonomous onboarding (0).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):\n\nThe published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).\n\n- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.\n- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for \"contact sales\" or prices behind a login.\n- 20, a free tier or trial that doesn't need a card.\n- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).\n\nPayment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.\n\nOpen-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.\n\n## 6. Maintenance \u0026 community, 35 out of 100, up to 5.7 more on the total\n\nWhy it scored 35: The public launch was announced on 17 September 2026, 25 days before this check, and we count it as the last dated release (30). No changelog or release notes were found, so no three dated entries in 90 days (0). A support form, a community site linked from the status page (not read) and status incidents that were answered and closed, with no changelog (5 of 15). No SDK and no registry entry (0). No package to assess, and app store version histories were not read (0).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):\n\n- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.\n- 20, at least three releases or dated changelog entries in the last 90 days.\n- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.\n- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).\n- 10, package health, current dependencies and CI.\n\nModels are read for deprecation notice periods and model churn rather than release counts.\n\n## 7. Transparency \u0026 trust, 51 out of 100, up to 4.3 more on the total\n\nMade of editorial 37, provenance 64.\n\nWhy it scored 51: Closed source under short terms that name the entity and governing law (15). The privacy policy lists what is collected and categories of recipients, keeps data while the account is active, and the data page gives deletion from backups within 30 days. The home page says Haven is never trained on the user, which neither legal document repeats, and the FAQ's vetted providers are unnamed (14 of 30). The FAQ promises notice before charging starts, while the terms allow suspension or change at any time with no notice period (3 of 20). Sub-processors are listed by category with the full list on request, and no data location is stated (5 of 20).\n\nThe checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):\n\n- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.\n- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).\n- 0 to 20, a deprecation policy or notices with dates.\n- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).\n\nThe other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.\n\nProvenance checks not met in full (half of this category, computed from checked facts):\n\n- Domain age: hellohaven.ai, registered 2024-11-21 (1 year) (3 of 15)\n- Terms of service: read, states 5 of the 7 things a reader expects (8.3 of 10)\n- Privacy policy: read, states 5 of the 8 things a reader expects (7.8 of 10)\n- Changelog: not found (0 of 10)\n- security.txt: not found (0 of 10)\n\n## What we couldn't check\n\nWhat we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.\n\n- Kind is `platform`. Haven is a hosted consumer app reached by phone, text, email, web and mobile, with no API or MCP server, so no other kind fits. Graded as a hosted service.\n- The lead's only address was a press release. The release links my.hellohaven.ai/meethaven, and every fact here other than the announcement comes from that site, its status page, RDAP and GitHub.\n- The lead said Haven performs tasks through connected services. The terms confirm connections by type only. The 500 models and 100 integrations are the press release's figures and were not confirmed on the site.\n- my.hellohaven.ai is drawn by script. A plain request returned an empty page for /meethaven and /plans, while our page reader received full text for the other pages. Wording quoted from those pages passed through that reader's summary and should be checked against the pages before publishing. No script bundle was read.\n- unchecked: the app at app.hellohaven.ai (sign-in method, approval settings, the list of connectable accounts and their scopes, memory controls as built). It is behind a sign-in and we sent it nothing.\n- unchecked: the incident history page on status.hellohaven.ai (script-drawn). The linked Atom feed was read in its place. Uptime figures were not read.\n- unchecked: community.hellohaven.ai, the App Store and Google Play pages (version history, data safety labels), and the /press, /company, /contact, /gethaven and other blog pages.\n- unchecked: whether content is used to train models. The home page says never, and the terms and privacy policy were silent as our reader reported them.\n- Maintenance counts the launch of 17 September 2026 as the last dated release. With no changelog, a strict reading that wants a release note would give 0 on that line and a total of 5.\n- Reliability reads the 15 August 2026 voice outage as between minor and major because no duration is given. Read as a major outage the line is 10, not 15.\n- Slip, disclosed. The RDAP lookup at rdap.org redirected to rdap.identitydigital.services before that host's robots.txt was read. The answer is used for the registration date only.\n- The interface cannot be read without an account and three scores (schema, ergonomics, security) rest mostly on absence. Under the batch 8 rule this listing may belong in held/.\n\n## Weaknesses\n\n- No approval setting or list of actions that need confirmation was found on the public pages. The terms say it sends emails, SMS and calls following the user's instructions.\n- Connected accounts are described only by type (email, calendar, cloud storage, messaging). No provider names, scopes or token storage statement were found.\n- Model providers and sub-processors are listed by category only. The policy says the list is available on request by email.\n- No API, MCP server, developer docs, changelog, security.txt or disclosure policy was found. The press release says a developer platform is planned.\n- Two voice outages (23 May and 15 August 2026) were caused by billing errors with a provider, per the status page.\n- The terms allow the vendor to suspend, modify or terminate the service at any time, and say continued use accepts updated terms.\n\n## What costs an agent a turn today\n\nThe notes we give agents before they call it. Each one is a workaround an agent shouldn't need.\n\n- Haven has no documented API or MCP server. An outside agent can reach it only through the owner's channels (call, SMS, email, app).\n- Do not assume an approval step before Haven sends mail, texts or calls. None is documented on the public pages.\n- Email Haven sends to other people names Hello Haven as sender and says it was sent on the user's behalf, per the terms.\n- Chat messages, history, profile context and uploaded files go to third-party AI model providers that the vendor does not name.\n- Check status.hellohaven.ai before relying on phone or voice. All four published incidents affected those channels.\n\n## When it's done\n\nSend what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `\"kind\": \"dispute\"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.\n",
    "grade": "F",
    "score": 22.2,
    "assessed": "2026-10-12",
    "run": "October 2026 research run",
    "categories": [
      {
        "key": "schema",
        "name": "Schema \u0026 documentation",
        "score": 4,
        "maxGain": 15.6,
        "reason": "Haven has no API, MCP server or developer documentation on the pages read, so most lines score absent. No machine-readable contract (0). /llms.txt answered 404 (0). The FAQ and home page describe what the assistant does in general terms, with no account of which actions it takes or when (4 of 20). No typed inputs (0). No examples or error documentation, and the one help article we opened from the sitemap showed a not-found page (0). No versioning or changelog (0).",
        "checklist": [
          "APIs and MCP servers.",
          "- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).\n- 10, llms.txt or Markdown docs served for agents.\n- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.\n- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.\n- 0 to 15, examples and documented error responses.\n- 15, versioning and a public changelog.",
          "Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-schema"
      },
      {
        "key": "ergonomics",
        "name": "Agent ergonomics",
        "score": 6,
        "maxGain": 15.3,
        "reason": "No programmatic surface, so the lines are read against what an agent or its owner can do through the channels. Nothing sizes or filters replies (0 of 25, 0 of 20). No error documentation (0). No retry or idempotency guidance for tasks such as orders or sent messages (0). An account needs no setup beyond a call, text or email, and recurring tasks are set in plain language per the press release, with no SDK (6 of 15).",
        "checklist": [
          "- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).\n- 20, pagination, filtering and output-size controls.\n- 20, actionable, documented error responses, codes and messages an agent can recover from.\n- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.\n- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.",
          "Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-ergonomics"
      },
      {
        "key": "security",
        "name": "Security \u0026 auth",
        "score": 13,
        "maxGain": 15.2,
        "reason": "The sign-in method was not read, and no scopes, token storage or revocation for connected accounts were found. The privacy policy says credentials for connected services are shared with those providers and that the vendor's own keys sit in server-side environment variables (5 of 30). No read-only mode or approval control is documented. Outbound email is labelled as sent on the user's behalf and impersonation is forbidden (3 of 20). Haven reads mail and web pages, and no prompt-injection guidance was found beyond the home page's words safety tested (0 of 15). Memory can be browsed in the app, but no log of actions taken was found (2 of 15). Encryption in transit and at rest is claimed. No security.txt, disclosure policy, bounty or certification was found (3 of 20).",
        "checklist": [
          "- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.\n- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.\n- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.\n- 0 to 15, audit logs or per-call visibility for the operator.\n- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.",
          "Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-security"
      },
      {
        "key": "reliability",
        "name": "Reliability",
        "score": 35,
        "maxGain": 13,
        "reason": "Read with the hosted lines. Statuspage site at status.hellohaven.ai with eight components (20). In the 90 days to 12 October 2026 the feed has one incident, phone and app voice down on 15 August 2026 from a billing issue with a provider, with no duration given. Voice is one of six channels, so we read it between minor and major (15 of 30). The FAQ says there are no usage limits and no rate limit was found (0). No overload or retry guidance (0). No SLA, and the terms say there are no guarantees of delivery, accuracy or uninterrupted service (0). The service is in beta (0).",
        "checklist": [
          "Hosted APIs, MCP servers, models and platforms.",
          "- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).\n- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.\n- 15, rate limits documented with numbers.\n- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.\n- 10, an SLA published for any paid tier.\n- 10, the surface agents use is generally available, not beta or preview.",
          "Local packages, SDKs, frameworks and stdio MCP servers.",
          "- 20, installs from an official package with supported runtimes stated.\n- 25, a public CI and test suite, passing on the default branch.\n- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).\n- 15, semver discipline and breaking changes called out in a changelog.\n- 15, version 1.0 or later, or declared stable.",
          "Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-reliability"
      },
      {
        "key": "payments",
        "name": "Payments \u0026 pricing",
        "score": 30,
        "maxGain": 8.8,
        "reason": "No machine payment protocol (0). The price today is published without a login (free in beta), and future prices are not set, which we read as public plan-only pricing (10). Free with no card (20). A person has to sign up with an invite code or phone the number, so no autonomous onboarding (0).",
        "checklist": [
          "The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).",
          "- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.\n- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for \"contact sales\" or prices behind a login.\n- 20, a free tier or trial that doesn't need a card.\n- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).",
          "Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.",
          "Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-payments"
      },
      {
        "key": "maintenance",
        "name": "Maintenance \u0026 community",
        "score": 35,
        "maxGain": 5.7,
        "reason": "The public launch was announced on 17 September 2026, 25 days before this check, and we count it as the last dated release (30). No changelog or release notes were found, so no three dated entries in 90 days (0). A support form, a community site linked from the status page (not read) and status incidents that were answered and closed, with no changelog (5 of 15). No SDK and no registry entry (0). No package to assess, and app store version histories were not read (0).",
        "checklist": [
          "- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.\n- 20, at least three releases or dated changelog entries in the last 90 days.\n- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.\n- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).\n- 10, package health, current dependencies and CI.",
          "Models are read for deprecation notice periods and model churn rather than release counts."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-maintenance"
      },
      {
        "key": "transparency",
        "name": "Transparency \u0026 trust",
        "score": 51,
        "maxGain": 4.3,
        "reason": "Closed source under short terms that name the entity and governing law (15). The privacy policy lists what is collected and categories of recipients, keeps data while the account is active, and the data page gives deletion from backups within 30 days. The home page says Haven is never trained on the user, which neither legal document repeats, and the FAQ's vetted providers are unnamed (14 of 30). The FAQ promises notice before charging starts, while the terms allow suspension or change at any time with no notice period (3 of 20). Sub-processors are listed by category with the full list on request, and no data location is stated (5 of 20).",
        "blend": "editorial 37, provenance 64",
        "checklist": [
          "- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.\n- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).\n- 0 to 20, a deprecation policy or notices with dates.\n- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).",
          "The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two."
        ],
        "checklistUrl": "https://www.anchorterminal.com/benchmark/#checklist-transparency"
      }
    ],
    "provenance": [
      {
        "label": "Domain age",
        "value": "hellohaven.ai, registered 2024-11-21 (1 year)",
        "points": 3,
        "max": 15
      },
      {
        "label": "Terms of service",
        "value": "read, states 5 of the 7 things a reader expects",
        "points": 8.3,
        "max": 10
      },
      {
        "label": "Privacy policy",
        "value": "read, states 5 of the 8 things a reader expects",
        "points": 7.8,
        "max": 10
      },
      {
        "label": "Changelog",
        "value": "not found",
        "points": 0,
        "max": 10
      },
      {
        "label": "security.txt",
        "value": "not found",
        "points": 0,
        "max": 10
      }
    ],
    "unchecked": [
      "Kind is `platform`. Haven is a hosted consumer app reached by phone, text, email, web and mobile, with no API or MCP server, so no other kind fits. Graded as a hosted service.",
      "The lead's only address was a press release. The release links my.hellohaven.ai/meethaven, and every fact here other than the announcement comes from that site, its status page, RDAP and GitHub.",
      "The lead said Haven performs tasks through connected services. The terms confirm connections by type only. The 500 models and 100 integrations are the press release's figures and were not confirmed on the site.",
      "my.hellohaven.ai is drawn by script. A plain request returned an empty page for /meethaven and /plans, while our page reader received full text for the other pages. Wording quoted from those pages passed through that reader's summary and should be checked against the pages before publishing. No script bundle was read.",
      "unchecked: the app at app.hellohaven.ai (sign-in method, approval settings, the list of connectable accounts and their scopes, memory controls as built). It is behind a sign-in and we sent it nothing.",
      "unchecked: the incident history page on status.hellohaven.ai (script-drawn). The linked Atom feed was read in its place. Uptime figures were not read.",
      "unchecked: community.hellohaven.ai, the App Store and Google Play pages (version history, data safety labels), and the /press, /company, /contact, /gethaven and other blog pages.",
      "unchecked: whether content is used to train models. The home page says never, and the terms and privacy policy were silent as our reader reported them.",
      "Maintenance counts the launch of 17 September 2026 as the last dated release. With no changelog, a strict reading that wants a release note would give 0 on that line and a total of 5.",
      "Reliability reads the 15 August 2026 voice outage as between minor and major because no duration is given. Read as a major outage the line is 10, not 15.",
      "Slip, disclosed. The RDAP lookup at rdap.org redirected to rdap.identitydigital.services before that host's robots.txt was read. The answer is used for the registration date only.",
      "The interface cannot be read without an account and three scores (schema, ergonomics, security) rest mostly on absence. Under the batch 8 rule this listing may belong in held/."
    ],
    "weaknesses": [
      "No approval setting or list of actions that need confirmation was found on the public pages. The terms say it sends emails, SMS and calls following the user's instructions.",
      "Connected accounts are described only by type (email, calendar, cloud storage, messaging). No provider names, scopes or token storage statement were found.",
      "Model providers and sub-processors are listed by category only. The policy says the list is available on request by email.",
      "No API, MCP server, developer docs, changelog, security.txt or disclosure policy was found. The press release says a developer platform is planned.",
      "Two voice outages (23 May and 15 August 2026) were caused by billing errors with a provider, per the status page.",
      "The terms allow the vendor to suspend, modify or terminate the service at any time, and say continued use accepts updated terms."
    ],
    "agentNotes": [
      "Haven has no documented API or MCP server. An outside agent can reach it only through the owner's channels (call, SMS, email, app).",
      "Do not assume an approval step before Haven sends mail, texts or calls. None is documented on the public pages.",
      "Email Haven sends to other people names Hello Haven as sender and says it was sent on the user's behalf, per the terms.",
      "Chat messages, history, profile context and uploaded files go to third-party AI model providers that the vendor does not name.",
      "Check status.hellohaven.ai before relying on phone or voice. All four published incidents affected those channels."
    ],
    "recheck": "https://www.anchorterminal.com/builders/#disputes"
  },
  "meta": {
    "attribution": "Anchor Terminal (https://www.anchorterminal.com)",
    "docs": "https://www.anchorterminal.com/docs/",
    "generatedAt": "2026-10-12",
    "license": "CC-BY-4.0",
    "method": "https://www.anchorterminal.com/benchmark/",
    "methodology": "0.4",
    "openapi": "https://www.anchorterminal.com/openapi.json",
    "preview": false,
    "run": "2026-10-01",
    "runLabel": "October 2026 research run"
  }
}