White paper ·
MARA, the Medical Agentic Resident Assistant: Four Generations, One Line
MARA is meant to hold one patient's whole record for every role in their care. Three earlier generations, HAL 2000, MAX3 and MAX4, exist to prove her methods on machines with no patient data in them
Contents11 sections
MARA is meant to hold one patient's whole record for every role in their care. Three earlier generations, HAL 2000, MAX3 and MAX4, exist to prove her methods before a patient depends on them.
What MARA is for
MARA, the Medical Agentic Resident Assistant, holds one patient's record from cradle to grave and serves it to everyone in their care. She recommends. She never decides: a person does, and a provider agrees before any treatment or prescription starts. That rule doesn't bend, and most of what follows is about how it got built into code.
She exists because a patient's story is scattered, and it has been for as long as there have been separate systems to scatter it across. The primary care record, the hospital chart, the imaging archive, the lab, the pharmacy, the specialist, the insurer and the billing office each hold a part, and not one of them was built to hold the person.
The cost turns up in ordinary places. Last year's imaging read never reaches the diagnosis. A drug started at another clinic isn't on the chart. The plan won't cover the treatment, and the prior authorisation lands after the visit. A claim is denied because its code didn't match a diagnosis held in another system, and the patient — who did nothing wrong — gets the bill. Tests get repeated, because nobody could find the first set. What happened to thousands of patients like this one is known only in aggregate, months later, and almost never at the bedside where it would have helped.
Nobody in that chain is careless. Each of them is doing the job inside their own walls. What's missing is one record they can all see.
What she has to do
MARA's job comes in six parts.
- One record per patient, for life. Encounter notes, diagnoses (DX), treatments (TX), prescriptions (RX), imaging, labs, claims and benefits come together from every system the patient touches, and every fact keeps its source.
- Every role on that record. The patient, nurse, triage, provider, pharmacist, coder, biller and payer each see what their role needs, and they're all looking at the same thing.
- Enrichment at every touch. Each encounter, result, prescription and claim adds to the record and is graded for how sure it is and where it came from.
- Learning from outcomes. A treatment that works, a claim that's paid, a claim that's denied: each one teaches her, and a recommendation that missed is demoted.
- Learning across cohorts. A lifetime record is compared with records like it, so what happened to similar patients informs this one's next step.
- A recommendation with a reason. She gives a probability and the evidence behind it to whoever needs it, and then a person decides.
Done well, that lowers cost and improves care. Diagnosis comes earlier and more accurately, treatment works more often, and claims clear the payer the first time.
What she has to be trusted with
A record like this holds the most sensitive data a person has, and advice drawn from it can change their health. That sets seven requirements before MARA goes near a patient. Terms are explained where they first appear, and the glossary at the end collects them.
| Need | What it means |
|---|---|
| Security | Protected health information (PHI) is encrypted at rest and in transit; access is per role; nothing leaves where it shouldn't. |
| Compliance and audit | Every time anyone sees, touches, deletes, moves or uses a record, it's logged: who, what, when and why. HIPAA, the US health-privacy law, applies, and SOC 2 and HITRUST security audits follow when a hospital or payer asks. |
| Regulation | Food and Drug Administration (FDA) rules separate decision support from a medical device. MARA recommends with evidence and a provider decides, and she's built as if she were a device. |
| Owning the seam | Every handoff between systems, roles and processes is defined, guarded and recorded by us. Data crosses a boundary only through a gate we control. |
| Enriched, graded data | Every input carries its source and a confidence. Low confidence stays a hypothesis until it's proven. |
| Lifetime and cohort learning | She learns from each patient's outcomes and from cohorts, without leaking one patient's data to another. |
| Every role in one process | FHIR and USCDI (the US standard for exchanging health records, and its core data classes), prior authorisation and X12 claims standards let the same record work for provider, system, payer and patient. |
Table 1. MARA's seven hard requirements, and what each one means in practice.
None of the generations before her touches a real patient, and that's deliberate. Each one takes a row of this table and proves it on a machine where a mistake costs an evening. A method that's already been broken and fixed there is the only kind MARA gets to inherit.
The road to MARA
She's the fourth generation of one line. HAL 2000 (Heuristically programmed ALgorithmic computer) came first, in 2025: a voice assistant that proved an AI could live on one machine, know who it was talking to, and look things up. MAX3, the third MAX (Modular Algorithmic eXecutor), ran from 2025 to October 2026 as a local web application, and it learned to grade every claim, fill one knowledge graph from dozens of sources, and learn from outcomes. MAX4 started in October 2026 as a native Windows desktop resident. Its job is to move the safety gate into compiled code and prove identity, audit and isolation the way MARA will need them.
Medical software that skips a step tends to fail on a person. Building one generation at a time, on systems with no patient data in them, is slower. It's also the only order in which every method gets broken before anyone relies on it.
HAL 2000: an AI that lives in the room
HAL ran on one PC, as one Python program of about 20,900 lines. You said "HAL"; it woke, recognised you by voice or face, sent your question to a language model and spoke the answer. A word it didn't know sent it to seven web sources, and the result went into a cache.
| Area | How HAL did it |
|---|---|
| Voice | Silero voice detection, Whisper distil-large-v3 speech recognition primed with known names, Windows speech output |
| Identity | ECAPA-TDNN voice match with an automatic band (0.55 and up) and a confirm band (0.40 to 0.55); face recognition with unknown faces queued for review |
| Reasoning | Five language models in order, local models through Ollama first, with back-off when one failed |
| Knowledge | WordNet, Datamuse, dictionary, ConceptNet, Wikidata, DBpedia, GeoNames; a SQLite cache |
| Errors | One funnel for every source failure, one log per source |
| Self-heal | A snapshot of its own code after a good boot; restore only with a person's consent |
Table 2. How HAL did each part of its job.
Five things in HAL were worth keeping, and each turned out to matter more for medicine than for a house.
| What worked | Why it mattered |
|---|---|
| Recognising who's speaking, with a "please confirm" band | Identity is the first control in healthcare. A system that knows when it's unsure who it's talking to, and asks, is the seed of patient identification and role-based access. |
| Local first, cloud only as fallback | Patient data can't be sprayed across cloud services. Keeping the work on the machine by default is the seed of MARA's privacy posture. |
| Several knowledge sources, each with its own error log | Healthcare data arrives from many systems that fail in their own ways. Handling each source separately is the seed of combining an electronic health record (EHR), a lab, a pharmacy and a payer. |
| Self-heal only with consent, never touching user data | In medicine an automatic change nobody approved is a risk. Reversibility with a person in the loop became a core rule. |
| A working voice loop | A resident assistant at the bedside must be usable by speech. HAL's voice settings were good enough to carry forward almost unchanged. |
Table 3. What HAL got right, and what each part seeded for MARA.
The failures taught more. Every answer HAL gave sounded equally sure, with no confidence and no source behind it. A medical system that can't say how sure it is has no business near a chart. Its lookups never became knowledge. Facts sat in the cache and expired, and nothing improved with use. Voice, vision and lookups fought over one process and one CPU budget. It couldn't grow. Keys were quietly lost whenever the key store failed. There were no tests. Fixes regressed.
Silent failure was the worst of it, because a record that drops something without saying so is worse than no record.
The voice loop and six of its tuned settings crossed into MAX3, and so did ECAPA voice identity, speech recognition, the event bus, the knowledge sources, the error funnel and consent-based rollback. HAL's data, its interface, its cache and its habit of shipping without tests stayed behind.
HAL settled where MARA starts: local, aware of who's speaking, fed by more than one source. Its failures wrote MAX3's job description.
MAX3: a system that learns, and remembers its mistakes
MAX3 is a Python server with a web interface on one workstation, built from managers and workers around a single knowledge graph, and it grew to about 700 Python modules and about 950 backend test files. Its 282 registered event types are 23 times the 12 that HAL's event bus carried. Its 63 knowledge sources are nine times HAL's seven. Eleven hard rules govern every change.
Most of what MARA will think with was built here.
| What worked | Why it mattered |
|---|---|
| One knowledge graph that every source writes into | This is the shape of MARA's patient record: many systems feeding one connected record, rather than separate silos. MAX3 learned how to merge sources without losing where each fact came from. |
| Every claim graded FACT, BELIEF, HYPOTHESIS or OPINION, with confidence and source | MARA must say how sure she is and why. A diagnosis suggestion that can't show its evidence isn't usable. A low-confidence claim stays a hypothesis until it's corroborated. |
| Agreement across sources raises confidence | In healthcare a finding confirmed by the lab, the imaging and the history is stronger than one from a single note. MAX3's confidence pipeline is that idea in code. |
| Curiosity: gaps in knowledge become questions to answer | MARA must notice what's missing from a record (an unread scan, a missing lab, an unverified benefit) and go and find it. |
| Learning from outcomes, with misses demoted | This is the core of cohort and lifetime learning. MAX3's Forward-Forward network and its trust ladder learn from what actually happened, so advice improves with every result. |
| Medical sources already ingested: MeSH, RxNorm, openFDA, ICD-10, Disease Ontology, Uberon | MARA will speak in these vocabularies. MAX3 has already learned to read them and to frame medical claims cautiously. |
| Every automatic action held for 30 seconds with a rollback recipe, and audited | MARA's recommendations must be logged, reversible and overridable. MAX3 made this a rule rather than an option. |
| Default-deny security, a PIN for destructive actions, per-user privacy, loopback only | This is the baseline for handling protected health information: no data crosses a boundary unless it's allowed, and each person's data stays theirs. |
| A registry of 294 known failures, tests at every level, honest stubs | A certified medical system needs evidence that each defect was found, fixed and prevented. This is the habit an auditor will ask for. |
Table 4. What MAX3 got right, and what each part gives MARA.
The grading carries the most weight. A claim that only one source supports stays a HYPOTHESIS; a second source agreeing lifts it; an outcome that contradicts it pulls it back down. That's the loop a clinician runs informally every day, written down so a machine has to follow it.
MAX3 also got a lot wrong. The record is worth keeping. The browser couldn't reliably own the microphone or the camera. The interface also sat behind a web server on a network port, which is exactly the kind of open seam MARA can't have. The first graph database hung on stale locks and had to be replaced. It sprawled, too. On 28 September the AI services and build runners ate all of the machine's memory and CPU. On 4 October the month's hosted build minutes ran out. Autonomy features were built and then left switched off, which is a quiet way of admitting nobody had worked out how to trust them yet. Scope drifted into games, email, home power and the firewall.
That drift was an error in judgment about what the system was for. It cost weeks the core needed.
What crossed into MAX4 was the part that worked. The knowledge graph and identity profiles went across, with both ladders (grading for claims, trust for skills), the sources, the reading list, the audit log and the 30-second override. So did the rules, the failure registry and the test discipline. Everything else stayed behind, from the web server to the side projects.
MAX3 can merge sources into one record, grade every claim, learn from outcomes and act reversibly under audit. What it can't do is close its own seams. A port is open. A browser sits in the middle. Worse, the safety rules live only in Python, where any change can quietly step around them.
MAX4: owning the seam
MAX4 is a standalone Windows desktop app. A Rust shell owns the window, the microphone, the wake word, speech recognition and the trust gate. A Python helper does the thinking. The two talk over a named pipe, a local channel with an access list, a version handshake and a token per session. Nothing in the app listens on the network, and the local model server and vector store answer only on the machine itself.
| What MAX4 adds | Why it matters |
|---|---|
| A named pipe with access control, a version handshake and a per-session token, and no network port | This is owning the seam: every handoff between parts of the system goes through a gate we define. MARA's handoffs between EHR, lab, pharmacy and payer will follow the same pattern. |
| Python grades and proposes; Rust enforces the trust ladder and writes the audit in the same transaction | A recommendation can't happen without its audit record. If the audit write fails, the action doesn't happen. This is what compliance auditors look for. |
| A hash-chained audit log | An audit trail that can't be quietly edited is the standard MARA's "sees, touches, deletes, moves, uses" log must meet. |
| A trust ladder for every skill, starting at off: a skill earns probation on held-out accuracy and only then may take a reversible, audited action; competency (Heard, Tried, Held, Trusted, Autonomous) is tracked beside it | This is regulation in practice: a skill that hasn't proven itself on cases it wasn't tuned on doesn't act. MARA's rule that a provider agrees before treatment comes from here. |
| Identity with liveness checks, two modalities and owner confirmation; encrypted templates, never raw biometrics | Patient and staff identification reaches a standard MARA can build on, with the data protected even if the store is copied. |
| Per-user isolation; nothing leaves the machine | There's no leakage between people, which is the precondition for learning from cohorts without exposing any one patient. |
| Signed updates, a clean-room installer with verified downloads | A certified system has to prove what code is running and where it came from. |
Table 5. What MAX4 adds to MAX3, and why each part matters for MARA.
A regulator will read the gate first. Python grades a claim and proposes an action. Rust decides whether the skill behind it has earned the right to act, and it writes the audit entry in the same transaction as the change. Every skill starts at off, where MAX does nothing with it. Off is the floor. It reaches probation only after it's been right on 9 cases in 10 that it wasn't tuned on, across at least 8. Then, and only then, it may take a reversible, audited action with the 30-second override. One bad run demotes it. Competency, from Heard to Autonomous, is tracked beside the ladder. It answers a different question: how well the skill is done, rather than whether it may act.
MAX4 is early, and that's worth saying plainly before anyone mistakes a design for a running system. About 1,300 lines are built, roughly a sixteenth of HAL's 20,900, and they cover the shell, the tray, secure key storage, the clean-room installer, the first database schema and the screen renderer. The rest is on paper. The pipe, the helper, voice, identity, grading and the audit chain are designed and scheduled to start on 20 October 2026. Some documents have drifted, including a port number and an out-of-date architecture diagram. They're being corrected.
It's the first generation that enforces MARA's rules in code. Owning every seam, tying each action to its audit, keeping people's data apart, proving identity: HIPAA, SOC 2 or the FDA will ask MARA to show every one. Here they get proven on a machine with nobody's chart on it.
MARA, put together
Each generation left a piece, and MARA adds what none of them had.
| MARA needs | Comes from | MARA adds |
|---|---|---|
| Security | HAL local-first; MAX3 default-deny and loopback; MAX4 pipe, encryption, isolation | Encryption of PHI everywhere, TLS for real network transit, role-based access across organisations |
| Compliance and audit | MAX3 audit and override; MAX4 audit in the same transaction, hash-chained | Logging every read as well as every write; HIPAA, SOC 2 Type II, HITRUST |
| Regulation | MAX3 graded claims; MAX4 trust ladder and competency stages | A provider agrees before TX or RX; an FDA decision-support or device pathway |
| Owning the seam | MAX4 named pipe and trust gate | FHIR R4 and SMART for EHRs, Da Vinci for prior authorisation, X12 for claims, each behind a gate |
| Data enrichment | HAL multi-source; MAX3 graph and confidence pipeline | Every encounter, DX, imaging study, RX, TX, claim and benefit, per patient, cited |
| Cohort and lifetime learning | MAX3 outcome learning and trust ladder | Cradle-to-grave records compared across cohorts without exposing any one patient |
| Every role in one process | MAX3 manager-and-worker design | Views for patient, nurse, triage, provider, pharmacist, coder, biller and payer on one record |
Table 6. Where each of MARA's needs comes from, and what MARA adds to it.
She already runs as an offline demonstration. It has 24 role views and a 26-step guided tour through triage, check-in, coding, billing, pharmacy, prior authorisation, a payer's remittance and coordination of benefits. Five insurance scenarios balance to the cent.
The demo follows one fictional patient with a hurt ankle from a phone call to the final bill. A triage nurse asks the protocol questions; MARA hears "a little tingly earlier", reads it with a confidence, and suggests asking whether it's there right now. The nurse signs. The audit row shows who answered and who decided.
Looking back down the road
We started with the problem: healthcare holds each patient's story in pieces, spread across roles that can't see each other. MARA is meant to hold the whole story, from cradle to grave, for every role, enriched at each encounter and improved by every outcome and cohort, while a person always decides.
In healthcare, trust is earned in evidence. That's why the line runs in this order. Each method is broken on a machine with nothing to lose before it goes in front of a patient with everything to lose.
The demo nurse who signs off on "a little tingly earlier" is the test. When a real nurse does it, every step that put that answer in front of her will have been proven a generation back.
Sources
- Jason Newell, Building MARA, the source draft of 18 October 2026. The MAX3 and MAX4 counts (modules, test files, event types, sources, rules, known failures, lines built) and the dates of 28 September and 4 October come from it.
- "MAX: The AI Resident, and the Road to MARA", The Max Research Collective, October 2026.
- "MAX4 and MARA: The Ladder Starts at Off", The Max Research Collective, October 2026, for the trust ladder thresholds and the competency stages.
- NIST, SP 800-76-2, Biometric Specifications for Personal Identity Verification, July 2013, checked 18 October 2026.
- ISO/IEC, 19785-4:2025, Common Biometric Exchange Formats Framework, Part 4: Security block format specifications, checked 18 October 2026.
- ISO/IEC, 30107-1:2023, Biometric presentation attack detection, Part 1: Framework, checked 18 October 2026.
Glossary
| Term | Definition |
|---|---|
| CBEFF | The Common Biometric Exchange Formats Framework (ISO/IEC 19785) is a standard wrapper for biometric data that can carry integrity protection. MARA adds it, with a digital signature, so an identity template can be checked for tampering. |
| Cohort | A cohort is a group of patients with similar records. MARA uses cohorts to learn what worked for people like the one in front of her. |
| COB | Coordination of benefits decides which insurer pays first when a patient has more than one. The MARA demo works through it end to end. |
| Competency stages | Competency is MAX4's five-stage measure of how well a skill is done: Heard, Tried, Held, Trusted and Autonomous. It's tracked beside the trust ladder, and a miss drops it one stage. |
| Cradle to grave | Cradle to grave means a patient's whole lifetime record. MARA holds it as one record rather than as pieces in each system. |
| Da Vinci PAS, CRD | These are HL7 standards for prior authorisation and for coverage requirements. MARA uses them to ask a payer before the visit rather than after it. |
| DX, TX, RX | These are the clinical shorthands for diagnosis, treatment and prescription. |
| ECAPA-TDNN | ECAPA-TDNN is the speaker-recognition model used from HAL through MAX4. It's how the resident knows whose voice it's hearing. |
| EHR | An electronic health record is a provider's clinical system, such as Epic or Cerner. MARA reads from and writes to it through a gate. |
| Epistemic ladder | The epistemic ladder is MAX's grading of claims as FACT, BELIEF, HYPOTHESIS or OPINION. It's why every MARA recommendation says how sure it is. |
| FDA, SaMD | The US Food and Drug Administration regulates Software as a Medical Device, software the FDA treats as a device. MARA is built as if it will be one. |
| FHIR, USCDI, SMART | FHIR is HL7's standard API for health data, USCDI is the US core set of data classes, and SMART is the standard way an app launches against an EHR. Together they let MARA reach any compliant record. |
| Forward-Forward network | A Forward-Forward network trains each layer locally on true and corrupted examples. It's MAX's shared learner. |
| HAL 2000 | HAL 2000 (Heuristically programmed ALgorithmic computer) was the first assistant in the line, in 2025. It proved an AI could live on one machine. |
| HIPAA | HIPAA is the US law governing the privacy and security of PHI. Every MARA requirement on access and audit traces back to it. |
| ISO 30107 | ISO/IEC 30107 is the international standard series for biometric presentation attack detection, which catches a photo, recording or mask offered in place of a live person. MAX4 builds its liveness checks to it. |
| MAX | MAX, the Modular Algorithmic eXecutor, is the AI resident MARA is built on. |
| MAX3 | MAX3 is the third MAX (MAX3000), a local web application that ran from 2025 to October 2026. It's now frozen as the source MAX4 is ported from. |
| MAX4 | MAX4 is the fourth MAX, a native Windows desktop app, from October 2026 on. It enforces in compiled code the rules MAX3 only followed. |
| MARA | MARA, the Medical Agentic Resident Assistant, is the healthcare system this article is about. She's the goal of the whole line. |
| Medical vocabularies | MeSH, RxNorm, openFDA, ICD-10, the Disease Ontology and Uberon are the standard vocabularies for medical subjects, drugs, drug safety, diagnosis codes, diseases and anatomy. MAX3 already reads them, and MARA will speak in them. |
| Named pipe | A named pipe is a local, access-controlled channel between MAX4's Rust shell and Python helper. It has no network port, so nothing off the machine can reach it. |
| NIST 800-76 | NIST Special Publication 800-76-2 is the biometric specification for the US federal Personal Identity Verification (PIV) card, and it sets minimum accuracy requirements for deployed biometric checks. MARA adopts those floors for her identity checks. |
| Override window | Every automatic action is held for 30 seconds with a rollback recipe, so a person can veto it. |
| PHI | Protected health information is the patient data HIPAA governs. |
| SOC 2, HITRUST | SOC 2 and HITRUST are security audit frameworks that hospitals and payers ask vendors for. |
| The seam | A seam is any handoff between systems, roles or processes. Owning it means it's defined, guarded and recorded. |
| Trust ladder | The trust ladder decides whether MAX4 may act on a skill. Every skill starts at off, reaches probation on held-out accuracy of 0.9 over at least 8 cases, may then act reversibly with an audit, and is demoted by a single bad run. |
| X12 837 / 835 | These are the standard claim and remittance, or payment, transactions between a provider and a payer. |
Table 7. Glossary of the terms used in this article.
Keep reading
More field notes
This piece is part of the MAX Research Collective library. Browse the rest, or connect on LinkedIn.