NeuroAtlas

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Scope covered across the 3 parts: NeuroAtlas (platform), DICOM imaging module, NeuroPharmacology, Computational Neuroradiology reasoning engine, Lens 4D stage, Twin Brain compiler. Part 1 = NeuroAtlas + DICOM. Part 2 = NeuroPharmacology + Computational Neuroradiology. Part 3 = Lens + Twin Brain + evidence appendix + remaining scope.

NeuroAtlas (platform)

Biography

The problem. Clinical imaging viewers are closed, diagnosis-oriented and rarely explain why they show what they show. The owner wanted the opposite: an open research environment where a DICOM study could be reconstructed, measured, segmented, labelled against standard brain atlases, and reasoned over — with every number and surface carrying its provenance and uncertainty, and with firm guardrails so nothing reads as a diagnosis.

Origin and motivation. NeuroAtlas grew as the imaging arm of AssistantApp. The documented driver (session records, Jul 2026) is a large owner "add these medical-imaging modules" vision; a survey found most of the wishlist already existed (HU/radiomics, material classes, vessel/NASCET, vascular territory, differential engine, provenance graph, the MISO/MESA/MEGA signal spine, pharmacology reasoning, digital-twin case sessions), so the programme became gap-fill and unify, not a rebuild. Three companion roadmaps record this: DICOM Intake Intelligence, TwinBrain integration, and the Computational Neuroradiology roadmap.

Audience. Imaging researchers, developers and technically-minded clinicians exploring methods; students of neuroanatomy; the studio’s own thesis/research work. Not patients, and not for clinical decisions.

Distinctive ideas.

• Evidence classes everywhere. Derived content is tagged (e.g. .measuredFromDICOM, .derivedFromSegmentation, .dicomSegmentation, .atlasPrior) and that class drives how it is rendered and captioned — so an interpolated isosurface is never captioned as "measured on this scan." A prohibited-wording linter blocks diagnostic phrasing.
• One study → one model. The Twin Brain compiler (Part 3) registers a study's series into a common frame and assembles a single cross-acquisition scenario.
• Atlas-grounded. Official FSL atlas label volumes (Harvard-Oxford cortical/subcortical, JHU labels/tracts, MNI152 templates) are staged locally and queried voxelwise to name regions, with a coarse-centroid fallback when volumes are absent.
• Offline-first. Reconstruction, segmentation caches, atlas lookups and reasoning run on-device; live connectors (PubMed/ClinicalTrials.gov/ChEMBL) only annotate and degrade gracefully offline.
• Host-aware budgets. Residency/vertex/layer ceilings scale with the Mac's RAM tier so large studies don't silently drop structures.

What it does — a user journey.

• Open a DICOM study; NeuroAtlas decodes the series (including JPEG-2000-lossless), builds the volume, and reports a reconstruction verdict (stack geometry, gantry tilt, HU proxies).
• View it as stacked slices with MPR, or as a 3D volume/surface; step two studies side-by-side in a compare grid.
• Run segmentation; masks are cached per series; structures appear as shaded layers.
• Labels are grounded against the atlases; measurements (volume, mean HU, texture, symmetry) are computed with evidence tags.
• Open the Evidence Explorer to drill from a report into the graph, the MPR overlay, and the 3D scene, and into offline literature.
• Optionally compile the whole study into a Twin Brain scenario, or ask a non-personalised "what-if" about drug mechanisms (Part 2).

Features a visitor could see (once captured from synthetic/phantom data): the four-region workstation (nav strip / rail / centre canvas / inspector + job bar); slice+MPR viewing; the 3D/4D Lens stage; the segmentation panel; the Evidence Explorer (report, graph, MPR overlay, 3D link-back); the What-If reasoning panel.

Authored work: the whole NeuroAtlas module tree and its engines. Dependencies: Apple frameworks (SceneKit, Accelerate, SwiftUI, WebKit); FSL atlas data (third-party, see rights note); the studio’s own packages for some numeric/DSP work.

Maturity by feature (from dated session records)

Roadmap (aspiration)

Live SceneKit selection binding + MPR-canvas compositing ("last mile"); prior-scan registration data; live literature connectors; the parked physics-sim/"reality compiler" horizon is explicitly not a build commitment (realistic target: a "Radiology Reasoning Engine").

Known limits

Non-diagnostic by design; several surfaces are self-tested but not human-runtime-verified; depends on staged atlas/segmentation data; external-drive reads have caused SIGBUS, so reads are bounded.

FAQs

• Is it a diagnostic tool? No — research-only, non-diagnostic, enforced by wording/evidence guards.
• Does it need the internet? No; it's offline-first. Live lookups only annotate.
• Whose scans does it show? Real de-identified research DICOM for development; those are not website-safe — site imagery must be synthetic/phantom.
• What are MISO/MESA/MEGA? The internal signal spine (segment-level signals → grouped structures → assembled scenario).

DICOM imaging module

Biography

The problem. Real DICOM is messy: mixed transfer syntaxes, undefined-length sequences, unsigned vs signed pixel representations, rescale intercepts that push true Hounsfield ranges outside a signed-16-bit container. Naive readers silently corrupt data and still produce a confident-looking answer — the exact "absence rendered as presence" failure the project is vigilant about.

Origin and motivation. The module was proven against a reference CTA (Siemens SOMATOM X.ceed carotid angio, 1016 frames, 512×512, JPEG-2000-lossless) and a library of real archives. The live runtime proof (session records) both validated the pipeline and surfaced real defects, which were fixed — the project treats "it ran on real data and told the truth about its limits" as the bar, not "it compiled."

Audience. Imaging researchers and developers; anyone needing an open, inspectable DICOM pipeline. Not clinical users.

Distinctive ideas.

• Honest HU. When source is unsigned-16 with intercept −8192 (true HU −8192…+57343) but storage is [Int16], it measures and reports the clamp (e.g. 1,428 voxels at exactly 32767), tallies both clamp sites, and marks peakHU a lower bound rather than widening storage (a deliberate memory trade-off on a module with IOSurface-exhaustion history).
• Refuse, don't fake. The dense-census tool returns a reason on decode failure instead of "0 objects," and emits refusals as JSON on stdout so callers can't silently swallow diagnostics.
• Correct geometry. LPS→RAS affine writing was corrected; tests assert the rule (derive expected frame from the header's observable shape), never a fixed classification of a momentary file.
• Compressed + uncompressed parity. The parser recurses into nested undefined-length sequences and respects PixelRepresentation, so both encapsulated JPEG-2000 and native OW blobs read correctly.

What it does — a user journey.

• Point at a study folder; the engine decodes and reports a reconstruction verdict (stack parallelism, 0° tilt, contrast proxy in HU, metal-voxel count).
• View slices, scrub with the cine transport, open MPR planes; put two studies in a 2-up/4-up compare grid.
• Hand the volume to segmentation (caches under SegCache/<seriesID>/), the Lens 3D/4D stage, or the measurement/reasoning engines.
• For scripted/headless work, the CLI tools (dicomvol <seriesDir> stats, census, render) produce the same measurements with explicit refusals.

Features a visitor could see (capture from phantom/synthetic data): the single-scan viewer with MPR; the compare grid; a 3D reconstruction; a reconstruction-verdict readout.

Authored work: the DICOM decoder, reconstruction, MPR, viewer, CLI tools. Dependencies: a JPEG-2000 decoder path; Apple frameworks.

Maturity by feature (dated session records)

Note: the MCP shells out to prebuilt binaries in Tools/DICOMTools/bin/; source changes there are inert until recompiled.

Roadmap / limits

Widening storage to Int32 was deliberately declined (memory cost); peak HU therefore remains a declared lower bound on saturating scans. External-drive force-unmount (SIGBUS) is a known hazard; reads are bounded. Live MPR-canvas compositing is "last-mile" pending.

FAQs

• Does it handle compressed DICOM? Yes, including JPEG-2000-lossless, plus awkward uncompressed GE/Siemens.
• Why is peak HU sometimes a "lower bound"? Because the signed-16 container can clamp true HU; it reports this rather than hiding it.
• Can I script it? Yes — the dicomvol/census/render CLIs give the same measurements with explicit refusals.

— End Part 1/3. Part 2 (NeuroPharmacology + Computational Neuroradiology) follows. I wrote no response file; these ccx messages are the deliverable.

(NeuroPharmacology below was verified against current source this session — highest confidence in this report.)

NeuroPharmacology (research module)

Biography

The problem. Consumer "drug interaction checkers" are opaque look-up tables: they say "interaction: moderate" without the mechanism, the evidence, or any honesty about uncertainty — and most apps carry only a few hundred drugs with real reasoning behind them. The owner wanted a transparent, offline, mechanism-first engine that covers the whole drug universe for identity and reasons deeply wherever real data exists, while refusing to pose as a prescriber.

Origin and motivation. The module began as a curated seed of CNS-active drugs with hand-modelled targets, CYP/UGT/MAO metabolism, pharmacodynamic "load" axes and label interactions, each carrying provenance and a clinical-use policy. A recurring owner requirement drove its expansion: "do not use an inferior process… there should be 20,000 meds." That led to two tiers (identity vs deep reasoning) and a proper bulk-data automation rather than hand-curation. In this session the deep-reasoning coverage was extended again (shared-target convergence across thousands of drugs) and the openFDA/DailyMed label layer — the long-standing open roadmap item — was built and populated with real data.

Audience. Researchers, students, and technically-curious users exploring polypharmacy mechanisms; the studio’s own thesis/what-if work. Not patients or prescribers; it gives no personalised advice.

Distinctive ideas.

• Two honest tiers. Identity/search covers 23,599 drugs (RxNorm ingredients/brands/combinations + WHO ATC class). Deep what-if reasoning covers a curated seed (~97 drugs) plus an offline enrichment now spanning 5,974 drugs with real targets/enzymes/loads (up from 999 earlier this session, after shared-target reasoning was wired in). The site should state both numbers plainly — identity ≠ deep reasoning.
• Mechanism-first, categorised. The CombinationReasoner emits seven separated hypothesis categories (e.g. pharmacokinetic enzyme conflict, pharmacodynamic load overlap, target-system convergence, pharmacovigilance signal) rather than one "severity" word, each with counter-evidence and uncertainty.
• Real data, offline. A Python tool pulls the full ChEMBL mechanism + metabolism tables and an ATC→load mapping into a staged JSON the app reads with no runtime network. A second tool stages real openFDA drug-label sections (boxed warning, contraindications, interactions, warnings, PK/PD, adverse reactions, dosage) as quote-bounded evidence.
• Safety wording is enforced. Every generated string must pass a research-safe language policy (no prescribing directives); pharmacovigilance is signal-only and rendered non-causal.
• Target convergence done carefully. Non-neurotransmitter targets (hERG, COX, carbonic anhydrase, coagulation factors…) converge only on an exact shared target, never as a coarse "system," to avoid false positives.

What it does — a user journey.

• Enter or import a medication list (e.g. the drugs from a research case).
• Each drug is normalised against the 23.6k identity index (RxCUI/ATC), and matched to deep reasoning where available.
• The reasoner returns categorised hypotheses: shared CYP pathways (e.g. a CYP2C19 conflict), overlapping loads (QT, serotonergic, bleeding), converging targets — each with mechanism text, counter-evidence and verification pointers.
• Real FDA label snippets appear as evidence (e.g. clopidogrel's genuine CYP2C19-loss-of-function boxed warning; sertraline's suicidality boxed warning).
• Everything is framed as research; nothing is a recommendation.

Features a visitor could see (capture-to-do from the app): the Combine panel; the What-If panel; an evidence/provenance view with the drug count metrics; the index/search tab.

Technical foundations. Curated seed + graph store + DrugNormalizer; CombinationReasoner; PharmacologyEnrichmentStore (Tier-2 synthetic ingredients from ChEMBL); NeuroPharmacologySharedDrugIndex (identity); PharmacologyLabelStore (openFDA/DailyMed labels, new this session); live adapters (RxNav, ClinicalTrials.gov, ChEMBL) that only annotate. Data sources (all public): RxNorm/RxNav, WHO ATC, ChEMBL, openFDA/DailyMed. Staging tools: build_drug_index.py, build_pharmacology_enrichment.py, build_pharmacology_labels.py.

Maturity by feature (reported by the project agent on 17 October 2026 unless noted)

Roadmap (aspiration)

FAARS signal partitions; UK/EMA/genomics sources (catalog-only today); wider deep-reasoning coverage; the blocked Python bulk resource mirror (SSL-blocked on the build host — the label tool, by contrast, works).

Known limits

Deep pharmacology data only exists for a few thousand characterised drugs; the long tail stays identity-only (honest ceiling, not a bug). ChEMBL coverage is occasionally idiosyncratic, so it annotates, never overrides, the curated seed. Non-diagnostic; no personalised dosing.

FAQs

• Is this medical advice? No — research/educational only; a wording guard blocks prescribing language.
• Does it really cover 20,000+ drugs? ~23,600 for identity/search; deep mechanism reasoning covers ~6,000 where real data exists. Both numbers are stated honestly.
• Where does the data come from? Public databases — RxNorm/RxNav, WHO ATC, ChEMBL, openFDA/DailyMed — staged offline.
• Does it need the internet? No; reasoning is fully offline. Live lookups only add annotations.
• Can it tell me if my medicines are safe together? No. It surfaces mechanisms and evidence for research; clinical decisions belong to a professional.

Computational Neuroradiology reasoning engine (research module)

Biography

The problem. Imaging analysis is usually a black box: a number appears with no lineage and no uncertainty. The owner — with a medical-imaging background — wanted analysis that shows its working: what was measured, from which evidence class, with what confidence, and what the alternative explanations are.

Origin and motivation. A large owner vision doc was turned (Jul 2026) into a gap-fill roadmap after a survey found most building blocks already existed. The honest realistic target was named a "Radiology Reasoning Engine"; the physics-sim / "reality compiler" / meta-science arc was explicitly parked as a research horizon, not a build commitment.

Audience. Imaging researchers, method developers, the studio’s thesis work. Not clinical use.

Distinctive ideas.

• ~19 engine cores, each a pure, self-tested core plus a macOS card, mounted under the Evidence Explorer.
• Evidence Explorer = the multi-panel workstation as one recursive node drill-down (report ⇄ graph ⇄ MPR overlay ⇄ 3D link-back ⇄ literature).
• Atlas-grounded region naming from staged FSL volumes (Harvard-Oxford, JHU), verified on real data.
• Uncertainty + evidence class propagate through the reasoning, and drive how things are shown and captioned.
• Offline literature leaf over a local research-packet store; live PubMed/CT.gov connectors only annotate.

What it does — a user journey. Reconstruct a study (DICOM module) → run the analysis cores → open the Evidence Explorer → drill from a finding into its graph, overlay and 3D anchor → read the offline evidence behind it → optionally pose a non-personalised drug/mechanism "what-if."

Maturity (from session records, Jul–Aug 2026)

• All 19 engine cores built + self-tested in-tree; Evidence Explorer and its 5 UI surfaces built.
• "Everything codeable offline is built (~80%)."
• Atlas label volumes staged + GREEN at runtime on real CT (2026-08-30); Twin suite 503/503; Computational-Neuro ~2565/2578 across ~134 suites (13 known pre-existing failures logged).
• Genuinely pending: human runtime pass of several surfaces; live SceneKit selection binding + MPR-canvas compositing ("last mile"); prior-scan registration data; auth-gated live connectors.
• Not released.

Roadmap / limits

Last-mile live compositing; longitudinal change on real prior scans; the parked physics/meta-science horizon stays a horizon. Non-diagnostic; several surfaces self-tested but not runtime-verified.

FAQs

• Does it diagnose? No — it's a reasoning engine, explicitly non-diagnostic.
• What's an "evidence class"? A tag on every derived item (measured / segmentation-derived / atlas-prior…) that controls how it's shown and what it may claim.
• Does it need the cloud? No; analysis + literature are offline. Live connectors only annotate.

— End Part 2/3. Part 3 (Lens 4D stage + Twin Brain + evidence appendix + remaining scope) follows.

Roadmap / limits

No linked-scroll across compare cells (claiming one would be unsupported); true per-frame screen-space label declutter not done (column stacking is the ceiling); live selection binding is "last-mile." Non-diagnostic.

FAQs

• Are decimated meshes measured? No — decimation is display-only; measurement uses the full mesh.
• Why do some structures show as "listed" not drawn? Residency budget (scaled to your Mac's RAM); they're staged, not dropped.
• Is a surface "measured"? Only if its evidence class says so; iso-level surfaces are labelled as such.

Twin Brain compiler (research module)

Biography

The problem. A study is many separate series; reasoning over them individually loses the whole picture, and naive "alignment" invents geometry. The owner wanted one coherent scenario per study, assembled only where the data supports it.

Origin and motivation. runStudyTwinBrain() closed three gaps that had made it "not the full spec": radiomics+cochlear folded into the study pass; true cross-series referencing; and a coupled simulation built from observed regions. A key refactor pulled the logic into a standalone TwinStudyCompiler so a self-test can drive the shipping code without a real DICOM decode.

Audience. Imaging/neuro researchers; the studio’s thesis. Not clinical.

Distinctive ideas.

• Honest registration. Per-series scalp fiducials (direction cosines from slice orientation); the first series with ≥3 fiducials is the reference; others align via a similarity (Horn/Umeyama) transform. Unregistrable series fall back to their own per-series grouping — no fabricated alignment.
• Observed-data simulation. A coupled pathway-stress + Wong-Wang network run whose network is built from the study's own observed regions/territories; the higher-level graph stays synthesised from structural groupings (acyclic).
• Testable seam. Pure TwinStudyCompiler + value-type inputs let the exact shipping logic be unit-tested headlessly (self-tests stageE-radiomics, study-cross-series).

What it does — a user journey. Open a multi-series study → run Study Twin Brain → series register into a common frame (or fall back) → radiomic/cochlear signals attach → structures cluster across acquisitions → a coupled dynamics run enriches the scenario → explore it in the Lens stage / Evidence Explorer.

Maturity (session records, ~Jul 2026 — older)

• Built green (macOS); self-tests registered in the Twin suite (503/503 at a later atlas run). Research-only.

Roadmap / limits

Registration needs ≥3 fiducials per series or it falls back; the mm-residual registration quality item is tracked elsewhere. Non-diagnostic.

FAQs

• Does it invent alignment between scans? No — unregistrable series fall back to per-series grouping.
• Is the "twin" a simulation of the patient? No — it's a research scenario assembled from observed structures/signals, non-diagnostic.