Made of little things.

# AI Doc 3D — proposed research prototype

Implementation follow-up: [current roadmap and requested future work](roadmap.md)
tracks the 25 October 2026 decisions. The discussion below is the original brief;
see the README and anatomy-layer notes for shipped prototype capabilities.

Status: discussion draft, 24 October 2026. No application implementation or clinical validation is implied. Confirmed audience: adults describing their own symptoms. Confirmed stage: private research prototype, with a possible EU launch later. All other choices below are recommendations for discussion.

## Purpose and clinical scope

Help an adult describe a health concern accurately using a body map, a symptom history, relevant background and optional supporting documents. Produce a patient-reviewed summary and, in a separately evaluated AI workflow, preliminary possibilities and an appropriate care destination/timeframe.

The useful clinical sequence is urgency → history → clarification → synthesis → next care step. The 3D representation improves communication; its appearance, pose and anatomical precision are not measurements of the patient's actual anatomy or a physical examination.

Use **concern** in the interface. A concern may be pain, itching/rash, swelling, bleeding, numbness, weakness, a lump, another local change, or an unlocalized symptom. Avoid asking patients to identify diagnoses or responsible organs. Preserve their own wording.

The prototype should collect whole-body and general symptoms. Initially evaluate the richer body-map and pose interaction with musculoskeletal and skin examples; do not claim validated general diagnostic coverage. Use synthetic cases first. Real participant testing needs clinical oversight, a privacy plan and appropriate research review.

Potential EU release needs an intended-purpose and medical-device assessment before release planning. Calling a diagnostic function “preliminary” does not itself settle its status. The current MDCG guidance evaluates software by intended purpose, including diagnostic decision support. Health-data processing also requires an appropriate legal basis and safeguards; BYOK does not resolve that responsibility. See [MDCG software guidance, June 2025](https://health.ec.europa.eu/latest-updates/update-mdcg-2019-11-rev1-qualification-and-classification-software-regulation-eu-2017745-and-2025-06-17_en) and [European Commission data-processing guidance](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/legal-grounds-processing-data_en).

## Proposed user journey

1. Show the body with a short “What is bothering you?” entry, age and optional body measurements. Make a quick urgency check available immediately, before long forms or AI setup.
2. Add a concern by painting, selecting a named body region, or choosing “not in one place.” Distinguish rotate, mark and pose modes. A completed area creates one concern card; another stroke may extend the active concern instead of creating another form.
3. Ask a short common history, then targeted questions appropriate to the concern. Allow “unknown,” “not sure” and “prefer not to say.” Keep unanswered, absent and declined answers distinct.
4. Add a pose or activity example to an existing concern, or create another concern. Show a thumbnail and editable description for each observation.
5. Add relevant background and optional files. Review extracted text before it becomes part of the history.
6. Present the complete case summary and exact provider-bound content for correction and consent. Show the selected vendor, model, bridge and expected cost information.
7. Run clarification/analysis. Show urgency first, a concise summary, preliminary possibilities with uncertainty, and an appropriate next care step. Offer a fuller clinician-oriented summary.

Urgent findings must not wait for upload, payment, a key or model availability. Examples requiring a clinically reviewed pathway include severe breathing difficulty, stroke-like symptoms and uncontrolled bleeding. This is not a complete triage algorithm. Use localized care instructions and review the pathways with a clinician; a negative checklist must never be presented as proof of safety. [NHS emergency examples](https://www.londonambulance.nhs.uk/our-services/emergency-care/calling-999/).

## Intake content

The following is a proposed question inventory, not a validated medical questionnaire. Use progressive disclosure rather than placing every item on the landing screen. Medication, allergy, medical/surgical history, family history and substance-use questions are supported by [MedlinePlus preparation guidance](https://www.medlineplus.gov/ency/patientinstructions/000860.htm).

| Group | Proposed fields and behavior |
| --- | --- |
| Person and context | Age in years rather than date of birth; language; country for care routing; principal concern; what the person hopes to learn and what worries them. |
| Relevant physiology | Ask sex assigned at birth and relevant anatomy, hormonal treatment, pregnancy possibility/current pregnancy or recent pregnancy when clinically relevant. Explain why. Avatar appearance is independently adjustable and never used to infer these facts. |
| Measurements | Optional height and weight, unit selector, date and whether estimated/measured. Ask about recent unintentional weight change when relevant. Do not require exact measurements to describe a symptom. |
| Health background | Diagnosed conditions, surgeries, significant injuries, prior episodes, relevant family history. Ask targeted follow-ups for factors such as immune suppression, diabetes, cancer, clotting history or anticoagulation. |
| Medicines and allergies | Prescription/OTC medicines, supplements, dose/frequency if known, recent changes, treatments tried and effects; allergies plus the reaction, not just the substance. |
| Habits and exposures | Current/former/never tobacco use, type/amount/duration and quit timing if relevant; vaping; alcohol and other substances; occupation, repetitive loads, exercise, sleep, travel, sick contacts and new exposures as indicated. |
| Known observations | Temperature, pulse, blood pressure or other already available readings with units, timestamp and source. Do not make buying devices or taking unreliable measurements a prerequisite. |

For every concern, collect:

- **Onset:** when it first started; sudden/gradual; injury, illness, new medicine or another trigger; first episode versus recurrence. Preserve approximate dates and relative wording.
- **Course:** constant/intermittent; episode length/frequency; improving/stable/worsening; new changes to a longstanding concern.
- **Location:** patient-left/right/both/midline, selected areas, spread or radiation, perceived superficial/deep/uncertain. Several locations can belong to the same concern.
- **Character and severity:** descriptions appropriate to symptom type; optional numeric or verbal pain scale; severity now and at worst. Do not apply a pain score to every symptom.
- **Aggravating/relieving factors:** activity, position, exertion, rest and treatments tried. Record that a pose triggers symptoms only when the patient says so.
- **Impact:** walking, using a limb, sleep, work and ordinary tasks; what changed from usual ability.
- **Associated symptoms:** targeted positives and explicit negatives, with an option to add anything else.

This structure follows the dimensions in the [NIH pain overview](https://health.nih.gov/health-topics-a-z/pain). Keep duration as data; do not make patients decide whether their pain is medically “chronic.” NICE describes chronic pain as persisting or recurring for more than three months, but duration does not establish its cause. [NICE NG193](https://www.nice.org.uk/guidance/ng193/chapter/recommendations).

Suggested branches, for clinical review:

| Concern | Additional questions |
| --- | --- |
| Musculoskeletal | Mechanism of injury, activity/load, stiffness, swelling, locking/giving way, numbness/weakness, ability to use or bear weight, prior injury/surgery. Never instruct painful self-tests or force a movement. |
| Rash/itching/skin change | Start/spread, itch/pain/warmth, blisters or discharge, fever or systemic symptoms, new products/medicines/exposures, close contacts; overview and close-up photos when desired. |
| Bleeding | Site/source, whether ongoing, approximate amount with plain-language choices, trauma, blood thinners, associated faintness or weakness; urgent routing when indicated. |
| Fatigue/nausea/general symptoms | Timing, functional impact, sleep, appetite/intake, vomiting, associated symptoms, recent illness/medicines and relevant pregnancy questions. No artificial body location required. |

## Body model and asset decision

Recommended first candidate: a MakeHuman/MPFB-derived skin model, prepared in Blender and exported as a web-ready rigged asset with a small, deliberately chosen set of morph targets. This is a research shortlist, not a tested asset selection.

| Candidate | Evidence | Proposed use and unresolved work |
| --- | --- | --- |
| MakeHuman / MPFB | Core assets are CC0; the official documentation covers body-shape controls, rigs and IK helpers. | Best initial skin candidate. Inspect anatomy, hands/feet, UVs, deformation and morph export. It is a character system, not a validated anatomical patient model. |
| BodyParts3D | The official archive provides named organ meshes and relationships. Its current license page, updated February 2025, says CC BY 4.0. | Candidate for later internal structures. The downloads are large; do not assume a shared animation rig, morph compatibility or ready web assets. |
| Z-Anatomy | A navigable anatomical atlas with downloadable models. Its repository states CC BY-SA 4.0 and also credits components under noncommercial licenses. | Useful anatomy reference/candidate library. Per-component provenance and redistribution review are essential; rigging and common deformation remain unverified. |

Sources: [MPFB licensing](https://www.makehumancommunity.org/about/license.html), [MPFB getting started](https://www.makehumancommunity.org/mpfb/docs/getting_started.html), [MPFB export considerations](https://ww.makehumancommunity.org/mpfb/docs/exporting/index.html), [BodyParts3D downloads](https://dbarchive.biosciencedbc.jp/en/bodyparts3d/download.html), [BodyParts3D current license](https://dbarchive.biosciencedbc.jp/en/bodyparts3d/lic.html), [Z-Anatomy repository and credits](https://github.com/Z-Anatomy/Models-of-human-anatomy/blob/master/Readme.md).

Do not assume a complete, legally redistributable, multilayer, morphable and well-rigged model has been found. Skinning an animation mesh and modeling anatomically plausible muscle/organ deformation are separate tasks. A bone rig is not a rendered anatomical skeleton. Avoid combining atlas organs and a character body as though their alignment were automatically accurate.

Height can set an approximate scale; weight can influence a bounded silhouette morph. Height/weight do not determine body composition or fat distribution. Label the result illustrative, permit manual adjustment, and keep clinical measurements separate from display parameters. Offer appearance/skin tone choices without deriving ethnicity, diagnoses or physiology from them. Support manual/text descriptions when an avatar does not represent a person's body, disability, amputation or prosthesis.

### Asset spike acceptance criteria

- Document the exact source/version and licenses for every mesh, texture, pose and derivative.
- Export a useful body with distinct left/right UV space, stable canonical topology and usable close views of joints, hands, feet and head.
- Show height/silhouette changes without corrupting skin weights or moving anatomical labels to the wrong region. Morph-driven joint placement may need custom work.
- Demonstrate standing, seated, supine, prone and side-lying poses; constrained arm/leg manipulation; a baked walking/jogging clip with pause/scrub.
- Prove annotation persistence through body morphs, pose changes, save/reload and model rotation.
- Fit the host asset budgets and measure performance on a representative phone. Document build bytes, asset bytes, memory and frame time; aim for smooth touch interaction, with 30 FPS as an initial engineering target rather than a proven result.
- Test the actual opaque iframe, including texture decoding and asset loading. A Blender or standalone browser demo is insufficient.

## Fine-grained surface annotation

Keep **continuous geometry** and **clinical region names** separate. A brush can capture an arbitrary small patch without pretending every millimeter has a medically meaningful label.

Use a versioned canonical mesh/UV atlas and a clinician-reviewed hierarchy of regions and landmarks. Resolve left/right in the patient's coordinate system. Give extra attention to fingers/toes, joint surfaces, palm/back of hand, sole/top of foot, head/face and boundaries between adjacent regions. Sensitive areas must remain describable through text even if the default avatar is modest.

Proposed implementation:

1. Raycast against the currently deformed visible surface.
2. Store a canonical surface anchor: mesh/version, triangle identifier and barycentric position, with UV/chart identity for painting. Store brush strokes/patch extent, not just their centroid.
3. Reconstruct the paint/anchor after morphing and skinning. Handle UV seams and avoid mirrored UVs for laterality. Keep region lookup independent of GPU color blending.
4. Restrict the brush to the intended visible surface so it cannot leak through a knee to the other leg or across nearby folded body parts. Use surface connectivity and occlusion, not an unrestricted world-space sphere.
5. Intersect a patch with the anatomical region map. Preserve multi-region and uncertain-boundary selections. Permit explicit correction without erasing the original geometric evidence.
6. Generate plain-language text deterministically; ask the user to confirm it. The LLM receives this structured location and optional screenshots, rather than guessing the location from a picture.

Example: “Outer side of the left knee, extending a little below the joint; reported as deep pain.” Do not translate this to a damaged ligament or meniscus. Surface footprint is not a calibrated wound size or actual body surface measurement.

Support point/brush/erase/undo, multiple patches per concern, overlapping concerns, bilateral marking and a separate radiation path. Marking, orbiting and posing need explicit modes and clear touch feedback. A searchable region list and front/back 2D map should produce the same concern data.

## Pose and activity semantics

Store a pose snapshot per observation, not a single mutable global pose. Several observations can describe the same concern in different positions or times.

Begin with presets and constrained handles for hands, feet, elbows and knees; provide simple joint sliders as an accessible alternative. Use joint limits, stable elbow/knee bend directions and reset/undo. Full-body IK, collision-free seated contact and spinal movement require separate validation.

Blender's authoring controls do not automatically become browser IK. Build and test runtime constraints. Three.js supplies [SkinnedMesh](https://threejs.org/docs/pages/SkinnedMesh.html), [GLTFLoader byte parsing](https://threejs.org/docs/pages/GLTFLoader.html) and a [CCDIKSolver](https://threejs.org/docs/pages/CCDIKSolver.html); these are building blocks, not medical biomechanics.

Walking/jogging are activities represented by an animation and selected time/phase. Record “pain while jogging” only from the user's answer. “Left knee bent in the illustrated seated pose” can be generated from the pose. Do not report the illustrated angle as measured patient range of motion or infer force, injury or an observed gait.

## Data model and report provenance

Suggested app-local entities (not new NAP domains):

- `Case`: adult eligibility, language, timestamps, profile, background, concerns, consent and schema version.
- `Concern`: patient wording, type, onset/course, severity/impact, associated answers, links to observations and attachments.
- `Observation`: symptom state at a reported time, surface patches, perceived depth, activity/context, pose snapshot and confirmed location description.
- `SurfacePatch`: canonical model/atlas version, anchors/strokes, region IDs, laterality and user overrides.
- `Attachment`: local/session reference, type, date, concern links, source, processing status, extraction/review status and consent. No public medical-file URL by default.
- `AnalysisRun`: immutable input revision, source references, provider/model/version where available, prompt/rule version, output, limitations, usage and errors.

Every relevant fact must retain whether it was patient-entered, extracted from a document, geometrically derived or AI-inferred. Preserve exact user language alongside normalized fields. Distinguish confirmed negative from not asked/unknown/declined. Review conflicts rather than silently overwriting them. Editing a case makes its old AI report visibly outdated.

## AI workflow and provider connections

Use an explicit pipeline rather than one long prompt:

1. Clinically reviewed urgency logic and question paths; no LLM needed for already identified urgent triggers.
2. Local normalization and missing-information checks, with user review of attachment extraction and anatomical descriptions.
3. A bounded clarification step for questions that could change urgency or interpretation. Allow skipping and retain uncertainty.
4. A structured synthesis from the approved case bundle, with source IDs for important factual statements.
5. Output schema validation, factual/source checks and consistency checks against urgency rules. These checks reduce errors but do not establish clinical safety.

The report should contain: care urgency/timeframe; concise case summary; plausible explanations with supporting/missing/contradictory information; what requires examination or tests; suitable first contact (including primary care or urgent/emergency services); optional specialist and rationale; and symptom-specific safety-net instructions. The clinician-facing appendix should distinguish history from AI hypotheses. Avoid invented probabilities, fabricated examinations, definitive rule-outs and automatic prescriptions.

Evaluate vendors on held-out clinician-authored/adjudicated cases, including urgent cases, uncertainty, contradictory reports, incomplete histories, different skin tones/ages/body types, image quality and misleading instructions inside uploaded documents. Score dangerous under-triage, unsupported claims, omissions, referral appropriateness, uncertainty, readability, privacy, cost and latency. Do not select a medical default using coding/chat leaderboard performance. [WHO's LMM guidance](https://www.who.int/news/item/18-01-2024-who-releases-ai-ethics-and-governance-guidance-for-large-multi-modal-models) supports task-specific evaluation and early clinical participation.

Saved connections should separate provider metadata from secrets: display name, vendor/endpoint, model, modality support, request limits, supported output formats, retention/region information and cost controls. Test connections with synthetic content. No automatic vendor failover or hidden multi-vendor fanout of a health case.

Current official documentation establishes that multimodal candidates exist, not that they are suitable for this use: [Kimi API overview](https://www.kimi.ai/help/kimi-api/api-overview), [DeepSeek vision](https://api-docs.deepseek.com/guides/vision/), [OpenAI vision](https://developers.openai.com/api/docs/guides/images-vision). OpenAI's vision documentation expressly warns against specialized medical-image interpretation and use for medical advice. Review each vendor's permitted uses and processing terms before enabling this workflow. Provider/model capabilities must be checked at implementation and re-evaluated on model changes.

## Files and privacy

Start with optional photos and text/PDF reports. Capture document date, provenance and the concern it relates to. Preserve lab units/reference ranges and document page references. Treat OCR as uncertain until reviewed; preserve existing diagnoses as “reported in document,” not established current findings.

Do not promise radiology interpretation from a general vision model. Prefer the radiologist's report in the first prototype. Defer DICOM studies, CT/MRI volumes and diagnostic X-ray reading; these introduce specialized display, metadata, size and validation requirements. Poor-quality photos must lead to a limitation, not confident reassurance.

Use local/session imports first and disclose exactly what is sent. Offer cropping/redaction and remove unnecessary metadata from derived transmission copies. Never claim cropping, EXIF removal or removing a name guarantees anonymization; content itself may identify a person. Treat documents as data, never executable instructions for the analysis workflow.

No health records or keys in public Nostr events, ordinary Blossom uploads, source assets, debug logs or analytics. Session-only should be the initial health-data default. Durable drafts require an explicit privacy design for storage at rest, host/operator access, retention, deletion and account switching. A scoped storage API is not evidence of encryption.

## Napplet capability contract and feasibility gaps

The workspace remains the existing soyLI/Vite/TypeScript project. Add Three.js only when implementation begins. Keep application state, body/region logic, intake rules, evidence assembly and report rendering independently testable. Put provider networking in a separate service, not shell implementation copied into this repository.

| Capability | Proposed boundary and fallback |
| --- | --- |
| Scene, forms and annotation | App-local bundled code/assets; text/2D fallback if WebGL is unavailable. |
| Larger public model assets | `resource` through the soyLI asset helpers; bundled minimal fallback where practical. Parse received bytes; do not use network-loading helpers or remote decoder scripts. |
| Non-sensitive preferences | Optional `storage`; memory fallback. Draft health persistence is a separate, explicit design decision. |
| Provider metadata and session secret entry | Optional `config`; ordinary configuration can persist, but the documented `x-napplet-secret` fields are masked and session-only. This is not a persistent key vault or a guarantee the app cannot read the key. |
| AI inference | Existing `cvm` to a separately operated/user-controlled service, subject to host approval and a verified private transport/data path. No direct vendor HTTP requests in the napplet. |
| Attachments and report export | Documented host `fs` pick/read/write/export flow, pending the SDK compatibility gap below. Text intake and selectable report remain useful without it. |
| External care/provider information | Optional `link`, with ordinary in-app instructions when absent. |
| Theme and shortcuts | Optional; app-owned palette and ordinary controls remain functional. |

**Network gap:** the current sandbox forbids direct vendor networking; read-only resource loading is not a POST/authorization proxy. A separate CVM service could own vendor calls, but no such service is implemented or validated here. The installed dynamic soy backend profile itself has no network access and cannot serve as that proxy. Verify end-to-end encryption, recipient identity, relay metadata, payload limits, cancellation, error handling and binary transfer with synthetic fixtures before health-data use. If a valid path is unavailable, the AI feature remains explicitly blocked; do not invent a NAP or silently weaken the sandbox.

**Credential gap:** recommend a user-controlled bridge with credentials provisioned in its own secure store; the napplet uses a scoped connection reference. Alternatively investigate the documented session-only secret fields for a private prototype, with explicit disclosure that the chosen bridge receives the secret. Durable multi-provider key storage is not established by the current host documentation. Never put keys in URLs or ordinary app storage.

**Original file SDK gap (resolved 26 October 2026 with SDK 0.30.0):** the host guide documents `fs`, but the installed `@napplet/sdk` 0.24.4 export declarations inspected for this plan do not expose `fs`; the installed `@napplet/nap` package exports also did not reveal an fs entry. Resolve this upstream/package mismatch and test the actual supported API before committing to attachments. Do not add guessed shim methods.

Relevant current documented limits: 512 KB scoped storage; 10 MiB total session files; 256 KiB file reads/writes; 10 MiB per managed asset, 32 MiB managed assets total; 25 MiB built HTML. These are host/package limits, not proof of private media transport. Keep binaries out of small JSON drafts.

Proposed hard requirements: none for the standalone intake/body-map stage if a bundled fallback is provided. For a later release whose promised core job includes AI assessment, decide whether `cvm` is required; never advertise completed analysis when it is unavailable. No identity, outbox, relay or social publication is needed for the core task. No relay escape hatch or cross-napplet integration is proposed.

Local evidence: [host capabilities and settings](napplet-space.md), [file/session contracts](napplet-actions.md), [dynamic backend limits](napplet-dynamic-backends.md), [boundaries](boundaries.md), installed SDK README and type exports. Runtime behavior has not been tested for this product.

## Visual direction and responsive behavior

Considered directions: a detailed medical atlas and a calm consultation workspace. Recommend the consultation workspace: neutral matte body on a pale slate surface, dark readable text, restrained teal for interaction and numbered/patterned concern marks. Use severity/emergency colors only for their defined meaning; never communicate concern identity through color alone. Keep body detail sufficient for precise selection without presenting a simulated scan.

The body and active concern card share the main surface on desktop. Keep the history in a progressive sequence rather than a wall of demographic fields. Use readable default text, generous spacing, visible focus and touch targets around 44 px. Motion is deliberate, with pause and reduced-motion alternatives. Generated text remains selectable.

- Tiny 200×160: meaningful case status and guidance to enlarge; do not pretend precision painting is usable here.
- Phone 320×560: one task at a time, tabs for Body / Concerns / Review, focused concern editor and explicit mode controls.
- Regular 900×600 and wider: body beside the current form, with a persistent but compact concern list.
- Short landscape: collapse secondary controls; preserve body navigation and active input.
- Test both host themes and missing theme support; use app-owned colors throughout.

Representative proof state: two separate concerns on the body, one seated-pose observation, a clear confirmed location sentence and a partially completed symptom history. Use only synthetic content in captures.

## Delivery sequence and exit criteria

| Phase | Deliverable | Exit criterion |
| --- | --- | --- |
| 0 — Feasibility | Skin asset spike, annotation anchor experiment, synthetic CVM/credential experiment and file SDK investigation. | Exact asset/license decision; working morph/pose/paint demonstration; documented supported AI/file path or explicit blockers. |
| 1 — Useful intake | Adult profile, whole-body concerns, general symptoms, fine-grained skin map, presets, draft summary and accessible text alternative. | A person can describe multiple concerns and correct the generated location/history without AI. |
| 2 — Movement context | Constrained IK, per-observation poses, walking/jogging pause/scrub and context questions. | Same concern survives all pose/morph changes; pose language does not claim measured motion or causation. |
| 3 — Evidence and BYOK | Private file imports, reviewed extraction, provider connections and a synthetic-to-approved-data inference path. | Verified credential lifecycle, exact transmission preview, bounded payloads, rejection/cancellation and no public health-data uploads. |
| 4 — Evaluated research report | Clarification, structured preliminary assessment, urgency/care routing and source-traceable report. | Clinician-agreed evaluation criteria met on held-out cases; failures/limitations documented. No claim of clinical validation from engineering checks. |
| 5 — Anatomy expansion | Selected skeleton/muscle layers, then organs if justified. | Licensing, common coordinate alignment and deformation established; patient-perceived depth remains distinct from diagnosed structure. |

Engineering verification for implemented phases: `pnpm type-check`, `pnpm build`, `pnpm test:guidance`, `pnpm test:conformance`, plus an owned `soyli dev` preview stopped after testing. Read passed/failed/skipped conformance evidence separately. Test real SDK operations and missing optional domains in the target host.

Focused product tests: patient-left/right consistency; UV seams and overlapping limbs; paint after extreme supported morph/pose changes; cross-region marks; round-trip serialization; unit/date handling; unknown vs negative; attachment extraction errors; provider cancellation/retries; stale reports; urgent paths without AI; hostile document instructions; touch/keyboard and fallback input. A small clinically reviewed safety corpus cannot establish comprehensive sensitivity; agree an evaluation design and release gates with the clinical lead.

## Decisions still open

- Clinical collaborator: a GP/internal-medicine lead for broad intake and urgency, plus musculoskeletal and dermatology review for the first rich workflows.
- 3D production effort: whether to commission an artist/anatomist if the asset spike exposes deformation or region-map gaps.
- Bridge deployment and credential ownership: user-operated service first, or a separately reviewed hosted research service.
- Which preliminary-assessment tasks and provider terms are acceptable for the first evaluation cohort.
- Supported languages, research protocol and real-participant data policy.

Recommended immediate next step: resolve the skin/paint/pose and private AI-transport feasibility questions before building the full questionnaire or integrating multiple vendors.

## Planning checkpoint verification

Only this planning document changed. The existing scaffold passed type-check, build and all six guidance tests. The conformance run reported five passed, zero failed and five skipped: manifest evidence, wire envelopes and lifecycle coverage were not supplied/measured. Its local server required execution outside the filesystem sandbox after an initial listen-permission failure. No product UI, model asset, provider integration, clinical behavior or hosted manual preview was implemented or tested.