For Sales

The honest framing, first

You cannot sell this. PR #241 changes one internal CI workflow file. It adds no capability a clinic can use, see, or pay for. There is no demo, no pricing implication, no feature-comparison row.

What it is: a concrete, defensible answer to a question you already get from larger buyers — "how do you test your software before it reaches our clinic?" For dental groups, hospital systems, and anyone running a procurement or IT-security review, that question is a real gate. This page gives you an accurate answer to it.

Business view

The 30-second version

Every change our engineers make gets its own isolated copy of the full Dentolize system — real database, real data — and an AI QA agent reviews the code and drives that copy through real clinic workflows in a browser: booking appointments, issuing invoices, running the roles a receptionist or an accountant would. An engineer reviews and corrects the AI's analysis at two checkpoints before any test runs, and every scenario tested is recorded as a tracked ticket with its result. Nothing merges on the AI's word alone.

Every clause there is true and backed by code. Do not extend it.

Why the human checkpoints are the selling point

The instinct is to lead with "we use AI to test everything." Resist it. In healthcare procurement, unsupervised AI is a concern, not a feature. Buyers have spent two years being told AI will handle things and have learned to ask what happens when it is wrong.

Lead with the checkpoint instead:

We assume the AI gets things wrong. So the process is built so an engineer reads its analysis and corrects it before it tests anything, and again before it changes any code. The AI drafts; a person decides.

This reframes AI from a risk you are taking to a risk you have engineered around. It is also simply true — it is what this PR implements.

What changed vs. what already existed

Be careful not to over-credit this PR in a conversation.

Most of the story you'll tell was already true. This PR added the supervision layer. If a prospect asks "is this new?", the accurate answer is: the environment-per-change testing has been in place; the human review checkpoints are a recent addition.

Objection handling

"So AI writes your code?"

No — and be crisp here. AI is used in QA, not feature development. Within QA, three of the five available actions cannot modify code at all; they only produce analysis and test results. The two that can propose fixes are triggered deliberately by an engineer, and their commits go through the same human code review as any other contribution. The default action in the tool does not touch code.

(Backing: .github/workflows/sandbox-qa.yml:30 — default is the non-committing action; :50-53 — the workflow's permissions; :139 — analysis actions exit before any write path.)

"How do you know the AI's tests are testing the right things?"

Because an engineer reads and edits them before they run. The AI's test plan is posted as an editable document; engineers delete scenarios that are wrong, add ones it missed, and correct the roles. What then runs is the corrected version — not the AI's original.

(Backing: :76-82 reads the human-edited text back; :133 — the plan comment's own header reads "edit freely; test runs exactly this".)

This is the strongest single answer in your kit. It is specific, it is verifiable, and it directly addresses the fear behind the question.

"Is our data used for this?"

No. Testing runs against synthetic seed data in a disposable environment built for that change — fabricated patients, fabricated invoices, fabricated staff accounts. Production data is not involved, and the environment is destroyed when the change is merged or abandoned.

(You can show this: the screenshots in the Feature Tour are from a live test environment. Every patient in it is named "Patient 006".)

"What if the AI misses something?"

It will, and the process assumes it. The AI QA layer is one gate among several — human code review, the engineer's own testing, and staged release still apply. Its job is breadth: mechanically walking dozens of clinic scenarios across multiple staff roles on every change, which is exactly the work humans do inconsistently. It does not replace judgement, which is why the checkpoints exist.

"Can you show us evidence of testing for a specific change?"

Yes, in principle — each tested scenario becomes a tracked ticket with its outcome, and the full run log and evidence are retained for 14 days.

Caveat before you promise anything: those tickets live in the internal engineering repository. Sharing them externally is a decision for Engineering, not a commitment you can make on a call. Say "I can ask what we're able to share" — never "yes, we'll send you the test results."

(Backing: :191-200 — issue per scenario; :241-250 — 14-day artifact retention.)

"Is this certified / does it meet [standard]?"

No, and do not imply otherwise. This is an internal engineering practice, not a certified process, not an audited control, and not part of any compliance attestation. Describe it as how we work, never as what we are certified for. Route any formal compliance question to the appropriate owner.

Competitive angle

Use sparingly and only when a prospect raises quality or reliability.

Most dental-practice-management vendors of Dentolize's size test manually and release on a schedule. "Every single change gets its own full copy of the system and is browser-tested across staff roles before it can merge" is genuinely above the norm for the segment, and it is checkable — it explains why bugs in appointment booking or invoicing don't reach clinics.

But do not turn it into a claim about outcomes. There is no measured defect-reduction number, no uptime figure attributable to this, and no benchmark against a competitor. If you need a number, ask Engineering to produce one first. Inventing one is both wrong and fragile.

Words to avoid

Technical view (for the engineer on the buyer's call)

If a prospect puts a technical person on the call, this is what is actually true — stated at the level they'll want.

• Each pull request gets an ephemeral, fully seeded deployment of the whole

stack (API, web, database), routed at its own hostname, destroyed on merge or close.

• A QA agent runs headless against that deployment. It has five dispatchable

actions: review (code analysis), plan (generate user-story scenarios), test (execute them via Playwright), fix (attempt repairs and re-test), and full-auto (all four).

• The outputs of review and plan are posted as GitHub PR comments and are

editable; the subsequent action re-reads the comment body from the API and uses the human-edited version (.github/workflows/sandbox-qa.yml:60-82).

• test executes scenarios per clinic role — owner, doctor, receptionist,

accountant — against seeded synthetic data, and files one issue per scenario with PASS / FAIL / FIXED / SKIPPED (:172-207).

• Only fix and full-auto write to the branch; their commits enter normal

human code review (:50-53).

• Run evidence — agent log, plan, raw results — is retained as a build artifact

for 14 days (:241-250).

If they push further than this, get an engineer on the call. The internal documentation is candid about the tool's limits — see Operating notes — and that candour is not material for a sales conversation.