Partners

Build with Deedglass, in the open.

There are four ways to partner with Deedglass: make it work with your product, run a six-week pilot on synthetic data, use and add to the benchmark, or donate scenarios and test vectors. Each one says what you get, what we ask and how to start. Partnering costs nothing.

We’re early: Deedglass has no partners and no customers yet, so there are no logos on this page. The first partners work directly with the founder.

01 · Integration partners

Make Deedglass work with your product.

For agent frameworks, MCP gateways, FHIR servers, HIS and EHR vendors, and Postgres platforms such as Neon.

You get

  • A page for your integration on deedglass.com and in the docs, written with you and listed once your check passes.
  • Co-written docs: a short, runnable recipe for your product, updated with each Deedglass release.
  • A test fixture for your product in the benchmark, so every release runs against it.
  • A “works with Deedglass” check you run yourself, on your own machine, any time. It’s a set of commands with a pass or fail, not a badge we sell.

We ask

  • One technical contact who can answer a question within a week.
  • A test environment we can run in CI: a container image, a sandbox or a test account.
  • A note before a change that would break the integration.

How to start

  1. 1Send the form below with the product and the integration path you have in mind.
  2. 2We agree one path (an MCP server, a framework hook, a FHIR server, a Postgres platform) and the test environment.
  3. 3You run the check from the integration checklist. When it passes, we publish the page together.

The open parts the check is built on

How a submitted result is run again before it’s listed: submitting a result.

No list, no newsletter, no cookies. Never paste keys or passwords: the form refuses them.

02 · Design partners in health

A six-week pilot on synthetic data.

For scribes, copilots, record systems and FHIR servers: any team whose AI writes to health records. We never receive patient data: Deedglass runs on your servers with your own Postgres and sends us nothing by default.

You get

  • Six weeks on one workflow where an agent writes to a record system, on synthetic data only (Synthea or the FHIR examples), on a test server you choose.
  • The FHIR connector (beta) in front of your test FHIR R4 server, or the Postgres connector if your app’s data is in Postgres.
  • A read-back after every write, comparing the fields your agent sent with what the server stored.
  • The free healthcare-fhir rules pack, tuned to your workflow, and sealed records anyone can check offline with your public key.
  • A short written summary at week 6: what matched, what didn’t, what we changed.

We ask

  • A short weekly check-in, in writing, with the engineer who owns the workflow.
  • Honest notes on what is missing or wrong.
  • We call you a design partner in public only if you say yes, in writing. Otherwise we never name you and never quote you.
Week by week
WeekWhat happens
1Pick the workflow; test server and synthetic data in place; first rules.
2–3The agent runs through Deedglass; read-backs and approvals tuned.
4–5Edge cases: conditional creates, unchanged updates, refusals, two-person approvals.
6Written summary; decide together whether to continue.

What it costs

Nothing. The pilot is free, and every Deedglass feature is free while we grow, so there is nothing to buy afterwards either. Paid support, SLAs and a hosted version for organisations come later; anything free today stays free for teams that run Deedglass themselves. See the pricing page.

Deedglass makes no clinical decisions, and it doesn’t make you meet any law or standard. We don’t have a SOC 2 report or an ISO 27001 audit yet.

More for hospitals and health-tech teams: Deedglass Health.

No list, no newsletter, no cookies. Never paste keys or passwords: the form refuses them.

03 · Research and academic

Use the benchmark. Add to it. Get credited.

For colleges, students and researchers. The corpus and the runner are in the open repository; the corpus has its own licence.

You get

  • The intent-vs-effect corpus: twelve SQL scenarios where what an agent reports and what Postgres commits come apart, each with its expected result.
  • The runner that scores any tool against them from Postgres’s own change log. It needs Docker and takes about a minute.
  • Credit: your name on each scenario you contribute, in the corpus and its change log, and on /benchmark when it runs there.
  • Help from the founder to reproduce a run or set up a student project.

We ask

  • Use the corpus under its licence, and cite the commit you ran.
  • Send new scenarios by pull request. Scenarios that Deedglass misses are especially welcome.
  • Tell us when you publish, so we can link to it if you agree.

How to start

  1. 1Read the corpus and the latest results.
  2. 2Run make corpus-bench from the repository.
  3. 3Add a scenario by pull request, or send the form below.

No list, no newsletter, no cookies. Never paste keys or passwords: the form refuses them.

04 · Standards and community

Scenarios and test vectors, donated.

For groups writing the rules for agent tools and health data. We aren’t a member of these groups today; we’d like to help where our test cases are useful.

What we bring

  • Scenarios and test vectors from our repository, donated to your work under the terms your group uses.
  • The record format as an open spec under CC-BY-4.0, free to quote, adapt and build on.
  • Time from the founder to review drafts and run your test cases against Deedglass.

We ask

  • Tell us where a scenario or a test vector would help a draft.
  • Credit the contribution the way your group normally does.

Where we’d like to help

  • The MCP security interest group
  • HL7 (FHIR, and the AI Transparency on FHIR work)
  • The OWASP GenAI Security Project

No list, no newsletter, no cookies. Never paste keys or passwords: the form refuses them.

Rather write? hello@deedglass.com reaches the founder.

Arjun Prabhakaran, founder