A standing product commitment. This document is public at dacard.ai/commitments/adapter-tiers.

The commitment

Dacard will not advertise community-tier adapters as production-grade integrations in any public-facing material.

The public catalog always shows which adapters are production-hardened and which are experimental. A user who reads the UI will never be misled about what they are connecting to. This is a product boundary, not a roadmap item. It will not move.

What we will never build

We will not build, ship, enable via API, or allow as a customer-configured feature:

  • A marketing page or pricing copy that claims a total integration count without separating production from community.
  • A UI that presents community adapters in the same visual weight as production adapters without a label.
  • A "50+ integrations" claim that bundles both tiers without qualification.
  • Any removal of the community-tier banner or label as a "polish" step without first completing the promotion criteria.

If a sales call asks for the integration count, the honest answer includes the tier breakdown. The answer stays honest under commercial pressure. The answer stays honest if a competitor ships a larger uncaveated count.

Why

Vanity-metric failure mode. A large uncaveated integration count is a vanity metric. It signals breadth without signaling quality. Per the no-vanity-metrics commitment, every number shown to a user must be attached to a specific, measurable outcome it predicts. A count that mixes production and experimental adapters predicts nothing useful.

Trust erosion at the moment of integration. When a customer connects a community adapter and hits a stub, an error, or a signal gap, the damage is not to the adapter; it is to the credibility of the platform. Preventing this requires honesty before connection, not apology after.

Category error. Calling an adapter "an integration" when it lacks test coverage, error handling, and production validation is a category error. The word integration carries a promise of reliability. Community adapters carry no such promise, and we will not use the word to imply one.

No-vanity-metrics commitment. This commitment is the integration-specific application of no-vanity-metrics.md. Both commitments are mutually reinforcing. Violating one violates the other.

What production-grade means

An adapter reaches the production tier when it satisfies all of the following:

  1. Size and completeness. The adapter file is 500+ lines. No stubs. All declared signal types emit real data from the provider API.
  2. Signal density. At minimum 15 signal types where the provider's API supports it. Providers with fewer signals by nature (e.g. a billing-only provider) may qualify at lower counts, but only with documented justification.
  3. Test coverage. At least one Vitest integration test exercises the sync path with a fixture or mock. The test is not a smoke test; it validates specific signal shapes.
  4. Error handling. The adapter handles credential failures, rate limits, and partial API outages without crashing the sync pipeline. Errors are surfaced in the sync log.
  5. Real-world usage signal. At least one customer account has successfully synced the adapter in production. Not a demo account.

Community adapters that satisfy all five criteria are promoted to production in a dedicated PR. The PR updates registry.ts tier field, integration-defs.ts, this document's community list, and the test in tier-registry.test.ts.

Community tier is explicit about being experimental

Community adapters:

  • Are visible in the settings catalog under the "Community (experimental)" heading.
  • Carry the banner: "Community-tier adapters are experimental. Test coverage and production hardening are not guaranteed. Use at your own risk."
  • Are still connectable. The label does not gate access; it informs it.
  • Are not listed in marketing materials as supported integrations.

Promotion process: community to production

  1. Adapter author opens a PR that satisfies all five production criteria above.
  2. PR includes a new or updated Vitest test that covers the sync path.
  3. At least one real-world sync run is documented (log link or signal screenshot in the PR).
  4. Reviewer confirms the PR against this doc's criteria before merge.
  5. On merge, the adapter's tier field moves from 'community' to 'production' in both registry.ts and integration-defs.ts.
  6. This document's community list is updated to remove the promoted adapter.

Current community adapters (as of 2026-04-24)

The following 30 adapters are community-tier at launch:

  • slack, attio, salesforce, dx, hivel, dragonboat, fibery, jellyfish, dotwork, klue, orb, aws-cost-explorer, slack-webhook, enterpret, canny, notion, incident-io, braintrust, dovetail, heap, statsig, eppo, mintlify, gitbook, userpilot, jira-product-discovery, prodpad, chatprd, plane, zeda, clickup, asana, monday, claude-code, claude-design, cursor, github-copilot, v0, windsurf, lovable, devin

This list is updated whenever an adapter is promoted or a new community adapter is added.

How you can hold us to this

1. Public catalog. The settings page at dacard.ai/app/settings/integrations always shows tier labels. Any regression (labels missing, community and production merged into one unsorted list) is a violation of this commitment.

2. Product enforcement. The IntegrationsSettings component renders two visually distinct sections: "Production" and "Community (experimental)". The community banner is not a user preference; it is rendered unconditionally. Removing it requires a code change that will appear in git history.

3. Marketing guardrail. No copy in apps/web/src/app/(www)/ may claim a total integration count without the tier breakdown. This is enforced by code review and this commitment.

4. Test enforcement. packages/core/src/integrations/__tests__/tier-registry.test.ts asserts exactly 22 production-tier adapters and the specific set. Any attempt to inflate the production count without meeting the promotion criteria will fail this test.

5. Violation disclosure. If this commitment is breached (an adapter is promoted without meeting criteria, or the catalog hides the tier distinction), we will disclose it in the changelog and revert within one business day.

What this commitment does not prevent

  • Adding new community adapters. Community is the correct entry state for new adapters.
  • Connecting community adapters. Users may connect them; they are simply told they are experimental.
  • Promoting adapters quickly. If an adapter genuinely meets all five criteria within a week of being added, it can be promoted immediately.
  • Using community adapters in internal tooling or demos, with appropriate internal labeling.
  • Describing the total number of adapters in non-marketing contexts (e.g., this document, internal planning) as long as the tier split is included.

The line is clear: every adapter the public catalog shows carries an honest label about what it is.

Signed on behalf of Dacard, 2026-04-24.* *Revisions, if any, will be logged here with date, reason, and 90-day notice to customers.

Honest catalog, always | DAC Commitments | DAC