My Bill Doctor is an early-stage dental plan and bill comparison product. The first prototype exposed a real need—and showed why a polished answer is not enough when the underlying financial facts cannot be traced and checked.
beta-archive.main begins from a clean rebuild brief, not inherited app code.Status here describes the verified archive/restart checkpoint, not a live connection to development activity. Planned work remains planned until supporting evidence is added.
A patient receives a treatment plan, has insurance, and still cannot tell what the office is charging, which plan terms apply, what an upgrade buys, or what to ask before agreeing. The same confusion can remain after payment.
“I am on a tight budget. What lower-cost option should I ask about, what does my plan actually say, and what would I give up by declining the premium option?”
The answer should be balanced: premium options can be reasonable; a price difference is not automatically misconduct.
The proposed wedge is personal-plan comparison at the moment of a pricing decision—not generic code lookup or a broad medical-bill chatbot. A short, grounded explanation can reduce the work needed to turn confusing documents into useful questions.
Potential defensibility: trustworthy workflow, a domain-specific evaluation set, evidence-linked rules, and distribution that reaches users at the right moment. These are assets to build, not established advantages today.
| Business question | Current position | Evidence to collect next |
|---|---|---|
| Demand | Founder/user pain and repeated product feedback; not broad market validation. | Observed pilot use, completion, useful-question feedback, and repeat intent. |
| Revenue | One-off checks or a paid ongoing service are hypotheses. No validated pricing is claimed. | Willingness-to-pay conversations after users receive a trustworthy result. |
| Distribution | Educational content and referrals are proposed channels, not proven acquisition engines. | Source of qualified uploads and completed checks. |
| Economics | No reliable production cost per successful analysis is established. | Hosted compute, retries, explanation tokens, failed jobs, and review effort per completed case. |
| Expansion | Dental first. Broader medical, insurance, or household bills are not launch scope. | Evidence that the first supported dental workflow is useful and repeatable. |
This report does not claim market size, revenue, clinically validated outcomes, confirmed overcharges, or money recovered. A successful transcription test is not commercial traction.
| Stage | What was attempted | What it revealed |
|---|---|---|
| Concept | Upload the user's plan and photograph a dental treatment document; explain costs, options, and questions. | The product needed a personal comparison, not generic fair-price or code-lookup output. |
| Fast interface prototype | Vanilla web interface with plan uploads, bill/estimate/receipt inputs, cards, and financial tables. | A readable interface does not validate the meaning or correctness of its numbers. |
| Model-driven extraction | Vision extraction and plan interpretation through MiMo. | Wrong columns, misread codes and amounts, lost cents, dropped rows, and mixed sections could still produce plausible output. |
| Repeated patches | Fuller PDF input, explicit column schemas, separate extraction/analysis, retries, parallel requests, and plan-text regex lookups. | Some individual tests improved, but the application still mixed unverified output with checked values. |
| User challenge | A core-buildup row displayed a different procedure's plan amount. Paid documents were still described as amounts owed. | The issues were not only reader quality; joins, precedence rules, state handling, and verification were defective. |
| Correctness review | Read source and exercised small functions rather than relying on success responses. | Found runtime rendering defects, unknown-to-zero behavior, inherited alternative costs, weak totals validation, and scratch-dependent tests. |
| Archive and restart | Preserved the prototype on a branch and tag; prepared a clean main branch. | The project is early enough to rebuild the financial foundation instead of defending patchwork assumptions. |
| Failure class | Observed problem | Required replacement |
|---|---|---|
| Transcription | Amounts and procedure codes could be misread, rows dropped, or money columns displaced. | Preserve source cells/spans, document completeness and uncertainty; validate against independently reviewed examples. |
| Meaning | “Estimated Fee” was treated as universally equal to a plan copay; zero insurance payments were interpreted as no plan applied. | Keep original headers and document-specific meaning. Do not infer financial state from a column name or a zero alone. |
| Row identity | Model row numbers drifted; code-only matching ignored repeated services, teeth and visits. | Unique document/page/row IDs. Code, tooth, surface, quantity and date remain attributes, not identity. |
| Plan facts | A nearest-dollar regex or model guess could be promoted to an authoritative benefit. | Structured benefits with source citations, conditions, plan version and unresolved applicability. |
| Unknown handling | Missing copays could count as zero; an alternative could inherit the original procedure's cost. | Typed unknown states that survive totals, alternative cards, shared output and explanations. |
| Reconciliation | A matching total was treated as broad success; checks accepted absent totals and sub-dollar differences. | Integer-cent validation of available sections and columns, plus cell/code checks. No totals means unverified—not passed. |
| Payments | Patient-responsibility estimates were confused with paid amounts; a paid-mode value was discarded. | Distinguish estimated responsibility, user-reported payment, receipt-confirmed transactions and remaining balance. |
| Runtime behavior | A label/column-fix block sat outside its rendering scope and swallowed errors. | Runtime/browser assertions against the rendered result; do not hide programming errors in empty catch blocks. |
| Benefit comparison | A covered crown alternative could pair with the first other major procedure on the tooth. | Explicit same-scope treatment matching. Crown-only and crown-plus-buildup packages are not interchangeable totals. |
| Testing | A test depended on temporary scratch source and did not form a portable failing release gate. | Project-owned fixtures/modules, nonzero test failures, regression cases and end-to-end browser checks. |
| Claims | Differences could become “savings,” and optional treatments could be described as clinically equivalent without proof. | Conditional financial comparisons and questions. Do not certify refunds, overcharges or clinical suitability. |
| Completeness and security | Files/pages could be silently skipped, while untrusted content entered HTML rendering. | Visible ingestion inventory, explicit limits, safe output rendering and server-side validation. |
A model can explain checked data without being trusted to select prices, join rows, or invent missing conditions. Its response must not overwrite the evidence it is meant to explain.
A regex returns the same result repeatedly, but may select the wrong dollar amount. A calculation can be exact while its input meaning is wrong. Both extraction and interpretation need evidence.
Parsing a script and receiving an API success were mistaken for a working result. Tests must check what the user sees: the right row, amount, source, state, and wording.
Output budgets and parallel calls were explored before correctness was dependable. Performance work is useful only after the accepted workflow is accurate or honestly abstains.
Enlarging an image does not restore missing detail. Retrying is not verification. Totals must detect possible misreads, not pressure a model to change digits until the sums fit.
Stacked handoff notes became contradictory. The clean rebuild brief is the active scope; archive documents are a record of prior thinking, not competing instructions.
This is a replacement of an early, unvalidated implementation—not a rewrite of a mature, revenue-generating platform. Archiving preserves the learning while preventing the old code from becoming an accidental dependency.
beta-archive into main. Use focused feature branches for new work. Consult the archive to understand a failure, not to copy the financial engine.Planned, not implemented One pipeline with clear responsibilities. It must work without the owner's computer or a personal graphics processor being online.
Plan, estimate, bill and receipt remain distinct. Inventory files/pages and preserve originals for the processing job.
PyMuPDF for usable native text; Docling for scanned/image pages or failed native extraction. Preserve positions and reading structure.
Keep raw labels; assign unique row IDs and supported financial meanings. Ambiguity remains visible.
Use cited benefits and tested integer-cent calculations. Reconcile scope, discounts, payments and balances.
Generate understandable summaries and questions from structured findings. Do not introduce new amounts or medical certainty.
Link each fact to evidence; distinguish verified, conditional and needs-review states. Corrected input invalidates dependent findings.
| Layer | Archived prototype | Clean-build direction | Status |
|---|---|---|---|
| Website | Single-file vanilla HTML, CSS and JavaScript on the shared reports host. | Simple browser interface; avoid a framework migration for its own sake. | New app not built |
| Native PDFs | Browser pdf.js text extraction, with historical page/character limits. | Hosted PyMuPDF extraction with positions and completeness accounting. | Chosen starting path |
| Scans and photos | Canvas-prepared images sent to MiMo vision extraction. | Hosted Docling, tested against supported real layouts; explicit review when unreadable. | Chosen starting path |
| Financial logic | Browser arithmetic, regex copay mapping, and model fallbacks. | Validated data contracts, rule applicability, evidence-linked benefits, integer cents and explicit unknowns. | To implement |
| Explanations | MiMo combined extraction, benefits reasoning and prose generation. | Keep MiMo initially, narrowed to explaining structured checked findings. | Baseline choice |
| Application API | Cloudflare Pages Function with extraction/analysis modes and parallel model calls. | Small online orchestration layer calling a hosted parser; final interface selected during implementation. | Design and implement |
| Hosting | Cloudflare Pages project cf-reports; old app path remains a demo. | Hosted parser service; CPU suitability measured before adding infrastructure. No personal hardware dependency. | Provider unresolved |
| Database | No reviewed shared benefits library. | No plan database in the first milestone. Add versioned caching only when trustworthy and necessary. | Deferred |
| Testing | Targeted API runs and a limited scratch-dependent lookup test. | Portable tests, source-backed fixtures and browser acceptance checks. | To establish |
| Coding environment | Hermes-led iterative prototype work. | OpenCode as an implementation environment; coding-agent model selection is separate from the app's MiMo API. | Owner direction |
The parser choices are a committed starting approach, not a completed benchmark or accuracy guarantee. Review package licenses, pinned versions and hosting compatibility before distribution; zero new subscription or hosting prices are promised here.
The central change is not “a smarter model.” It is a data contract that makes it difficult to display a financial conclusion without a supported path back to the documents.
| Record | Required information | Prevents |
|---|---|---|
| Source field | Document and page ID, original label/value, normalized value, text span or bounding box, extraction method and verification state. | A plausible amount losing its source or column meaning. |
| Procedure row | Unique row ID plus code, tooth/surface, quantity, visit/date, document role and relationships. | One procedure's copay or explanation drifting to another row. |
| Plan benefit | Source entry, base amount, conditions, effective plan identity/version and unresolved applicability. | A nearby dollar amount becoming a guaranteed patient obligation. |
| Payment | Amount, date, source, transaction type and whether it is user-stated or receipt-confirmed. | An estimated patient amount being relabeled as paid without evidence. |
| Finding | Input IDs, tested calculation or rule, evidence references, scope and result state. | An explanation generating unsupported savings, refunds or equivalence. |
The source is identified and the supported calculation or transcription has passed the relevant checks. This is a claim about that fact—not the entire treatment decision.
A rule depends on unresolved eligibility, upgrade terms, document meaning, missing pages or uncertain transcription. Ask the user or office; do not silently fill the gap.
The system cannot assume that every office prints the same columns or even includes a procedure code on every line. Layout and semantic meaning are separate problems.
Launch discipline: start with the supplied dental maintenance organization plan scope and clearly supported document types. Check a small permissioned or de-identified set of other practice layouts. Keep some layouts out of development tuning. Synthetic variants supplement—not replace—real examples. Expand the advertised scope only after tests support it.
No calendar promises are implied. Each milestone advances on evidence rather than elapsed time. All build stages below are planned at this reporting checkpoint.
Private repository, clean main, historical beta-archive, fixed snapshot tag, credential/private-fixture exclusions and a clean rebuild brief.
No old financial code merged into the restart. No patient documents committed. Historical instructions remain reference material.
Typed document/row/benefit/payment records, integer-cent calculations and explicit unknown states. Project-owned failing-on-error tests; independently review private source annotations.
Tests catch wrong-row copays, lost payment state, inherited alternative prices, missing-to-zero conversions and reconciliation mismatches. No temporary-machine test dependencies.
A minimal hosted PyMuPDF/Docling service, upload/page inventory and source spans/crops. Evaluate the chosen path on native pages and scans; reject or flag unreadable evidence.
Supported fields are correctly extracted or visibly sent for review. Missing pages and silent truncation are detected. An online request works without a developer's local service.
Source-linked base benefits and conditional rules for the initial supported plan scope. Match related treatment documents without duplication; distinguish discounts, responsibilities and payments.
Every supported comparison uses the correct row, scope and benefit conditions. Unresolved inputs block precise final-payable or savings claims. Printed totals are checked independently.
MiMo summaries and office questions from structured findings; evidence inspection, correction and recomputation; clear estimated/paid/remaining labels.
Browser tests verify actual visible values and wording. Explanations introduce no unsupported amounts. User corrections recompute dependent findings; failed jobs do not masquerade as successful sample output.
Small additional-practice validation, explicit supported/unsupported cases, privacy/retention verification, abuse limits, staging and rollback, and an owner-approved deployment.
The hosted workflow passes its supported-case regression suite or abstains visibly. Pilot feedback supports usefulness. No personal hardware dependency; live checks run with local services stopped.
Measure time, failure/review rate, cost per completed check and repeat use before optimizing. Accounts, reviewed plan caching, broader plan support, model changes and paid features need evidence of value. Do not build them to avoid finishing the core workflow.
| Gate | Required evidence | Failure behavior |
|---|---|---|
| Correct critical fields | Source-backed money, code, tooth and document-role checks across the declared test scope. | Needs review, not an invented number. |
| Explainable calculations | Integer-cent math linked to verified inputs and relevant rules. | No unsupported total, savings or refund statement. |
| Complete ingestion | Known file/page inventory; explicit limits and failed pages. | Disclose incompleteness; do not claim all pages read. |
| Traceable benefits | Plan entry plus applicable conditions and source citation. | Unknown or conditional, not “not covered” merely because parsing missed it. |
| Honest payments | User statement or receipt evidence separated from estimated responsibility. | No invented per-row payment allocation or settled balance. |
| Rendered correctness | End-to-end browser assertions for amounts, labels, source links and error handling. | Block release when financial display regressions fail. |
| Online operation | Hosted upload → parser → rules → explanation → result with no local backend. | Not complete until online acceptance passes. |
| Privacy and recovery | Verified provider access/logging/retention, no secrets in source, staged deployment and rollback. | No stronger privacy promise or production release than evidence supports. |
No universal accuracy percentage or response-time promise has been set. Agree the pilot corpus and measurable release thresholds before assessing readiness. Report false confident conclusions separately from safe abstentions.
| Location | Purpose | Instruction |
|---|---|---|
| Private repository · main | Clean source of truth for the restart. | Begin with README.md and REBUILD-BRIEF.md. |
| beta-archive | Historical source, defect review and planning. | Reference only. Never merge wholesale into the restart. |
| v0.1.0-beta-archive | Fixed prototype snapshot. | Keep the tag unchanged; Git records the exact historical state. |
docs/project-report/index.html | Repository copy of this shared report. | Update with evidence as milestones change; publish to the same report route. |
docs/LOCAL-PROJECT-MAP.md | Private developer map with exact local workspace and report/deploy locations. | Repository access required. Deliberately not included as a public download. |
| Original prototype workspace | Preserved source and private original test documents outside the clean repo. | Keep unchanged for reference. Do not commit personal fixtures or patient-derived annotations. |
The report explains the project. Git holds the current requirements and implementation. The private fixture inventory holds original test evidence. The archive holds historical context.
If these disagree, record and resolve the discrepancy; do not silently turn a historical claim into current status.
Private GitHub links require authorized access. The source-control commits at this checkpoint are f77454c for the clean foundation and c3b9cd6 for the archived prototype. Later documentation commits do not imply new product functionality.
This report contains no patient uploads, credentials, account identifiers or absolute local filesystem paths. Its noindex setting discourages search indexing; it is not access control. Anyone with this report URL can read it.
Private fixtures and exact local paths stay in local/private developer records. Add authentication if future report content becomes confidential.
Deployment caution: the current report host is shared with earlier reports and the archived demo. A report update must preserve all existing folders and API code. Publishing this document is not approval to modify or release the new application.
Keep this stable report URL and update it as implementation evidence changes. Preserve previous report revisions in Git. Product V2 is the clean rebuild roadmap—not a claim that a second application is already complete.
| Update trigger | What to record | What not to claim |
|---|---|---|
| A milestone is implemented | Change summary, reviewed source commit, tests executed and results, unsupported cases. | “Verified” based only on intended behavior or one API response. |
| A parser or hosting choice changes | Concrete blocker, measured comparison, privacy implications and approved spend. | Universal superiority or production costs from marketing material. |
| A new layout or plan is supported | Permissioned/de-identified test scope and cell/rule/browser results. | Support for every form or every insurer. |
| An error escapes | Reproduction, user impact, root cause, correction and a regression test. | That a prompt change alone eliminates a class of errors. |
| A pilot or launch occurs | Actual usage, completion/review outcomes, costs, feedback and current release limits. | Revenue, recovered savings, retention or clinical benefits without evidence. |
| Reference | Use |
|---|---|
| Current rebuild brief · private | Owner-approved direction and initial acceptance requirements. |
| Historical correctness review · private | Recorded code defects, targeted checks and planning corrections. |
| Archived source snapshot · private | Reproducible historical reference; not a release recommendation. |
| PyMuPDF documentation | Implementation reference; does not establish performance or accuracy on our documents. |
| Docling documentation · Model repository | Implementation candidates already selected for focused evaluation; not an endorsement of unmeasured results. |
| Hugging Face Spaces documentation | Potential hosting reference. Availability, cost and access/retention behavior require verification before selection. |
| Earlier product report · Archived live demo | Historical context only. The demo contains known defects and must not be relied on for financial decisions. |
This is a project retrospective and implementation briefing grounded in the owner's decisions, repository checkpoint and recorded review. It is not a new market study, independent clinical review, parser benchmark or certification of insurance obligations.