• GIF

• GIF

Asclepius

Your words. Your Care Card. Your choice.

Repository guide · Walkthrough · Architecture · Evidence limits

The short version

Asclepius turns a voice or text check-in into an editable, user-verified Care Card. It compares the current check-in with only the previous approved card, helps organize what the person wants to discuss, and leaves correction, approval, transcript choice, and PDF export in their hands.

This is a tool for preparing a conversation, not making a medical assessment. The output is a handoff the person approves not a diagnosis, risk prediction, or automated referral.

Inspiration

When someone prepares to ask for support, the difficult part can be putting the story into words: what changed, what stayed the same, and what matters today. Retelling everything from the beginning can lose context. Giving an AI-written summary authority over that story creates a different problem.

We built Asclepius around a smaller, more accountable role for software: help prepare the words, show the draft, and let the person change it before anything is carried forward.

What we built

SHARE Consent first. Voice or text.

COMPARE One previous approved card.

CORRECT Four sections. Your wording.

APPROVE Choose the appendix. Export the PDF.

Capability	What it does	Why it matters
Consent and channel choice	Offers history consent and voice/text entry.	The person chooses how to begin; text remains a complete path.
Meaningful Next Step	Optional short supportive-planning questions and an editable note.	Provides another starting point without forcing a plan or a clinical interpretation.
Visible drafting	Shows progress and identifies live drafting or deterministic fallback.	A fallback is not disguised as a successful model response.
One-card continuity	Compares the current check-in with one previous approved Care Card.	Context stays bounded and tied to a prior user decision.
Editable Care Card	Organizes What changed, What stayed the same, What to discuss, and Remove or correct.	The person can repair omissions or unwanted wording.
Separate approval	Distinguishes a generated draft, user edit, and approved card.	Editing does not silently become permission to export.
PDF choice	Includes the transcript appendix by default, with explicit removal and preview.	The person can see what the handoff will carry.
Dedicated support action	Opens a separate user-selected support route.	No model decides urgency or triggers that route.

Product walkthrough

These recordings show the real app at 390×844 with synthetic data. The drafting request is deliberately blocked so the labeled fallback is exercised. They demonstrate the product flow, not live DeepSeek or Android DAM execution.

1. Put it into words	2. Make the handoff yours
Begin with consent, choose text, then inspect the draft and previous approved-card context.	Correct a sentence, approve the card, choose the transcript state, and explicitly export.

Prefer no animation? Open the continuity screen, approved card, or PDF preview. Capture provenance records the source and timing.

The proof to look for

The important moment is not when the draft appears. It is what happens next:

1. The person opens Edit and changes What to discuss.
2. User-edited draft appears; the card is not yet approved.
3. Verify Care Card & continue creates the separate approval state.
4. The person removes the transcript appendix and checks the new preview.
5. Approve and export produces the local PDF.

That sequence makes the person's authority visible instead of leaving it in a disclaimer.

How we built it

Editable Draw.io source · Static architecture

Component	Role
React + TypeScript + Vite	The mobile-width check-in and review interface.
Capacitor	Native platform integration and the DAM bridge.
Express + Zod + shared contracts	Text-only orchestration and strict request/response validation.
DeepSeek through OpenRouter	Optional server-assisted text drafting with server-only credentials.
Deterministic fallback	Keeps the editable check-in flow usable when the provider is missing, unavailable, or invalid.
ONNX Runtime / DAM bridge	Optional bounded review-route branch; native runtime evidence is a separate verification track.
Approved-card adapters	Temporary memory for the explicit website demo; demo localStorage for the ordinary browser/WebView path.
pdf-lib	Local Care Card PDF construction behind approval and transcript-choice gates.

The public drafting request carries text, an optional allowed route, and at most one previous approved Care Card. It does not carry recorded audio or DAM task-head values. Provider output is untrusted until validation passes.

The optional native DAM branch and server-assisted drafting are separate. DAM can affect only REVIEW_REQUIRED versus SELF_REPORT_ONLY. Technical head outputs, when available in the technical-details panel, are not personal questionnaire scores and are excluded from drafting. The intended safety contract also excludes them from export, but the current implementation has the discrepancy described below.

The native bridge and Android packaging path are implemented. Physical-device execution, model parity, performance, and containment evidence remain open. The explicit localhost DAM development mode is local-machine inference, not on-device evidence.

The human decision boundary

Editable Draw.io source · Static decision loop

The animated dashes illustrate allowed paths, not measured live traffic. Only the person can approve the Care Card, approve export, or choose urgent support. A Meaningful Next Step note also needs its own approval before it can be carried into the editable Care Card.

Challenges we addressed

Challenge	Implementation response
A plausible draft can still be wrong.	Keep four sections editable and require a separate user approval.
History can become an unbounded profile.	Read only the previous approved card, with history consent.
A provider can fail or return invalid content.	Validate the response and visibly use a deterministic fallback.
Model outputs can be mistaken for clinical authority.	Restrict DAM to two route states and isolate technical evidence from downstream decisions.
A preview can be confused with consent.	Separate editing, Care Card approval, transcript choice, and final export approval.
A browser demo can overstate native capability.	Label demo, fallback, local-machine inference, and unresolved physical-device evidence separately.

What we are proud of

The implementation includes a text-first path through editing and PDF export, one-card continuity, separate approval states, a bounded provider interface, and a dedicated model-independent support action. The value is in how these parts work together: the draft is useful, but it does not become the authority.

The repository also keeps product evidence separate from model and deployment claims. Browser replay, provider smoke, and Android build records answer different questions; none is presented as proof of clinical validity.

What we learned

A disclaimer cannot enforce a boundary. Approval has to be represented in state, validated at export, and visible in the interface.

Fallback behavior is part of the product. When a model is unavailable, the person still needs to finish with their own words.

Continuity does not require collecting everything. One previous approved card is enough to demonstrate a bounded comparison without treating an evolving model interpretation as the person's record.

Honest limits

• Export-contract discrepancy: the current PDF exporter can append SignalBridge evidence, including task-head values when supplied, despite the safety contract's export exclusion. This remains unresolved; the recorded fallback has no returned DAM values. Source audit.
• Public inputs, screenshots, and recordings are synthetic.
• The website demo resets its in-memory history on refresh. Ordinary browser history uses localStorage; neither mode proves encrypted or secure storage.
• Provider retention terms must be verified before sensitive, non-synthetic text is submitted.
• Native build evidence is not physical-device model execution, parity, or audio-containment evidence.
• Browser accessibility smoke checks are not full accessibility conformance.
• Removing the transcript appendix does not erase approved Care Card content or remove the separate SignalBridge evidence appendix. Export creates a copy outside the app's control.
• No claim is made about clinical validity, treatment, inferred urgency, automatic referral, or production readiness.

See the claim matrix, submission evidence register, and safety contract for the release boundaries.

What is next

The next work is verification, not broader model authority: physical-device runs and parity checks, instrumented audio containment, secure native storage and deletion, provider-retention review, and fuller assistive-technology testing. The review and approval boundaries stay in place through that work.

Try it

From the repository root:

npm ci
npm run dev:local

Open http://localhost:5173/?demo=live and use synthetic text. Provider configuration is optional for the fallback walkthrough. The dev:local command also enables the development-only local DAM endpoint; that endpoint is not intended for production.

• README and complete local demo path
• Configuration and native builds
• Repository evidence
• Demo script

Built with

React 19 · TypeScript · Vite · Capacitor 8 · Express · Zod · DeepSeek through OpenRouter · ONNX Runtime · pdf-lib · synthetic fixtures · Draw.io

Source and license

Application code is licensed under Apache-2.0. Third-party notices and model attribution remain separate: NOTICE and model attribution. Media sources and capture mode are recorded with the documentation assets.

Built With

• javascript
• python
• typescript