Expected nonqualifying
300
Proof center
Observed August 31, 2026
Tested against the cases that should move—and the ones that should stop.
Kept Count's repeatable synthetic suite checks qualifying paths, deliberate nonqualifiers, changing monthly states, and duplicate-month conflicts against a fixed answer manifest. No PHI. No customer records. No inflated capacity claim.
Expected holds
Failure cases were designed in—not edited out.
The answer manifest deliberately included four reasons a record should not move into the qualifying path. The separate rule pass matched each expected category and output flag.
Expected nonqualifying
300
No consent
Expected nonqualifying
200
Missing element
Expected nonqualifying
100
Duplicate month
An additional stress case inside the qualifying population
The packet also included 100 mid-month tier-change cases to test how a changing monthly state was classified. They are part of the same 10,000 records and are not part of the 900 nonqualifying total.
Stateless execution boundary
A clean-room software check, with the boundary in plain view.
The run isolated classification behavior from production systems. That makes the result reproducible, but deliberately narrower than a production-readiness test.
No PHI
Every name and identifier followed a deterministic synthetic convention.
No database
The stateless classifier ran without a database connection.
No network
The run made no network calls or external service requests.
No persistent writes
It created no lasting application or CRM records.
From classification to monthly close
See how a held record stays held.
The synthetic monthly-close view translates the control model into a reviewable queue. It illustrates the intended workflow; it is not evidence of a production deployment or submitted claim.
Synthetic interface
Monthly-close control view
The interface keeps exceptions and final human review visible before any downstream billing decision.
- 01
Separate candidates from holds
A review queue keeps unsupported work out of the ready path.
- 02
Give each exception a reason
Consent, coverage, missing evidence, and overlap questions remain visible.
- 03
Keep a named human reviewer
Provider and billing teams retain approval and final claims authority.
- 04
Export evidence, not a claim
Kept Count prepares review material; it does not auto-submit claims.
Product walkthrough
Watch one month move from scattered work to human review.
The walkthrough explains the input, the deliberately blocked cases, the stateless boundary, and the human approval point. All people shown are synthetic.
- Start with a fixed synthetic answer manifest
- Compare every output with the expected answer
- Inspect reason-coded holds and tier changes
- Keep the final operating decision with the provider team
Synthetic proof walkthrough
No PHIMethodology
Reproducible by design.
The receipt pins the seed, command, source hashes, measured runtime, expected categories, and result. It can be inspected without turning a narrow software test into a broader production claim.
The current reference receipt records 10,000 synthetic cases: 9,100 expected qualifying outputs and 900 deliberate nonqualifiers. This is the documented test packet, not a capacity ceiling.
Step 1
Generate a fixed answer manifest
Seed 42 produced the same 10,000 synthetic people and expected output categories for repeatable evaluation.
Step 2
Pin the code under test
The receipt records the base commit and SHA-256 hashes for the generator and classifier sources.
Step 3
Run without application state
Environment connections were removed before three deterministic 10,000-record scanner scenarios ran.
Step 4
Compare every expected code and flag
A separate rule pass matched the expected code and qualifying flag for all 10,000 synthetic records.
Run count
3 stateless scenarios
Observed classification time
60–70 ms per run
Not a production-throughput claim
Receipt
docs/evidence/synthetic-scale/10000/receipt-2026-08-31.json
What this does not prove
Strong evidence begins with an honest boundary.
A passed synthetic classifier test is useful evidence about deterministic software behavior. It is not a proxy for practice policy, human judgment, production controls, or real-world acceptance.
- Clinical eligibility or appropriateness
- Billability, reimbursement, revenue, or payment
- Database, RLS, browser, API, or production concurrency behavior
- Covered-PHI readiness or production authorization
- Customer acceptance or real-world outcomes
- CMS compliance, certification, or an audit outcome
What the evidence is for
A passing test is only useful if it earns a real conversation.
Every number above exists to get your reviewers to the table, not to stand in for their judgment.
Independent review welcome
Bring your clinical, billing, and compliance reviewers.
We will make the evidence and its limitations available for independent review, then map the remaining practice-specific controls before any covered-data or production work begins.
Book a proof review
No patient data or technical preparation is needed for the first conversation.