Carta vs Ledgy

Agent access

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

   weight 2 · round drawn
   Carta—none0/10

   Direct probes show no llms.txt file (404) and no machine-readable docs or OpenAPI spec discoverable at expected paths, meaning there's no agent-oriented docs entrypoint for an AI agent to point at; the MCP setup guide is a separate integration path, not an llms.txt/agent-docs format.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.carta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.carta.com/api-platform/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy—none0/10

   A direct probe found no llms.txt (404) and no discoverable OpenAPI/agent-oriented docs at standard locations, and no evidence pack item mentions an agent-facing docs format.

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

   proof ↗⚑ flag

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

   weight 2 · round to Ledgy
   Carta~partialprobed4/10

   Carta exposes a REST API with OAuth2 CLIENT_CREDENTIALS grant (machine-to-machine, no user interaction), which supports scripted/automated access suitable for CI-like use, and offers Postman guides for programmatic access. However, there is no evidence of a CLI, SDK, headless runner, or explicit CI/automation tooling/documentation, and openapi/llms.txt probes 404 indicating limited machine-readable API surface. missing for 10: dedicated CLI or SDK for automation, explicit CI/CD integration guides, documented headless execution mode, independent evidence of automation use.

   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “The client credentials flow provides access to data about your company and does not require explicit permission from a Carta user prior to a…”
   • [claimed-docs] “This guide explains how to access Carta's APIs using Postman.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy~partialprobed5/10

   Ledgy's API supports non-interactive, machine-to-machine authentication via OAuth 2.0 client_credentials with service accounts, which enables scripted/CI-style access without a human login (ledgy-docs-1, ledgy-docs-18, ledgy-docs-19). However, the documented API surface is very limited (only `auth` and `companyCaptable` operations), no CLI, SDK, or CI-specific tooling is evidenced, and llms.txt/openapi probes both 404, suggesting thin machine-readable API documentation. Missing for 10: a broader documented API/CLI for automating core workflows (grants, reports, compliance), explicit CI/automation examples, and discoverable OpenAPI spec.

   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “you can discover it from the authorization server metadata at `https://app.ledgy.com/auth/oidc-idp/.well-known/oauth-authorization-server`”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Carta
   Carta✓fullprobed7/10

   Carta documents an official Claude MCP setup with pre-built plugins for cap table, investors, and fund data, enabling agent connection via natural-language queries (carta-docs-9, carta-docs-10, carta-docs-11, carta-probe-4). Missing for 10: independent/hands-on third-party corroboration of the MCP server working in practice, and details on broader MCP client support beyond Claude.

   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “The Carta Investors plugin gives LLMs access to your fund's data and allows you to generate tear sheets, budgets, and financial statements.”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Access NAV, fund performance, partner data, journal entries, portfolio company financials, build Excel budgets and consolidating P&L / balan…”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy—none0/10

   Ledgy is a cap table/equity management platform; it exposes an OAuth-authenticated API with specific operations (auth, companyCaptable) but no evidence of an official MCP server for agent connectivity. Probes for llms.txt and OpenAPI specs both returned 404, and no MCP-related documentation appears anywhere in the evidence.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Carta—none0/10

   Carta is an equity/cap-table management platform with a documented API, OAuth flows, MCP integrations, and Postman guide, but no evidence anywhere in the pack of an official CLI tool for developers or AI-native workflows. missing for 10: any mention of a CLI, command-line tool, or terminal-based interface.

   ⚑ flag

   Ledgy—none0/10

   Ledgy is a cap table/equity management SaaS with an API and OAuth-based service accounts, but there is no mention of an official CLI tool anywhere in the evidence pack.

   ⚑ flag

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

   weight 3 · round to Carta
   Carta✓fullprobed8/10

   Carta has a documented public REST API platform with OAuth 2.0 authorization, developer portal, playground/sandbox, extensive reference docs covering cap tables, stakeholders, option grants, valuations, and even Postman guides, clearly enabling programmatic/AI-native access. Missing for 10: no discoverable OpenAPI/swagger spec or llms.txt was found (probes returned 404s), which would strengthen machine-readability claims.

   • [claimed-docs] “Learn how to quickly and easily embed Carta data into your app.”
   • [claimed-docs] “Register for our developer portal and create your playground app to start building.”
   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “This guide explains how to access Carta's APIs using Postman.”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “This document explains how to create issuers using Carta’s Draft Issuer API.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.carta.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy~partialprobed5/10

   Ledgy documents a public API with OAuth 2.0 client_credentials auth, service accounts, and specific operations (auth, companyCaptable) that can be driven programmatically, which supports AI-native automation. However, probes show no discoverable OpenAPI spec or llms.txt, and only two operations are evidenced, suggesting limited API surface documentation for broader agentic use. Missing for 10: a full API reference/OpenAPI spec, broader endpoint coverage beyond auth/captable, and independent corroboration of real-world API usage.

   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “you can discover it from the authorization server metadata at `https://app.ledgy.com/auth/oidc-idp/.well-known/oauth-authorization-server`”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Carta~partialclaimed6/10

   Carta's API platform documents OAuth 2.0 with AUTHORIZATION_CODE and CLIENT_CREDENTIALS grant types, adjustable OAuth scopes, and dedicated service accounts for programmatic/investor API access, all of which support issuing scoped, non-interactive credentials suitable for automated/agent use (carta-docs-6, carta-docs-7, carta-docs-8, carta-docs-15). However, this is generic OAuth/service-account tooling not explicitly framed around AI agents, and there's no documentation of agent-specific credential issuance, fine-grained least-privilege enforcement, or credential lifecycle/audit controls. Missing for 10: explicit agent-oriented credential provisioning workflow, granular least-privilege scope examples, and independent verification that scopes are enforced as least-privilege in practice.

   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “The client credentials flow provides access to data about your company and does not require explicit permission from a Carta user prior to a…”
   • [claimed-docs] “Adding new OAuth scopes to your OAuth application allows you to enhance the capabilities of your integration with the Carta API platform.”
   • [claimed-docs] “The application is now added to your Investment Firm and can be used to access its data via the Investor API”

   proof ↗⚑ flag

   Ledgy~partialclaimed6/10

   Ledgy supports OAuth 2.0 service accounts with credentials 'scoped per integration', short-lived tokens, immediate revocation, and a client_credentials grant flow, which are solid least-privilege primitives that could be used to provision an agent's credentials. However, there's no evidence of fine-grained scope/permission configuration (e.g., read-only vs write, specific data-domain scopes) or any agent-specific tooling/framing. Missing for 10: granular permission-scope controls beyond 'per integration', explicit agent-oriented credential issuance workflow, and independent corroboration of least-privilege enforcement.

   • [claimed-docs] “If you still authenticate with an API key, migrate to a service account: the credentials are scoped per integration, the tokens are short-li…”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “Revoke deletes the service account and invalidates its outstanding access tokens right away.”
   • [claimed-docs] “If credentials have been exposed, revoke rather than rotate — rotation leaves already-issued tokens usable for up to 24 hours.”
   • [claimed-docs] “To rotate without downtime, create a second service account, move the integration over to it, and revoke the first one once the switch is co…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Carta
   Carta~partialprobed6/10

   Carta has an extensive REST API with developer portal, OAuth, playground/production environments, and detailed reference docs, satisfying the general SDK-building story; it also documents a Claude MCP setup for AI agent access to cap table/investor data. However, evidence probes show no discoverable OpenAPI spec, llms.txt, or official language-specific SDKs (only raw API + Postman), suggesting 'SDK' support is really API/reference docs rather than packaged SDKs. missing for 10: official language SDKs (Python/JS/etc.), publicly discoverable OpenAPI/machine-readable spec, independent third-party confirmation of SDK usability.

   • [claimed-docs] “Learn how to quickly and easily embed Carta data into your app.”
   • [claimed-docs] “Register for our developer portal and create your playground app to start building.”
   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “This guide explains how to access Carta's APIs using Postman.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.carta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.carta.com/api-platform/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence only shows raw OAuth 2.0 API operations (auth, companyCaptable) with no mention of official SDKs/client libraries in any language, and probes confirm no discoverable OpenAPI spec or llms.txt that would support SDK generation. missing for 10: no official SDK packages, no language-specific client libraries, no SDK documentation or GitHub repos referenced anywhere in the pack.

   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Carta—none0/10

   No evidence in the pack mentions webhooks, event subscriptions, or push notifications anywhere in Carta's API platform docs; the documented capabilities are REST endpoints, OAuth flows, MCP/Claude plugins, and a data warehouse, none of which describe webhook subscription support.

   ⚑ flag

   Ledgy—none0/10

   No evidence of webhook support anywhere in the docs; only OAuth-authenticated REST-style operations (auth, companyCaptable) are described, with no mention of event subscriptions or webhook callbacks.

   ⚑ flag

Agentic features

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

   weight 2 · round to Carta
   Carta~partialprobed6/10

   Carta documents an official Claude/MCP integration that lets users ask natural-language questions over cap table, fund, and portfolio data and generate tear sheets, budgets, and financial statements — a form of AI-generated insight from Carta data. However this is delivered via an external LLM (Claude) through MCP rather than a native in-product AI feature, and there is no independent/hands-on evidence corroborating quality or reliability of the insights. Missing for 10: native in-app AI insight generation (not requiring a separate Claude client), independent user validation of insight accuracy, and broader coverage beyond the MCP-specific plugins.

   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “The Carta Investors plugin gives LLMs access to your fund's data and allows you to generate tear sheets, budgets, and financial statements.”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Access NAV, fund performance, partner data, journal entries, portfolio company financials, build Excel budgets and consolidating P&L / balan…”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of any AI-generated insights, analytics, or suggestions feature within Ledgy; the evidence pack only covers cap table management, compliance, reporting, and API authentication mechanics. Missing for 10: any mention of AI/ML-driven analysis, natural-language insights, or suggestion features derived from user data.

   ⚑ flag

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

   weight 2 · round drawn
   Carta—none0/10

   Carta's docs describe API/OAuth access and an MCP integration for querying cap table and fund data via natural language (carta-docs-9, carta-docs-30, carta-docs-31), but there is no evidence of scheduling, triggers, webhooks, or any mechanism for autonomous background-running automations built on the platform. This axis is fair for an API/data platform, but the evidence pack shows only synchronous query/integration capabilities, not autonomous background automation.

   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Access NAV, fund performance, partner data, journal entries, portfolio company financials, build Excel budgets and consolidating P&L / balan…”
   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence shows Ledgy offers workflow automation for cap table/equity management (bulk granting, HRIS integrations) and an API with OAuth service accounts, but nothing describes autonomous background automations that a user or AI agent can set up and let run independently (e.g., scheduled jobs, triggers, webhooks). No mention of automation-builder, scheduling, or agentic execution.

   • [claimed-docs] “Leverage the power of 70+ HRIS integrations to keep large volumes of data accurate.”
   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Automated error flags and crystal-clear visuals let you easily identify and resolve compliance risks.”

   proof ↗⚑ flag

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

   weight 2 · round to Carta
   Carta~partialprobed6/10

   Carta documents an official Claude MCP integration allowing natural-language queries over cap tables, fund performance, and financial data (e.g., 'all with natural language questions'), which directly supports AI-native NL interaction. However, this is scoped to specific plugins (cap table, investors) via Claude/MCP rather than a native NL command interface across the whole product, and there's no independent/hands-on corroboration of quality or reliability. Missing for 10: broader natural-language coverage beyond Claude MCP plugins, independent hands-on verification, and evidence of NL support outside the MCP integration.

   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “The Carta Investors plugin gives LLMs access to your fund's data and allows you to generate tear sheets, budgets, and financial statements.”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Access NAV, fund performance, partner data, journal entries, portfolio company financials, build Excel budgets and consolidating P&L / balan…”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of any natural-language command interface, chatbot, or AI assistant in Ledgy; the product is described entirely as a cap-table/equity-management platform with REST-style API operations (auth, companyCaptable) and UI-based workflows. Probes for llms.txt and OpenAPI specs both failed, and no documentation mentions natural-language interaction.

   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Carta
   Carta~partialprobed4/10

   Carta has extensive API reference docs and a sandbox/playground environment with static valid responses for testing, which supports exploration without real credentials, but there's no evidence of an interactive 'try it now' console with runnable examples embedded in the docs, and OpenAPI/llms.txt probes all returned 404s. missing for 10: interactive in-browser API console with live runnable requests, OpenAPI spec availability, llms.txt for AI consumption.

   • [claimed-docs] “It doesn't require genuine credentials and always returns static but valid responses to your requests.”
   • [claimed-docs] “Our playground environment provides a similar experience to our production environment.”
   • [claimed-docs] “This guide explains how to access Carta's APIs using Postman.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.carta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.carta.com/api-platform/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence shows only text descriptions of two API operations (auth, companyCaptable) with no interactive reference, no runnable examples/sandbox, and explicit probes show no OpenAPI spec or llms.txt available.

   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Carta—none0/10

   Carta has an extensive API reference but there is no evidence of a downloadable OpenAPI/Swagger spec; probes for llms.txt, docs markdown, and common OpenAPI paths all returned 404, indicating no machine-readable spec is exposed.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.carta.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docs.carta.com/api-platform/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy—none0/10

   Probes for llms.txt and common OpenAPI/Swagger spec paths all returned 404, and no docs evidence links to a downloadable machine-readable API spec despite documenting individual operations like auth and companyCaptable.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”

   proof ↗⚑ flag

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

   weight 1 · round to Carta
   Carta✓fullclaimed8/10

   Carta provides an explicit playground/sandbox environment with static but valid mock responses that mimics production, plus a documented path to promote apps from playground to production, directly matching the story. Missing for 10: independent/hands-on developer confirmation that the sandbox fully isolates from production data in practice.

   • [claimed-docs] “It doesn't require genuine credentials and always returns static but valid responses to your requests.”
   • [claimed-docs] “Register for our developer portal and create your playground app to start building.”
   • [claimed-docs] “Our playground environment provides a similar experience to our production environment.”
   • [claimed-docs] “Promote your playground app to production in the Developer Portal.”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of a sandbox, staging, or test environment offered by Ledgy's API or platform; documentation covers only production OAuth authentication and API operations. Missing for 10: any mention of sandbox/test environment, test credentials, or non-production data mode.

   ⚑ flag

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

   weight 2 · round drawn
   Carta—none0/10

   The evidence pack shows API guides, OAuth authorization, and versioned endpoint paths (e.g. 'v-1-alpha-1') but no documented deprecation policy, versioning strategy, or changelog is mentioned anywhere; probes also failed to find an OpenAPI spec that would clarify versioning. Missing for 10: explicit API versioning scheme documentation, deprecation policy/timeline, changelog or migration guides for breaking changes.

   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; docs cover auth, rotation, and specific operations but nothing about version numbers, changelogs, or deprecation timelines. OpenAPI/spec probes also failed (404s), reinforcing absence of formal versioned API documentation.

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

   proof ↗⚑ flag

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

   weight 2 · round to Ledgy
   Carta~partialclaimed4/10

   Carta's API exposes list/read endpoints (stakeholders, option grants, convertible notes, fair market values) and a data warehouse enabling multi-faceted SQL queries across large datasets, which supports bulk retrieval/analysis. However, there is no evidence of bulk write/update/create operations (only single draft option grant / draft issuer creation endpoints), nor any explicit batch-processing or multi-item mutation API for AI-native workflows. Missing for 10: documented bulk create/update/delete endpoints, batch processing limits or examples, and independent/hands-on confirmation of large-scale bulk automation via the API or MCP integration.

   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “It unifies your firm's most critical data—from fund performance and portfolio financials to partner capital accounts—into a single, queryabl…”
   • [claimed-docs] “Analysts are free to perform sophisticated, multi-faceted SQL queries and analyses without the friction of integrating disparate data source…”

   proof ↗⚑ flag

   Ledgy~partialprobed5/10

   Ledgy documents bulk operations for humans in-app (bulk granting, document/signature workflows, HRIS-driven bulk data accuracy), but there's no evidence of an API/automation surface allowing an AI-native user to programmatically perform bulk operations across many items — the API docs only show narrow operations like 'auth' and 'companyCaptable', and no bulk/batch endpoints or OpenAPI spec are found. missing for 10: API-level bulk/batch endpoints, evidence of programmatic multi-item operations, OpenAPI/spec confirmation of bulk actions.

   • [claimed-docs] “Leverage the power of 70+ HRIS integrations to keep large volumes of data accurate.”
   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Carta—none0/10

   Carta's evidence covers API access, OAuth, data retrieval endpoints, and an MCP/Claude integration for querying data via natural language, but there is no mention of user-defined rules, triggers, webhooks, or event-based automation that fires actions automatically. Missing for 10: rule/trigger definition mechanism, event subscription or webhook system, evidence of automated actions firing on events.

   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of any rule engine, event triggers, or automated actions based on conditions/events; the 'automation' mentioned relates to bulk workflows (granting, reporting) not event-driven rule triggers.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Carta—none0/10

   Carta's evidence pack covers API access, OAuth, MCP plugin setup, and cap table data endpoints, but nothing describes scheduling, recurring jobs, cron-like automation, or workflow triggers. Missing for 10: any scheduler/cron feature, recurring job configuration, or workflow automation trigger mechanism.

   ⚑ flag

   Ledgy—none0/10

   No evidence of scheduling, cron-like recurring jobs, or workflow automation triggers in Ledgy's API or product docs; the pack only covers auth, cap table, and reporting features. missing for 10: any scheduling/recurring job mechanism, workflow trigger API, or automation orchestration capability.

   ⚑ flag

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

   weight 1 · round drawn
   Carta—none0/10

   Carta is a cap-table/equity management platform with an API and MCP plugin for querying data; no evidence describes any versioning, review, or rollback system for automations or integrations built on Carta. Nothing in the docs addresses automation history tracking or reverting changes.

   ⚑ flag

   Ledgy—none0/10

   No evidence of any versioning, review, or rollback capability for automations/workflows in Ledgy's product; docs focus on cap table, compliance, auth, and API credentials, not automation change management.

   ⚑ flag

Certificates

1. founderIssue electronic share certificates that are legally signed in-platform and permanently linked to the cap table entry they represent

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack is entirely about Carta's API platform (developer portal, OAuth, MCP integrations, data endpoints for cap tables, stakeholders, options, etc.) and community complaints about sales/cancellation practices; nothing describes electronic share certificate issuance, in-platform legal e-signature workflows, or certificate-to-cap-table linkage. Missing for 10: any documentation of certificate generation/e-signing feature, evidence of legal validity/compliance, and confirmation of permanent linkage to cap table records.

   ⚑ flag

   Ledgy~partialclaimed5/10

   Ledgy's docs mention granting share awards and 'creating, signing and sharing contracts in just a few clicks' (ledgy-docs-12) and automating 'document and signature workflows' (ledgy-docs-10), indicating in-platform signing tied to grants/cap table entries. However, there is no explicit mention of legally binding e-signature certification or the certificates being permanently and immutably linked to the cap table record. missing for 10: explicit legal e-signature compliance details, proof of permanent/immutable linkage between certificate and cap table entry, independent verification of signature legality.

   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”
   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”

   proof ↗⚑ flag

Migration

1. ops userMigrate an existing cap table — from a spreadsheet or another platform — with guided import, validation, and reconciliation against source documents

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack contains no documentation of a guided cap-table import, data validation, or reconciliation workflow for migrating from spreadsheets or other platforms into Carta; all docs relate to the developer API platform (retrieving data, OAuth, MCP plugins) rather than onboarding. The only related community evidence describes onboarding as an 'involved process' with many help articles and fees, and other threads describe difficulty migrating data OUT of Carta — neither confirms an actual guided import/reconciliation feature.

   • [community] “A founder asked whether switching from a free cap table tool to Carta would be painful, noting Carta onboarding 'has an involved process and…”
   • [community] “I'm the founder of Eqvista, a Carta competitor; we've seen significant migrations from Carta due to cost, lengthy 409A valuation timelines, …”

   proof ↗⚑ flag

   Ledgy~partialclaimed3/10

   Ledgy mentions bringing in historical transaction data with attached documents, implying some import capability, but there is no evidence of a guided import wizard, data validation, or reconciliation process against source documents. Missing for 10: guided import/migration workflow, validation checks, reconciliation reporting, and evidence of spreadsheet/platform migration support.

   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”

   proof ↗⚑ flag

Source of truth

1. founderMaintain my full cap table — share classes, certificates, SAFEs, and option grants — as a live single source of truth that investors and auditors rely on

   weight 3 · round to Ledgy
   Carta✓fullclaimed7/10

   Carta's own API docs confirm the core cap-table entities (issuers, share classes, stakeholders, option grants, convertible notes, SAFEs, 409A/FMV data) are all live, queryable objects in a single system, and describe partners, law firms, and auditors accessing this data programmatically — matching the 'single source of truth' story. Community evidence (billing/support complaints, PG's spam remark) is about sales practices and cancellation friction, not about the accuracy or reliability of the cap table data itself, so it doesn't contradict this axis. Missing for 10: independent/hands-on confirmation that investors and auditors actually rely on Carta as source of truth (only vendor docs), and no product UI evidence beyond API references.

   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “Allows law firms and technology partners to fetch cap table information on behalf of the company”
   • [claimed-docs] “This document explains how to create issuers using Carta’s Draft Issuer API.”

   proof ↗⚑ flag

   Ledgy✓fullclaimed8/10

   Ledgy's docs describe core cap-table functionality: bringing in historical transactions with attached documents, share classes/grants, reporting, and API access to cap table data (companyCaptable operation), positioning it as a live system of record used by companies and relied on for compliance/audit reporting. missing for 10: independent/third-party corroboration (e.g., investor or auditor testimonials) that Ledgy is trusted as the authoritative source of truth, and explicit documentation of SAFE instrument support.

   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”
   • [claimed-docs] “Build reports based on your needs: play with columns and views and aggregate grouping to see your data, your way.”
   • [claimed-docs] “Generate a broad suite of financial reports instantly to account for equity under IFRS 2, UK GAAP or US GAAP, with tranche-level details in …”
   • [claimed-docs] “Automated error flags and crystal-clear visuals let you easily identify and resolve compliance risks.”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”

   proof ↗⚑ flag

Stock comp

1. ops userProduce ASC 718 stock-based compensation expense reports my accountants can hand to auditors

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack covers Carta's API platform, cap tables, 409A valuations, option grants, and MCP data access, but contains no mention of ASC 718 stock-based compensation expense reports or auditor-ready compliance reporting output. Missing for 10: any documentation of an ASC 718 report, audit trail, or accountant-facing expense reporting feature.

   • [claimed-docs] “This API can be used to calculate the tax implications of a user exercising their equity.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “Retrieve option grants.”

   proof ↗⚑ flag

   Ledgy~partialclaimed6/10

   Ledgy explicitly advertises financial reports for equity compensation under US GAAP (which ASC 718 is part of) with tranche-level detail generated in one click, directly relevant to SBC expense reporting for auditors. However, the evidence never names ASC 718 specifically or describes audit-ready formatting/export conventions accountants expect. Missing for 10: explicit ASC 718 terminology, sample report/audit trail evidence, and confirmation of accountant-facing export formats.

   • [claimed-docs] “Generate a broad suite of financial reports instantly to account for equity under IFRS 2, UK GAAP or US GAAP, with tranche-level details in …”
   • [claimed-docs] “One-click equity compliance reports, custom views and exports, make meeting compliance deadlines a breeze.”

   proof ↗⚑ flag

Us filings

1. ops userUS equity compliance — Rule 701 disclosure thresholds, Form 3921 filings, 83(b) elections — is tracked and generated from the cap table automatically

   weight 2 · round drawn
   Carta—none0/10

   The evidence pack covers Carta's API platform, OAuth, MCP integrations, and cap table data endpoints, but contains no mention of Rule 701 disclosure threshold tracking, Form 3921 filing generation, or 83(b) election tracking/automation. The closest item (carta-docs-13, FMV/tax implications API) is generic tax calculation, not these specific compliance filings.

   ⚑ flag

   Ledgy—none0/10

   Evidence shows generic equity-compliance features (error flags, global mobility reporting, one-click compliance reports) but no mention of Rule 701 disclosure thresholds, Form 3921 filings, or 83(b) election tracking/generation — the specific US regulatory triggers named in the story are absent from the evidence pack.

   • [claimed-docs] “Automated error flags and crystal-clear visuals let you easily identify and resolve compliance risks.”
   • [claimed-docs] “Global mobility reporting helps you stay on top of equity and tax as your workforce moves across borders.”
   • [claimed-docs] “One-click equity compliance reports, custom views and exports, make meeting compliance deadlines a breeze.”

   proof ↗⚑ flag

Agent access

1. ai-native userAn agent can draft securities (e.g. option grants) via the platform's programmatic surface and leave them queued for human board approval

   weight 2 · round to Carta
   Carta~partialclaimed6/10

   Carta's API explicitly supports creating draft option grants that remain unapproved until board consent (carta-docs-22), and the programmatic surface (REST API plus OAuth) allows an agent to call this endpoint directly; the MCP/Claude integration also exposes option grant data for natural-language agent use (carta-docs-9, carta-docs-10, carta-docs-30). However, evidence doesn't show an end-to-end documented workflow specifically for an agent drafting a grant via MCP/Claude and it landing in a board approval queue, nor confirmation that the MCP plugin exposes write/draft-creation actions (it seems read/query-oriented). missing for 10: explicit documentation that the MCP-agent surface (not just direct REST API) can create draft securities, and confirmation of the human board-approval queue/workflow tied to that draft creation.

   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”

   proof ↗⚑ flag

   Ledgy—none0/10

   The API surface documented is read-only (auth, companyCaptable) with no evidence of any write/create operations for securities like option grants, let alone a queued-for-approval workflow; granting is only described as a manual UI feature (bulk grant/sign in the app), not a programmatic agent-drafting capability. missing for 10: any documented API endpoint to create/draft a grant, any concept of an approval queue or draft state reachable via API, and evidence of an agent-facing programmatic interface for equity issuance.

   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”
   • [claimed-docs] “The `auth` operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and ob…”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

2. ai-native userHave an agent pull my current cap table programmatically and reconcile it against my data room before a financing

   weight 3 · round to Carta
   Carta~partialprobed6/10

   Carta ships a documented REST API (capitalization table, stakeholders, option grants, convertible notes, FMV endpoints) plus an official Claude MCP server that lets an agent query cap table data via natural language, directly enabling programmatic cap-table pulls. However, there is no evidence of any data-room integration or reconciliation feature/endpoint tying cap table data to data-room documents for financing diligence. Missing for 10: data-room reconciliation capability, evidence of cross-referencing cap table vs data room documents, independent/hands-on validation of the MCP or API for this workflow.

   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy~partialprobed5/10

   Ledgy exposes an OAuth2-authenticated API with a companyCaptable operation that lets an agent programmatically pull cap table data, which is the core enabler for this story. However, there is no evidence of a documented reconciliation/data-room comparison capability, no data-room API, no openapi/llms.txt discoverability (both probes 404), and no example of an agent workflow tying cap table pulls to data-room reconciliation. Missing for 10: data-room integration/API, reconciliation logic or workflow support, machine-readable API spec (openapi.json/llms.txt) for agent discovery, independent/hands-on evidence of this workflow.

   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

Api access

1. developerPull the full capitalization table — stakeholders, share classes, securities, and vesting states — through a documented programmatic API

   weight 3 · round to Carta
   Carta✓fullclaimed9/10

   Carta's docs show a documented REST API with specific endpoints to retrieve capitalization tables by share class, stakeholders, option grants, convertible notes, draft securities, and fair market values, plus OAuth2-based authentication and a sandbox/playground for testing before production. Community evidence does not contradict the API's data-access functionality. Missing for 10: no independent third-party developer testimonial confirming real-world completeness/accuracy of the API responses, and no public OpenAPI spec discoverable (probe shows 404s).

   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “The formulas below show how to calculate the following outstanding and fully diluted percentages using our Capitalization Table endpoint”

   proof ↗⚑ flag

   Ledgy~partialprobed6/10

   Ledgy docs describe a documented, OAuth2-authenticated API with a `companyCaptable` operation that retrieves 'cap table data' for a company, which is the correct programmatic-access mechanism a developer would need. However, the evidence never enumerates the specific fields (stakeholders, share classes, securities, vesting states) returned by that operation, and probes for a public OpenAPI/swagger spec all 404, so the schema depth and completeness cannot be confirmed. Missing for 10: field-level schema documentation confirming stakeholders/share classes/securities/vesting data, and an accessible OpenAPI/reference spec.

   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

Partner access

1. developerThird parties my company authorizes — law firms, HRIS vendors, wealth managers — can access scoped slices of equity data on our behalf without full admin credentials

   weight 2 · round to Carta
   Carta✓fullclaimed8/10

   Carta's docs explicitly describe OAuth 2.0 authorization with scoped access (AUTHORIZATION_CODE/CLIENT_CREDENTIALS grants, custom OAuth scopes) and name exactly the third-party use cases in the story — law firms fetching cap table data on behalf of companies, personal finance/wealth partners aggregating equity holdings, and incorporation partners programmatically onboarding customers — all without requiring full admin credentials. Missing for 10: independent/hands-on corroboration that scope restrictions work as intended in production, and explicit documentation of an HRIS-specific integration scope (only 'personal finance' and 'law firm' partner types are named directly).

   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “Adding new OAuth scopes to your OAuth application allows you to enhance the capabilities of your integration with the Carta API platform.”
   • [claimed-docs] “Allows incorporation partners and law firms to programmatically send new customers to Carta”
   • [claimed-docs] “Allows fund operators to retrieve summary cap table insights for their portfolio holdings”
   • [claimed-docs] “Allows law firms and technology partners to fetch cap table information on behalf of the company”
   • [claimed-docs] “Allows personal finance management partners to aggregate holdings inclusive of equity data”
   • [claimed-docs] “Allows funds to manage their deal and fundraising relationships across the investment process”

   proof ↗⚑ flag

   Ledgy~partialclaimed6/10

   Ledgy's docs show OAuth 2.0 service accounts that are credential-scoped per integration, short-lived, and revocable, which supports the general concept of granting a third-party integration access without sharing admin credentials, and the 70+ HRIS integrations point to real external vendor connectivity. However, there's no explicit documentation of granular data-slice scoping (e.g., read-only cap-table subsets) or of onboarding named third-party personas like law firms or wealth managers specifically, only generic 'auth' and 'companyCaptable' API operations. Missing for 10: explicit fine-grained permission/data-scope controls per third party, documented support for law-firm/wealth-manager use cases, and any admin UI showing how a developer restricts a partner's access scope.

   • [claimed-docs] “Requests are authenticated with an OAuth 2.0 access token belonging to a service account.”
   • [claimed-docs] “If you still authenticate with an API key, migrate to a service account: the credentials are scoped per integration, the tokens are short-li…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “Leverage the power of 70+ HRIS integrations to keep large volumes of data accurate.”
   • [claimed-docs] “Exchange the credentials for an access token using the OAuth 2.0 `client_credentials` grant”
   • [claimed-docs] “The `auth` operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and ob…”

   proof ↗⚑ flag

Bulk issuance

1. ops userUpload or issue securities in bulk — a batch of grants or historical transactions — instead of entering them one at a time

   weight 2 · round to Ledgy
   Carta~partialclaimed3/10

   Carta's API exposes endpoints to create individual draft option grants and draft issuers programmatically (carta-docs-22, carta-docs-33), which could be scripted to issue many grants, but there is no documented bulk/batch upload endpoint, CSV import tool, or explicit 'bulk issuance' feature for historical transactions. Missing for 10: a dedicated batch/bulk-create endpoint or CSV import UI, documentation describing bulk historical transaction import, and any independent confirmation that ops teams actually use this for bulk issuance.

   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “This document explains how to create issuers using Carta’s Draft Issuer API.”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”

   proof ↗⚑ flag

   Ledgy✓fullclaimed7/10

   Docs explicitly support bulk historical transaction import ('Bring historical transaction data into your cap table') and bulk grant issuance ('Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks'), plus bulk automation of granting/document/signature workflows. missing for 10: no independent/hands-on corroboration of bulk upload UX, no detail on file format (CSV/template) or size limits, no evidence of error handling during bulk upload.

   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”
   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”

   proof ↗⚑ flag

Option grants

1. founderIssue options to a new hire with a board approval flow and a 409A-compliant strike price in one end-to-end workflow

   weight 3 · round to Carta
   Carta~partialclaimed6/10

   Carta's API docs confirm the underlying data model for this workflow: draft option grants require 'board consent and approval' before finalization (carta-docs-22), and FMV/409A valuation data is available to price grants compliantly (carta-docs-23, carta-docs-13, carta-docs-20). This implies the platform supports issuing 409A-priced options with board approval, but the evidence is API-reference level rather than a documented end-to-end founder-facing workflow, and there is no independent/hands-on confirmation that a founder can complete this in one seamless flow. missing for 10: first-party product walkthrough of the founder-facing grant-issuance UI (not just API), independent user confirmation the board-approval-to-409A-strike flow works smoothly end-to-end.

   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “This API can be used to calculate the tax implications of a user exercising their equity.”
   • [claimed-docs] “Retrieve option grants.”

   proof ↗⚑ flag

   Ledgy~partialclaimed3/10

   Ledgy's docs show granting workflows (bulk grants, contract signing, custom vesting) but there is no evidence of a board approval step or 409A-compliant strike price calculation anywhere in the pack. missing for 10: board approval workflow, 409A strike price compliance, end-to-end integration of these into a single grant flow.

   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Switch up vesting schedules for different groups, or create custom vesting to reflect your needs.”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”

   proof ↗⚑ flag

Vesting

1. ops userDefine custom vesting schedules — cliffs, milestones, acceleration on exit — and the platform tracks vested vs unvested automatically

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack covers Carta's API platform, OAuth, MCP integrations, and cap table/option-grant retrieval endpoints, but contains no mention of defining custom vesting schedules, cliffs, milestone-based vesting, or acceleration-on-exit logic, nor of automatic vested/unvested tracking. Since Carta is an equity management platform, this is a core applicable axis, but no supporting evidence exists in the pack.

   ⚑ flag

   Ledgy~partialclaimed5/10

   Ledgy's own equity-plan-automation page confirms custom vesting schedules ('Switch up vesting schedules for different groups, or create custom vesting') and bulk granting workflows, which supports the core ask, but there is no explicit evidence of cliff/milestone/acceleration-on-exit configuration or of automatic vested-vs-unvested tracking mechanics. Missing for 10: explicit cliff/milestone/acceleration-on-exit setup details, documentation of automatic vested/unvested calculation logic, and independent corroboration beyond marketing copy.

   • [claimed-docs] “Switch up vesting schedules for different groups, or create custom vesting to reflect your needs.”
   • [claimed-docs] “Automate your granting, document and signature workflows in bulk to make expansion easy.”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”

   proof ↗⚑ flag

Investor relations

1. founderMy investors get their own portal view of their holdings and can receive structured updates without emailing me for the cap table

   weight 1 · round drawn
   Carta—none0/10

   The evidence pack only covers Carta's developer API/MCP platform and negative community reports about cancellation and cold-calling practices; none of it documents a dedicated investor portal or structured update/reporting feature that would let investors self-serve cap table data without contacting the founder. The one tangential remark (Paul Graham noting Carta 'will spam all your investors') describes unsolicited outreach, not a structured self-serve portal, so it does not establish this capability.

   • [community] “Paul Graham (2021): 'If you use Carta to manage your cap table, they will spam all your investors.'”

   proof ↗⚑ flag

   Ledgy—none0/10

   The evidence pack covers API authentication, cap table data, equity plan automation, compliance, and trading/settlement features, but contains no mention of an investor portal, investor login access, or structured update/reporting features aimed at external investors. missing for 10: investor portal login, investor-facing update/reporting workflow, evidence of reducing founder-investor email traffic.

   ⚑ flag

Safes

1. founderCreate, send, and e-sign SAFEs or convertible notes in-platform, and they land on the cap table with their conversion terms modeled

   weight 3 · round to Carta
   Carta~partialclaimed4/10

   Evidence confirms convertible notes/SAFEs exist as objects on Carta's cap table and can be queried via API (carta-docs-21, carta-docs-30, carta-docs-10), implying they are modeled once created, but there is no documentation in this pack of an in-platform workflow to draft, send, or e-sign a SAFE/convertible note (only a 'Draft Issuer API' and 'draft option grant' creation flow are mentioned, not draft convertible notes or e-signature). Missing for 10: evidence of SAFE/convertible note creation and e-signature workflow, evidence that terms auto-model conversion scenarios upon signing.

   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “Query ownership, SAFEs, convertibles, grants, valuations, financing history, and compensation benchmarks.”
   • [claimed-docs] “Access ownership, stakeholder lists, SAFEs, convertible notes, option grants, 409A valuations, financing history, compensation benchmarks, a…”
   • [claimed-docs] “This document explains how to create issuers using Carta’s Draft Issuer API.”
   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence covers cap table reporting, equity plan automation, share grants, compliance, and API auth, but there is no mention of creating/sending/e-signing SAFEs or convertible notes, nor of automatic conversion-term modeling on the cap table. missing for 10: SAFE/convertible note creation workflow, e-signature for investment instruments, conversion term modeling on cap table.

   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”
   • [claimed-docs] “Grant share awards one by one, or in bulk, creating, signing and sharing contracts in just a few clicks.”
   • [claimed-docs] “Build reports based on your needs: play with columns and views and aggregate grouping to see your data, your way.”

   proof ↗⚑ flag

Scenario modeling

1. ops userRun exit waterfall analyses showing proceeds per share class and stakeholder under different exit values, honoring preferences and participation

   weight 2 · round drawn
   Carta—none0/10

   Evidence covers cap table data retrieval (share classes, stakeholders, option grants, FMV, convertibles) via API, but nothing documents exit waterfall modeling, proceeds-per-share-class calculations under different exit values, or handling of liquidation preferences/participation rights.

   ⚑ flag

   Ledgy—none0/10

   The evidence pack covers API authentication, cap table reporting, equity plan automation, compliance, and trading/settlement, but contains no mention of exit waterfall analysis, liquidation preferences, participation rights, or proceeds-per-share modeling under different exit scenarios. Missing for 10: any documentation of exit waterfall/scenario modeling, preference stack handling, participation calculations, or proceeds distribution by exit value.

   ⚑ flag

2. founderModel a priced round — dilution, option pool top-up, SAFE conversion, pro-forma ownership — and share the scenario with counsel and investors

   weight 3 · round drawn
   Carta—none0/10

   The evidence pack covers Carta's developer/API platform (cap table data retrieval, OAuth, MCP plugins, data warehouse) but contains no documentation of a scenario-modeling tool for priced rounds, dilution, option pool top-ups, SAFE conversion modeling, or pro-forma ownership sharing with counsel/investors. Only tangential API endpoints exist (cap table percentage calculation, convertible note listing, draft option grants) but none describe an interactive round-modeling workflow.

   • [claimed-docs] “The formulas below show how to calculate the following outstanding and fully diluted percentages using our Capitalization Table endpoint”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”

   proof ↗⚑ flag

   Ledgy—none0/10

   The evidence pack covers API authentication, cap table management, equity plan automation, compliance, and trading/settlement, but contains no mention of fundraising round modeling, dilution scenarios, option pool top-ups, SAFE conversion modeling, pro-forma ownership tables, or sharing scenarios with counsel/investors. Nothing in the pack addresses this specific fundraising-modeling capability.

   ⚑ flag

Board approvals

1. founderBoard consents and stockholder approvals are drafted, routed for e-signature, and archived against the transactions they authorize

   weight 2 · round drawn
   Carta—none0/10

   The evidence only shows API references to option grants requiring 'board consent and approval' as a status flag (carta-docs-22), but there is no documentation of a workflow for drafting board consents/stockholder approvals, routing them for e-signature, or archiving them against the transactions they authorize. Governance workflows are a plausible axis for a cap table platform, but no evidence substantiates this specific capability.

   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence covers cap table management, equity compliance reporting, HRIS integrations, and API authentication, plus e-signature use for grant contracts, but there is no mention of board consents or stockholder approval workflows being drafted, routed for signature, and archived against specific authorizing transactions.

   ⚑ flag

Counsel access

1. ops userMy outside counsel can work directly in the platform with law-firm roles — preparing documents and updating records without emailing spreadsheets

   weight 2 · round to Carta
   Carta~partialclaimed3/10

   Docs mention law firms and technology partners can be granted API access to 'fetch cap table information on behalf of the company' and 'programmatically send new customers to Carta,' implying some counsel-facing integration exists, but there is no evidence of an actual in-platform law-firm role for preparing documents or updating cap-table records directly in the UI. missing for 10: documentation of a dedicated law-firm/outside-counsel platform role, UI workflows for document preparation, and evidence of record-updating permissions rather than just read-only API access.

   • [claimed-docs] “Allows incorporation partners and law firms to programmatically send new customers to Carta”
   • [claimed-docs] “Allows law firms and technology partners to fetch cap table information on behalf of the company”

   proof ↗⚑ flag

   Ledgy—none0/10

   No evidence of a law-firm/counsel-specific role or external-counsel collaboration workflow; docs mention only generic 'segment permissions for team members' and API/service-account access, nothing about outside counsel drafting documents or updating records in-platform.

   • [claimed-docs] “Segment permissions for team members, ad”

   proof ↗⚑ flag

Data room

1. ops userShare a permissioned, diligence-ready data room — cap table views plus underlying documents — with counsel and investors

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack covers Carta's developer API platform, OAuth scopes, and an MCP/Claude plugin for querying cap table data — none of it describes a permissioned data-room product for sharing cap table views plus underlying documents with counsel/investors for diligence purposes. Community evidence only discusses pricing, cancellation friction, and sales-practice complaints, which are off-topic for this story.

   ⚑ flag

   Ledgy~partialclaimed3/10

   Evidence shows Ledgy attaches documents to cap table records (ledgy-docs-7) and offers permission segmentation for team members (ledgy-docs-23), which are building blocks for a shared, permissioned repository, but there is no explicit mention of a dedicated 'data room' feature, external counsel/investor access controls, or diligence-specific sharing workflow. Missing for 10: explicit data-room/document-sharing feature description, external party (counsel/investor) access permissioning, and any hands-on or documented workflow for diligence sharing.

   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”
   • [claimed-docs] “Segment permissions for team members, ad”
   • [claimed-docs] “Build reports based on your needs: play with columns and views and aggregate grouping to see your data, your way.”

   proof ↗⚑ flag

Hris sync

1. ops userStakeholders sync from my HRIS/payroll system (e.g. Gusto, Rippling) so new hires and terminations flow into equity records automatically

   weight 2 · round to Ledgy
   Carta—none0/10

   The evidence pack shows Carta's API/MCP platform covers cap tables, stakeholders, option grants, valuations, and OAuth access, but there is no mention of any HRIS/payroll integration (Gusto, Rippling, etc.) or automated sync of new hires/terminations into equity records. Absence of evidence for this specific applicable integration means it does not deliver the story.

   • [claimed-docs] “Learn how to quickly and easily embed Carta data into your app.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”

   proof ↗⚑ flag

   Ledgy~partialclaimed5/10

   Ledgy claims '70+ HRIS integrations to keep large volumes of data accurate' for equity plan automation, implying HRIS/payroll sync is supported, but there is no detail on which systems (e.g., Gusto, Rippling), how new hire/termination events flow into equity records, or sync mechanics/frequency. Missing for 10: named HRIS/payroll connectors, description of automated new-hire/termination event handling, setup/configuration docs, and independent or hands-on confirmation of the sync working.

   • [claimed-docs] “Leverage the power of 70+ HRIS integrations to keep large volumes of data accurate.”

   proof ↗⚑ flag

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

   weight 2 · round to Carta
   Carta~partialprobed5/10

   Carta exposes a broad read/write REST API (cap tables, stakeholders, option grants, convertible notes, 409A/FMV, draft issuer/option-grant creation) plus an MCP integration for natural-language querying, showing meaningful API-UI overlap for core equity data. However, there's no evidence of a machine-readable OpenAPI spec (all probes 404) or of API parity for many UI workflows (e.g., exercising options, secondary transactions, cancellations, full administrative actions), so full UI-API parity is unproven. Missing for 10: comprehensive OpenAPI/spec coverage, evidence of write-parity for transactional workflows (exercises, financings, secondary sales), and independent confirmation that all UI actions are API-accessible.

   • [claimed-docs] “Carta's API uses the OAuth 2.0 open specification to authorize your access to our data, and supports AUTHORIZATION_CODE and CLIENT_CREDENTIA…”
   • [claimed-docs] “Connect to your Carta account using pre-built plugins and access fund performance, cap tables, portfolio financials, partner data, and more.”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “A draft option grant is an option grant that is either still being finalized or that has not yet received board consent and approval.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “This document explains how to create issuers using Carta’s Draft Issuer API.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.carta.com/openapi.json, https://docs.carta.com/swagger.json, https://docs.carta.com/api…”
   • [probe] “official MCP server documented at https://docs.carta.com/api-platform/guides/guides/claude-mcp-setup/”

   proof ↗⚑ flag

   Ledgy—none0/10

   The API surface documented is limited to authentication and a single read-only companyCaptable query — nothing evidencing parity with the extensive UI functionality (bulk grants, vesting schedules, compliance reports, trading/settlement, HRIS integrations, financial reporting). No OpenAPI spec or broader endpoint catalog was found (probes 404), so there's no evidence the API covers most UI capabilities let alone all of them.

   • [claimed-docs] “The auth operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and obta…”
   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “The `companyCaptable` operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the quer…”
   • [claimed-docs] “The `auth` operation is a basic interface designed for authentication purposes. The operation user can authenticate their credentials and ob…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”

   proof ↗⚑ flag

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

   weight 3 · round to Carta
   Carta!disputedcontradicted3/10

   Carta's API platform does expose structured data (cap tables, stakeholders, grants, valuations) via REST endpoints, which offers some data access/portability, but there is no documented bulk 'export all data' feature in open formats, and independent reports directly contradict the 'leave' part of the story — founders describe deliberately obstructed cancellation, migration difficulty, and being 'trapped' when trying to move to a competitor. Missing for 10: evidence of a full open-format data export/download feature, and any confirmation that customers can smoothly migrate their full cap table data elsewhere.

   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [community] “Carta's cancellation process requires a meeting with a customer success rep before you can cancel, and founders report being unable to sched…”
   • [community] “I'm the founder of Eqvista, a Carta competitor; we've seen significant migrations from Carta due to cost, lengthy 409A valuation timelines, …”
   • [community] “Carta was charging me $8,000 per year. I found an alternative (Cake Equity) with all the features for 10% of the price. It took multiple cal…”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence shows API access via cap table/company queries and report exports (custom views/exports), but there is no mention of a full open-format data export/portability feature enabling a user to take all their data and leave the platform; no llms.txt or OpenAPI spec found either.

   • [claimed-docs] “One-click equity compliance reports, custom views and exports, make meeting compliance deadlines a breeze.”
   • [claimed-docs] “Build reports based on your needs: play with columns and views and aggregate grouping to see your data, your way.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docs.ledgy.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.ledgy.com/openapi.json, https://docs.ledgy.com/swagger.json, https://docs.ledgy.com/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Carta—none0/10

   No evidence in the pack mentions data residency, regional storage options, or data location controls for Carta's platform or API. missing for 10: any mention of region selection, data residency policy, or storage location controls.

   ⚑ flag

   Ledgy—none0/10

   No evidence in the pack addresses data residency, regional storage options, or where customer data is hosted; the docs cover only authentication, cap table, equity, and reporting features.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Carta—none0/10

   No evidence in the pack addresses AI training data opt-out or privacy controls related to AI model training; the docs focus on API/MCP integration and community items concern unrelated sales/support complaints. Missing for 10: any AI-training data usage policy, opt-out settings, or privacy documentation addressing this concern.

   ⚑ flag

   Ledgy—none0/10

   Ledgy's evidence pack covers API authentication, cap table, equity plan, compliance, and trading features, but contains no mention of AI training data usage, opt-out controls, or data-use policies for AI models. This is a fair question for a SaaS platform handling sensitive company data, so absence of evidence yields 'none' rather than 'na'. Missing for 10: any policy statement, opt-out mechanism, or documentation addressing whether customer data is used for AI/ML model training.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Carta—none0/10

   No evidence in the pack addresses data retention or deletion controls, privacy policies, or data lifecycle management for AI/MCP integrations; community evidence instead raises concerns about data misuse (e.g., cap table data used for solicitation) without any deletion/retention control mechanism documented. missing for 10: any data retention policy, deletion/export controls, or privacy settings applicable to AI-connected data access.

   • [community] “Carta sales rep reached out unsolicited to a family member/angel investor whose investment was never publicized, at exactly the company's Se…”
   • [community] “Carta announced it would exit its secondary trading business after backlash, but commenters noted this didn't address deeper questions about…”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence covers credential/access-token revocation and rotation, but there is nothing about data retention policies, data deletion of user/company data, or export/erasure controls for AI-native use. missing for 10: data retention policy documentation, data deletion/erasure workflow, export controls tied to AI agent usage.

   ⚑ flag

Audit trail

1. ops userEvery change to the cap table is captured in an audit log — who changed what, when, and under what authorization

   weight 1 · round drawn
   Carta—none0/10

   The evidence pack covers API/platform access, OAuth scopes, MCP integrations, and data retrieval endpoints, but nowhere documents an audit log capturing who changed the cap table, when, and under what authorization. No evidence of change-tracking, audit trail, or authorization logging features exists in the pack.

   ⚑ flag

   Ledgy—none0/10

   No evidence of a change/audit log tracking who changed what, when, or under what authorization for the cap table; evidence covers authentication, API scoping, and reporting features but nothing about audit trails or change history. Missing for 10: any mention of audit log, change history, user attribution for edits, or authorization trail.

   ⚑ flag

Exports

1. ops userExport my complete cap table and full transaction history to open formats (Excel/CSV) at any time — my ownership data is never held hostage

   weight 2 · round to Ledgy
   Carta!disputedcontradicted4/10

   Carta's API exposes cap table, stakeholder, option grant, convertible note, and FMV data programmatically (carta-docs-18–23) and its data warehouse supports SQL export/queries (carta-docs-17, carta-docs-29), suggesting technical export capability exists. However, this is not the same as an easy self-serve Excel/CSV export — no docs mention a native CSV/Excel export button, and a competitor (Eqvista) and multiple founders report that Carta makes cap table data specifically hard to transfer out and cancellation practically impossible without lengthy rep interactions (carta-comm-5, carta-comm-7), directly contradicting the 'never held hostage' claim. Missing for 10: explicit self-serve CSV/Excel export documentation, independent confirmation that full transaction history (not just current cap table) can be exported, and evidence refuting the migration-friction complaints.

   • [claimed-docs] “It unifies your firm's most critical data—from fund performance and portfolio financials to partner capital accounts—into a single, queryabl…”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”
   • [claimed-docs] “Retrieve stakeholders. A stakeholder is a person or entity that has been issued a security by an issuer and is, therefore, on the issuer's c…”
   • [claimed-docs] “Retrieve option grants.”
   • [claimed-docs] “Retrieve convertible notes.”
   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “Analysts are free to perform sophisticated, multi-faceted SQL queries and analyses without the friction of integrating disparate data source…”
   • [community] “Carta's cancellation process requires a meeting with a customer success rep before you can cancel, and founders report being unable to sched…”
   • [community] “I'm the founder of Eqvista, a Carta competitor; we've seen significant migrations from Carta due to cost, lengthy 409A valuation timelines, …”

   proof ↗⚑ flag

   Ledgy~partialclaimed5/10

   Ledgy's docs mention building custom reports/views and 'custom views and exports' for compliance reporting, plus an API (companyCaptable operation) for pulling cap table data, which implies some export capability. However, there is no explicit confirmation of Excel/CSV format exports, no documentation of a full transaction-history export, and no statement guaranteeing unrestricted, anytime data portability without vendor lock-in. missing for 10: explicit CSV/Excel export format documentation, full transaction-history export scope, explicit anti-lock-in / data-portability guarantee.

   • [claimed-docs] “The companyCaptable operation is a Ledgy interface for one specific company. The operation user can retrieve cap table data about the querie…”
   • [claimed-docs] “Build reports based on your needs: play with columns and views and aggregate grouping to see your data, your way.”
   • [claimed-docs] “One-click equity compliance reports, custom views and exports, make meeting compliance deadlines a breeze.”
   • [claimed-docs] “Bring historical transaction data into your cap table, with documents attached for maximum visibility and accuracy.”

   proof ↗⚑ flag

Education

1. employeeThe platform explains my equity in plain language — tax treatment, exercise windows, dilution — not just numbers

   weight 1 · round drawn
   Carta—none0/10

   Evidence is entirely API/developer-platform documentation (cap tables, FMV calculations, OAuth, MCP plugins) aimed at engineers and integrators, not employee-facing plain-language explanations of tax treatment, exercise windows, or dilution. There is no evidence of an employee-facing UI or educational content that translates equity data into plain language for stakeholders. Missing for 10: employee-facing plain-language equity education content, UI walkthroughs explaining tax treatment/exercise windows/dilution, any hands-on or user testimony about clarity of employee communications.

   • [claimed-docs] “This API can be used to calculate the tax implications of a user exercising their equity.”
   • [claimed-docs] “The formulas below show how to calculate the following outstanding and fully diluted percentages using our Capitalization Table endpoint”
   • [claimed-docs] “Retrieve an issuer's capitalization table by share class.”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence covers API auth, cap table admin features, compliance reporting, and trading/settlement, but nothing addresses employee-facing plain-language explanations of tax treatment, exercise windows, or dilution impact. Missing for 10: employee education content, tax explainer tools, exercise window guidance, dilution simulators aimed at employees.

   ⚑ flag

Exercising

1. employeeExercise my vested options online — including payment and the resulting share issuance — without paper forms

   weight 2 · round to Carta
   Carta!disputedcontradicted4/10

   Carta's docs only cover API/tax-calculation aspects of exercising equity (e.g., FMV/tax implications endpoint) rather than documenting an employee-facing online exercise-and-payment workflow, but a first-hand community report confirms the feature exists in practice — an employee exercised ~$20k of vested options online — and also documents a concrete failure: a single automated bank transfer failed, overdrafted the user, and Carta then permanently canceled the exercise rights with no retry or warning. This directly contradicts a smooth 'exercise, pay, and receive shares without paper forms' experience. Missing for 10: first-party documentation of the employee exercise portal/workflow itself, evidence of reliable payment handling, and confirmation of automatic share issuance without manual intervention.

   • [community] “After leaving my company I exercised options for ~$20k; six months later Carta attempted a single bank transfer, it failed and overdrafted m…”
   • [claimed-docs] “This API can be used to calculate the tax implications of a user exercising their equity.”

   proof ↗⚑ flag

   Ledgy—none0/10

   Evidence covers cap-table management, grant automation, financial reporting, and a trading/settlement/payout system (nominee, broker, paying agent, Airwallex payouts) for share transactions, but nothing describes an employee-facing online option-exercise workflow that includes paying the strike price and triggering share issuance without paper forms. missing for 10: documentation of an exercise request flow, payment collection for exercise price, and automated share issuance upon exercise.

   • [claimed-docs] “Ledgy connects nominee, broker, and paying agent, all in one place to streamline global employee trading.”
   • [claimed-docs] “Enable global employee payouts thanks to a direct integration with international paying agent, Airwallex. Employees can receive payments in …”
   • [claimed-docs] “Employees can receive payments in 170 countries, and over 60 currencies, at competitive FX rates.”
   • [claimed-docs] “One trading and settlement platform that enables participants and admins to keep track of past and current market orders from the moment the…”

   proof ↗⚑ flag

Portal

1. employeeI get my own portal showing my grants, vesting progress, strike price, and what my equity could be worth under different outcomes

   weight 3 · round drawn
   Carta—none0/10

   The evidence pack only covers Carta's developer/API platform (OAuth, MCP, cap-table endpoints) and community complaints about sales/cancellation practices; there is no evidence describing an employee-facing portal showing grants, vesting progress, strike price, or scenario-based equity valuation. Missing for 10: any documentation or screenshots of the employee equity dashboard/portal UI, vesting visualization, or outcome-based valuation tool.

   ⚑ flag

   Ledgy—none0/10

   The evidence pack focuses on API authentication, cap table administration, compliance reporting, and trading/settlement features, but contains no mention of an employee-facing portal showing grants, vesting progress, strike price, or scenario-based equity valuation. missing for 10: any documentation of an employee equity portal, vesting progress visualization, strike price display, or outcome/scenario modeling tools.

   ⚑ flag

International

1. ops userNon-US valuations and schemes — UK HMRC/EMI valuations, country-specific option plans — are supported for my international entities

   weight 1 · round to Ledgy
   Carta—none0/10

   The evidence pack covers Carta's API platform, MCP integration, and 409A/FMV endpoints generically, but contains no mention of UK HMRC/EMI valuations, non-US option schemes, or any country-specific plan support for international entities. Missing for 10: any documentation of HMRC/EMI valuation support, non-US equity scheme handling, or international entity-specific compliance features.

   ⚑ flag

   Ledgy~partialclaimed4/10

   Ledgy's docs show international financial reporting (IFRS 2, UK GAAP, US GAAP) and 'global mobility reporting' for cross-border equity and tax, implying some non-US support, but there is no explicit mention of UK HMRC/EMI valuation schemes or country-specific option plan types. Missing for 10: explicit HMRC/EMI valuation support, documentation of country-specific option plan templates, and independent confirmation of non-US scheme compliance.

   • [claimed-docs] “Generate a broad suite of financial reports instantly to account for equity under IFRS 2, UK GAAP or US GAAP, with tranche-level details in …”
   • [claimed-docs] “Global mobility reporting helps you stay on top of equity and tax as your workforce moves across borders.”

   proof ↗⚑ flag

Us 409a

1. founderOrder an audit-ready 409A valuation in-platform, generated from my live cap table data, and get refreshed valuations on schedule

   weight 3 · round to Carta
   Carta~partialclaimed3/10

   Docs confirm Carta's platform associates FMV/409A valuation data with the cap table and exposes it via an API endpoint (carta-docs-23, carta-docs-13), implying 409A valuations are a native, cap-table-linked feature, but there is no evidence describing an in-platform ordering flow, audit-ready deliverable, or scheduled refresh cadence. Missing for 10: documentation of the valuation ordering/request workflow, audit-readiness/compliance packaging, and automatic scheduled refresh mechanics.

   • [claimed-docs] “Retrieve the fair market values of an issuer, which are the values of the issuer's securities as determined by the issuer's 409a valuations.”
   • [claimed-docs] “This API can be used to calculate the tax implications of a user exercising their equity.”

   proof ↗⚑ flag

   Ledgy—none0/10

   The evidence pack covers API auth, cap table management, equity plans, compliance reporting, and trading/settlement, but contains no mention of 409A valuations, audit-ready valuation reports, or scheduled valuation refreshes.

   ⚑ flag