How Balaay verifies its own claims

Every mechanism Balaay uses to keep its public claims true: the capability registry that fails the build on an overclaim, the connector status ladder, the benchmark, the proof registry, the claim gates, and a list of what Balaay currently cannot prove.

Most vendor sites ask you to trust them. This page describes the machinery that makes Balaay's claims checkable instead — a capability registry that fails the build when copy exceeds it, a connector status ladder that marketing cannot outrun, a published benchmark, a proof registry that currently holds nothing, and three claim gates that run inside the deploy. It also lists what Balaay cannot currently prove, because that list is the honest part of the answer.

The capability registry

Every capability is recorded as shipped, partial or not implemented, with the file that proves the status so a reviewer can check rather than trust. 13 are shipped; 5 are not, and the not-implemented list is enforced: the site build fails if any page asserts one, including in a paraphrase or a JSON-LD feature list.

Shipped

• Answers the practice’s inbound phone calls with a spoken conversation
• Captures the caller’s name, number and reason for calling
• Escalates urgent calls to staff using rules the practice defines
• Stops booking, moving and cancelling appointments once a call turns urgent
• Offers only appointment times that are genuinely open in Balaay’s schedule
• Re-validates the slot immediately before committing a booking
• A repeated booking request cannot create a duplicate appointment
• Looks up an existing patient and the appointments they already have
• Moves an existing appointment to a new time on the call
• Cancels an appointment, or hands it to staff when the practice’s policy requires that
• Records the appointment and confirms it with the patient
• Never tells a caller an action succeeded unless it can verify that it succeeded
• Keeps a record of every appointment action it took or refused

Not implemented — and therefore not claimed anywhere

• Does not read your Google Calendar. Balaay works from its own schedule, configured to your hours.
• Does not yet use your practice-management system as the source of truth. The connector is built and unverified.
• Does not write into the calendar your team already opens. Appointments live in Balaay until a connector ships.
• Does not create appointments in Dentrix, Eaglesoft or any other practice-management system.
• Does not check insurance eligibility. It answers from the plan list you configure and will not estimate coverage.

Connector status, and why marketing cannot outrun it

A practice-management system may only be described as integrated once a real practice’s real workflow has run against the live system. The runtime enforces the same rule the marketing does: integrations/registry.ts refuses to hand a connector below that bar to a live call, so a page cannot claim a capability the code would decline to perform.

Per-system detail →

What counts as proof here

Seven levels, each stating what a page may DO with evidence at that level rather than just naming it. Everything above level 5 requires a real customer, which is why none of it is in use.

The claim gates

Three checks run inside the Docker image build, after the site is built and against the shipped files. A failure fails the image, so it cannot be deployed past — they were previously run by hand, which meant a fabricated claim could ship whenever nobody remembered to look.

• Capability and claim audit — roughly 22,400 checks across every rendered page, markdown mirror and JavaScript bundle. Blocks any assertion of an unimplemented capability, any unsourced statistic, and any customer claim with no registry entry.
• Proof-registry adversarial checks — 35 checks that attempt to publish fabrications, including every example the brief names: a combined customer count, a revenue figure derived from appointment volume, an accuracy percentage without a denominator, a revoked logo, and a case study containing a patient name.
• Contradiction audit — compares the same fact across all pages and bundles, because two pages that are each individually defensible and mutually incompatible leave a reader no way to know which is true.

Superiority claims are gated, not self-assessed

Balaay may not describe itself as best, #1, leading, market leader, most trusted or highest rated until every criterion below is met. Currently permitted: no.

Notably absent from that list: traffic, funding, feature count, and how good the product feels to us. A superiority claim needs a measurement someone outside the company could reproduce.

Sample thresholds

Set before any data existed, so they cannot be adjusted to fit a result.

• No percentage or rate may be published below 30 qualifying observations. 9 of 10 is not "90% reliability".
• A per-practice outcome needs a full month and 100 handled calls before it describes anything but a startup period.
• An aggregate across practices needs 5 or it is a handful of anecdotes with a mean.
• A reliability figure needs 100 attempts, and is always published as "n of N", never as a bare percentage.

Shared definitions

One definition per term, used in the product, the benchmark, the research and any future case study — with an audit check that fails if they drift apart. A figure that means one thing in a research table and another on a sales page is how a number quietly becomes a lie.

Full definitions → · Benchmark methodology → · Corrections log →

What Balaay cannot currently prove

The honest half of the answer. Each entry names what would close it.

• Practices save staff time
  No baseline of front-desk callback hours exists, and no practice has been measured before and after.
  Needed: Pre-launch time capture from 5 practices, then 30 days of comparison.
• Balaay books appointments a practice would otherwise lose
  Requires a pre-Balaay missed-call baseline. Nobody has one.
  Needed: Carrier or phone-system call logs for the 30 days before launch.
• Balaay produces revenue
  No access to any practice’s posted production, and no defensible attribution rule applied to real data.
  Needed: Read access with permission, plus the DIRECT attribution test on real bookings.
• Patients are satisfied talking to Balaay
  No patient has been surveyed. Practices have not been asked either.
  Needed: A post-call question, with the practice’s consent, and a sample above 30.
• Balaay is reliable in production
  Reliability is measured in the benchmark under test conditions, not in production across practices.
  Needed: 100 verified-appointment attempts in production; report as n of N.
• Any customer count
  There are no paying practices and no pilots. The only record in the system is the demo practice.
  Needed: A first paying practice.

Corrections

Errors are logged with the original statement, the correction and the reason. The log is appended to, never rewritten — two of its three entries correct Balaay’s own earlier research rather than a competitor fact. If you find something wrong here, that is a defect rather than a position, and we want to know.

Related pages

• AI Dental Receptionist
• Pricing
• Missed Call Recovery
• Dental Answering Service
• Practice Management Blog
• Dental Receptionist Cost Calculator

Explore Balaay

In summary

How Balaay verifies its own claims — Every mechanism Balaay uses to keep its public claims true: the capability registry that fails the build on an overclaim, the connector status ladder, the benchmark, the proof registry, the claim gates, and a list of what Balaay currently cannot prove. Balaay is an AI voice receptionist for dental practices that answers calls, books appointments, and escalates urgent calls to staff.

Loading interactive experience…