Each job gets an engine built for it.
Booking, intake, the visit, and follow-up need different information and different checks. An engine built for that job carries the difference.
AetherHeal Whitepaper v2.0 · 2026.08.19
Unfinished patient work,
carried through to done.
Clinical OS is the layer that holds several AI engines on one patient's state under the director's authority. It runs beside the chart. It does not replace the EMR. It shows how far a patient has come and who approved what, and it keeps the reasoning as a record. This whitepaper also sets out the Golden Clinical Loop, which runs from the physician's confirmation to the evidence that the work finished.
This web summary keeps the claims and the per-product evidence boundaries of the 2026.08.19 edition.
Executive summary · A medical AI engine company built by a practicing physician
What has not finished yet,
carried into execution someone answers for.
The chart records what finished. We handle what has not finished yet.
Purpose-built AI engines for each job in care, and a Clinical OS that keeps them on one patient state under one line of physician authority.
This whitepaper follows how per-job engines converge on one patient's work, and sets out what the physician confirms inside the Golden Clinical Loop. Product status and evidence are marked at their own separate levels.
Three principles
An engine for each job.
One patient state.
Execution the physician confirms.
Patient state stays continuous.
One place shows how far the patient has come, together with the evidence, the authority, the decision, the owner, and whether it closed.
The physician confirms the next action.
Proposal, confirmation, execution, and verification are kept apart. Diagnosis, treatment, corrections, and exceptions stay with the physician.
Clinical OS
Scattered tasks, joined
into one patient's work.
Booking, the EMR, and the CRM each keep their own records. Clinical OS sits alongside them and connects the patient's identity, evidence, authority, decisions, owner, and completion state.
- 01
Patient contact
Conversation, booking, and preparation details enter as the starting point of patient state.
- 02
One patient state
Evidence and unfinished work stay attached to the same patient even as the product changes.
- 03
An engine per job
The engine that owns a job proposes what to review, inside a set scope.
- 04
Physician confirmation
Clinical confirmation and role permissions are the precondition for the next task.
- 05
Execution and result
Approved tools act. Responses, failures, and the evidence of closure are kept.
- 06
Systems of record
Booking, the EMR, the CRM, devices, and messaging remain the reference record in their own domain.
Golden Clinical Loop
An answer is not the end.
We follow it to done.
The AI proposes and the physician confirms. After execution, evidence that the work closed remains. One turn covers all of it.
- 01
Observe
Read the current state of the patient and the work.
- 02
Structure
Lay out what has to be reviewed and what is still blank.
- 03
Propose
Suggest the next task inside the registered scope.
- 04
Confirm
The clinical team checks the evidence and the authority.
- 05
Execute
Only approved tools and roles act.
- 06
Verify
Confirm the result from what the systems of record return.
- 07
Record
What was accepted, corrected, or rejected is kept and feeds the next check.
- 08
Follow through
Owner, due date, and whatever is still open carry forward.
Products at different stages
do not get described at one level.
The status labels are from the evidence appendix, as of August 18, 2026. The current public boundary is shown with the as-of date from each product's evidence row. Neither label is a regulatory status or a clinical result.
Dockie-talkie
Evidence appendix labelbeta preparation
Not open yet; the beta opening is being prepared
Preparing a beta opening on 2026.09.01
Pre-launch validation
Published capability scope
2026-08-11
Beta opening prepared for 2026.09.01
Clinical Copilot
Evidence appendix labelinternal clinical use
In daily development-and-use loops at our own outpatient clinics
A working screen that moves only on physician confirmation
Pre-launch validation
Published capability scope
2026-08-11
v1.1.2 as of 2026.08.08
Clinical OS
Evidence appendix labelvalidation
A record-and-operations layer in validation
It does not replace an institution's existing chart
Pre-launch validation
Published capability scope
2026-08-11
Scope of the maturity labels as of 2026.08.08
Dermatoscan AI
Evidence appendix labelreference workflow
A physician-only reference workflow
A physician-only clinical reference tool
Pre-launch validation
Published capability scope
2026-08-11
Scope of the reference workflow as of 2026.08.08
WoundScan AI
Evidence appendix labelpartner co-development
Being built together with a partner
P0 scaffold · an early skeleton and its validation procedure
Pre-launch validation
Published capability scope
2026-08-11
Scope of partner co-development and the validation procedure
Golden Clinical Loop
Evidence appendix labelsynthetic case
Synthetic-case validation stage
Execution validated against fixed synthetic cases
Pre-launch validation
Published capability scope
2026-08-11
Scope of the fixed synthetic validation case
Public evidence
Confirmed facts and what we
do not yet say, kept side by side.
Only dated public evidence is summarized here. Code and tests existing is not the same thing as clinical validity or results in the field.
Building and measuring inside our own practice
We build, test, and measure inside the aesthetic and dermatology practice where our founder still sees patients every week.
This is not a count of outside institutions that adopted anything. It is the access we have to build and test inside our own practice.
About 2,000 automated tests
We run about 2,000 automated tests, including regressions on the safety rules.
A test count shows the regression coverage of code and rules. It shows neither clinical validity nor results in the field.
Clinical Copilot v1.1.2
Clinical Copilot v1.1.2 is prepared to the same level as the state published on its product page.
It is a working screen that moves only when a physician confirms. It carries no regulatory status and no clinical results.
Whitepaper v2.0 published
We published Whitepaper v2.0, separating the evergreen paper from a dated evidence appendix.
We do not flatten products that are at different stages into one level. Facts that change with the date are written in the evidence appendix, not in the paper.
Edition history
Only editions with evidence attached are recorded.
Whitepaper v2.0
The split between the evergreen paper and the dated evidence appendix. Reading every product as being at the same stage is not part of it.
Until earlier editions are attached to the public evidence log, we do not put a version or a date on them.
Whitepaper v2.0 · 2026.08.19
The full whitepaper is available as a file.
This page is the summary. The full text is below. Product status and anything else that carries a date lives in the evidence appendix, which is current as of August 18, 2026.
Evidence boundary
We use the present tense onlyfor what the evidence covers.
Per-product validation status, and the limits of what we say publicly, continue in the clinical safety document.
Read the clinical safety document