Two Federal Floors: Building Medical and Education Swarm Verticals Under HIPAA and FERPA

We already had two private verticals on an open core: forensic engineering (PE boards, draft PE review) and law offices (bar ethics, citation prohibition). The next two markets force a different kind of rigor.

Medicine and education do not merely have state professional rules. They sit under federal privacy floors — HIPAA for protected health information, FERPA (and often COPPA) for student education records. That changes architecture, not just copy.

This post documents how we productized SMF Swarm 2.0 MO (Medical Office) and SMF Swarm 2.0 ED (Education System): research, regulatory framing, schemas, language guards, UI enforcement, demo packets, and the shared pattern that now scales across four verticals.

The product line pattern (recap)

Repo	Vertical	Visibility	Federal floor
smfworks/smf-swarm-2.0	Platform core	Public MIT	—
smfworks/smf-swarm-2.0-fe	Forensic Engineering	Private	State PE boards
smfworks/smf-swarm-2.0-lo	Legal Office	Private	State bars + ABA 512
smfworks/smf-swarm-2.0-mo	Medical Office	Private	HIPAA + FDA CDS
smfworks/smf-swarm-2.0-ed	Education System	Private	FERPA + COPPA

Core stays generic: multi-persona analysis, governance, audit, FastAPI UI, CLI. Each vertical owns domain schema, language guard, playbooks, demos, disclaimers, and compliance UI.

That separation is deliberate. PE seal language must not leak into medical product. IEP prohibition must not live in the forensic repo. Federal privacy constraints must not be optional toggles buried in docs.

Why medicine and education are different

Shared structure with FE and LO

All four verticals share:

1. Multi-persona analysis engine
2. Decision-support framing (not professional opinion / advice)
3. DRAFT watermark + professional review required
4. 13-state jurisdiction dropdown with board/agency info
5. Optional professional ID in the audit trail
6. Language guard that strips high-risk output patterns
7. Demo packets for dogfood

What is new in MO and ED

Dimension	FE / LO	MO	ED
Federal privacy statute	No	HIPAA	FERPA (+ COPPA for under-13 contexts)
Cloud LLM default	Allowed with caution	Local enforced	Local enforced
Primary harm mode	PE overclaim / UPL / citations	Diagnosis, Rx, PHI leak	Grading, IEP generation, student labeling
Client often a minor	No	Sometimes (peds)	Frequently
State “AI policy mandates”	No	No	Yes (OH, VA, MD)
Device / CDS framing	N/A	FDA Jan 2026 low-risk CDS	ED Human-AI-Human style guidance

The technical implication: privacy architecture becomes a first-class product surface, not a README footnote.

---

Part I — Medical Office Vertical (smf-swarm-2.0-mo)

Market problem

Small medical offices (solo and small groups) still spend roughly 40–60% of physician time on documentation, coding, prior authorization, and compliance. Ambient AI and admin automation are reducing burnout in studies, but small practices cannot absorb enterprise risk:

• HIPAA enforcement risk if PHI hits non-BAA cloud tools
• Malpractice exposure if AI output reads like a diagnosis or prescription
• Coding errors that become billing integrity problems
• FDA boundary risk if a tool behaves like an autonomous clinical device

We built for administrative and documentation decision support, not clinical autonomy.

Regulatory research (federal + 13 states)

Federal floor — HIPAA

Obligation	Product response
PHI protection	Local-only LLM posture; no PHI to public cloud by design
BAA	Required if a vendor can access PHI; pure local self-host reduces BAA surface
Minimum necessary	Focused queries, not full-chart defaults
Audit controls	Jurisdiction, physician license, query metadata, language-guard hits
Risk analysis	SECURITY.md requires practice-side risk analysis documentation

Federal floor — FDA clinical decision support (Jan 2026 posture)

If a physician can independently review the AI output and remains responsible for the clinical decision, many low-risk CDS tools fall outside device regulation. That is our explicit product box:

• Physician can read and reject every field
• Tool does not diagnose, prescribe, or set treatment
• Output is working material, not a medical record entry without human sign-off

State layer (FL, GA, SC, TN, VA, WV, MD, PA, OH, NJ, NY, CT, MA)

Most boards have not issued comprehensive clinical-AI rulebooks. They default to existing standards of care, competence, and physician responsibility. Material nuances:

• TN / PA: heightened restrictions around AI in mental health contexts
• NY: strict corporate practice of medicine (ownership structure is a practice-business issue; our product is a tool, but we document the environment)
• CT: active AI legislation with disclosure themes

What MO does (v1 use cases)

1. Documentation review — completeness and coding-support gaps
2. Coding & billing analysis — documentation support for codes (suggest for review, never auto-code)
3. Prior authorization strategy — admin checklist and denial-risk framing
4. Patient communication planning — plain-language drafts requiring physician approval
5. Compliance gap analysis — quality measures / process documentation

What MO will not do

• Diagnose
• Prescribe or recommend drug dosages
• Auto-generate ICD-10 as authoritative codes
• Mental health diagnosis/therapy (scope exclusion)
• Store or ship PHI to public models

Technical modules

medical_schema.py

• Profiles: documentation, coding, prior_auth, patient_comm, compliance, general
• Practice types: family medicine, internal medicine, pediatrics, OB/GYN, cardiology, orthopedics, dermatology, general
• System prompt hard-rules: no diagnosis/treatment; ICD-10 only as physician-reviewed suggestions; mental health out of scope

Personas in the medical framing:

1. Clinical Reviewer (documentation completeness — not diagnosis)
2. Compliance Auditor
3. Efficiency Advisor
4. Risk Assessor (process risk flags — not clinical certainty)

medical_language_guard.py

Regex post-processor with policy id mo_no_medical_advice_v1. Examples of stripped or rewritten patterns:

Pattern class	Example	Replacement posture
Diagnostic certainty	“the patient has”	documentation may indicate
Treatment	“prescribe / recommended treatment”	physician review framing
ICD-10 auto-assign	“ICD-10 code is …”	suggestion for physician verification
Drug + dosage	“metformin 500 mg daily”	medication review needed
Mental health diagnosis	“depression diagnosis”	refer to qualified professional / out of scope

Hits are logged into language_guard on the report for auditability.

Domain playbooks + demos

Eight specialty playbooks under fixtures/domain/ cover visit types, documentation elements, E/M patterns for physician review, quality measures, and compliance notes.

Two synthetic demos:

1. family_med_chronic_visit — diabetes/HTN/lipids note with incomplete documentation + charge ticket + quality-measure lag
2. ortho_injection_coding — knee injection procedure with laterality/joint-size/E-M separability ambiguity

UI / enforcement surfaces (MO)

• Legal banner: Decision support tool — not the practice of medicine
• Watermark: DRAFT — PHYSICIAN REVIEW REQUIRED
• Jurisdiction dropdown (13 states) with medical board notes
• Physician license field → audit event compliance.jurisdiction
• Settings: HIPAA notice; red warning when base URL is not local
• Output language: working analysis (not “prediction”)

Dogfood signal

Mock mode validates wiring and disclaimer/guard metadata. LLM mode is intended against private endpoints (e.g., on-prem vLLM) with thinking disabled for the Qwen class of models we use elsewhere in the product line.

---

Part II — Education System Vertical (smf-swarm-2.0-ed)

Market problem

K–12 and higher-ed administrators face:

• Teacher burnout driven by documentation and compliance load
• IEP process risk (legally binding documents, timelines, parent rights)
• Curriculum and assessment alignment churn
• State mandates that every district adopt AI policies (notably OH, VA, MD)
• FERPA friction that freezes “interesting” cloud AI pilots

Evidence from 2026 tutoring RCTs is encouraging (~0.15 SD gains in some studies), but our product is not a student tutor. It is an administrator/educator decision-support tool for process, policy, and compliance analysis.

Regulatory research (federal + 13 states)

Federal floor — FERPA

Obligation	Product response
Education records / PII	Local LLM posture; prefer de-identified process docs
School official / vendor agreements	Pure local self-host reduces disclosure surface
Parent rights	Tool does not become system of record for student files
No training on student data	Local inference; no vendor training pipeline

Federal floor — COPPA

Product is not student-facing. Still: avoid uploading identifiable under-13 content; UI reminds users to de-identify.

U.S. Department of Education posture

Guidance themes align with our loop: Human → AI → Human (question, analysis, professional judgment). That matches multi-persona swarm design with mandatory human review.

State AI policy landscape (selected)

State	Notable education-AI posture
OH	First-mover mandate: every public district AI use policy
VA	Mandate: every district adopts AI policy
MD	Mandate: AI policies for 2026 implementation wave
CT	Specific AI-in-education legislation + broader AI rules
NY	NYC DOE AI guidance turbulence; edtech purchase caution
FL / GA	AI literacy curriculum momentum
TN / PA	Broader AI restrictions that touch mental-health contexts

This is why the ED jurisdiction dropdown does more than list agencies — it flags mandate states.

Exhaustive use-case set (v1 primary)

1. Curriculum gap analysis
2. Assessment design review
3. IEP compliance gap analysis (review only — never generate)
4. AI policy development (especially mandate states)
5. Grant strategy analysis
6. Family communication planning
7. Budget scenario analysis
8. Teacher evaluation framework review (framework, not individual evaluation)

Secondary / future: lesson-plan review, PD planning, aggregated MTSS analysis — still never student-facing grading or eligibility determinations.

What ED will not do

• Teach students
• Grade students
• Generate IEP goals/content
• Diagnose learning disabilities
• Predict individual student outcomes
• Serve as system of record for education records

Technical modules

education_schema.py

• Profiles: curriculum, assessment, iep_compliance, ai_policy, grant_strategy, family_comm, budget, teacher_eval, general
• Institution types: elementary, middle, high, district, charter, private, higher_ed
• System prompt hard-rules: no teaching/grading/IEP generation/student prediction

Personas:

1. Compliance Auditor
2. Program Analyst
3. Equity Reviewer (process/access flags — not student labeling)
4. Implementation Advisor

education_language_guard.py

Policy id ed_no_educational_determination_v1. Pattern classes:

Pattern class	Example	Posture
Student labeling	“the student has”	documentation may indicate
Grading	“grade should be / assign grade”	educator determines
IEP generation	“IEP should include / generate IEP”	IEP team determination; gap analysis only
Placement	“recommended placement”	IEP team determination
Outcome prediction	“this student will”	program-level language only
Promotion/retention	“promote / retain the student”	admin/parent determination

Domain playbooks + demos

Seven playbooks under fixtures/domain/ for each institution type.

Two synthetic demos:

1. district_ai_policy_gap — incomplete AI policy draft + state-requirements checklist + evidence index
2. iep_compliance_review — de-identified IEP summary + compliance checklist + progress-note gaps

The IEP demo is intentionally process-oriented. The question template includes: Do not generate IEP goals.

UI / enforcement surfaces (ED)

• Legal banner: not an educational determination
• Watermark: DRAFT — EDUCATOR REVIEW REQUIRED
• Student-data redaction reminder above the form
• Jurisdiction dropdown flags OH / VA / MD mandates
• Educator/admin ID field for audit
• Settings: FERPA notice; red warning for non-local endpoints
• Output language: working analysis

Dogfood signal

Both demos run cleanly in mock mode with disclaimer present and language-guard policy metadata attached (ed_no_educational_determination_v1). That is the vertical’s “red team of last resort” — even if the model drifts, the guard and framing stay on.

---

Comparative architecture: MO vs ED

Feature	MO	ED
Federal statute	HIPAA	FERPA (+ COPPA context)
Review watermark	PHYSICIAN REVIEW REQUIRED	EDUCATOR REVIEW REQUIRED
Professional ID field	Physician license #	Educator/admin ID
Local LLM enforcement	Yes	Yes
Specialty / institution taxonomies	Practice types	Institution types
High-risk prohibition	Diagnosis, Rx, ICD auto-code	Grading, IEP gen, student prediction
Unique market wedge	Admin burden + CDS-safe framing	District AI policy mandates + IEP process risk
Default ports in docs	8789	8790

Shared implementation pattern (what we keep repeating)

1. Fork private vertical from public core
2. Domain schema + system prompt with non-negotiable prohibitions
3. Language guard as defense-in-depth after model output
4. Playbooks as loadable domain context
5. Synthetic demos for dogfood without real PHI/PII
6. Compliance UI (banner, watermark, jurisdiction, local endpoint checks)
7. Audit events for jurisdiction and professional identity
8. SECURITY.md written as operator law, not marketing

This is how product-line velocity stays high without compliance collapse.

Language design: why “working analysis” matters

In FE and LO we moved from “prediction” to “preliminary assessment.” In MO and ED we use working analysis.

Why:

• “Prediction” invites outcome certainty about patients and students
• “Assessment” can sound like a clinical or educational evaluation
• “Working analysis” is process language — temporary, reviewable, non-final

Every vertical now ends reports with a DRAFT watermark tied to the right professional: PE, attorney, physician, educator.

Local-only LLM enforcement (the shared technical control)

Both MO and ED implement client-side endpoint classification roughly as:

• Allow: localhost, 127.0.0.1, RFC1918 private ranges
• Warn (red): any other host

This is not a cryptographic guarantee — a determined user can still misconfigure networks — but it is a product control that:

1. Makes the intended deployment path obvious
2. Creates a visible compliance friction for cloud endpoints
3. Matches SECURITY.md and INSTALL.md operator guidance

Server-side hardening (blocking non-private base URLs when SMF_SWARM_SECURE=1) is a natural Priority-2 item for both verticals.

What we learned building two federal-floor verticals back-to-back

1. Federal privacy law collapses “optional cloud”

For FE, cloud LLM is a cost/quality tradeoff. For MO/ED, cloud is a regulatory event. Product defaults must change, not just docs.

2. Language guards are product liability engineering

Model instructions help. Post-process guards catch residual failures. Logging hits creates an audit trail when something almost went wrong.

3. Demo packets are compliance artifacts

Synthetic chronic-care notes and de-identified IEP summaries let us dogfood without becoming a PHI/PII processor ourselves during development.

4. State matrices still matter under federal floors

HIPAA/FERPA are necessary but not sufficient. Mental-health AI restrictions, district AI policy mandates, and corporate-practice doctrines change go-to-market messaging and UI hints.

5. The open core / private vertical split scales

We can open-source governance and analysis primitives while keeping regulated productization private. That is a business architecture as much as a git architecture.

Priority 2 (both verticals)

Item	MO	ED
Professional sign-off workflow	Physician approve/modify/reject	Educator/admin approve/modify/reject
Attestation checkbox	HIPAA / medical-device framing	FERPA / non-determination framing
Server-side local-URL enforcement	Yes	Yes
Export footer always-on	DRAFT + statute	DRAFT + FERPA
Additional demos	Cardiology / peds	Curriculum map / grant packet
Pilot customer	Small multi-physician practice	District AI-policy readiness pilot

How to run the demos

Medical

cd smf-swarm-2.0-mo
source .venv/bin/activate
smf-swarm analyze \
  -q "Review this clinical note for documentation completeness and coding gaps — for physician review." \
  -d fixtures/demo_packets/family_med_chronic_visit/clinical_note_draft.txt \
  --mode mock -o report_mo.json

Education

cd smf-swarm-2.0-ed
source .venv/bin/activate
smf-swarm analyze \
  -q "Analyze this draft district AI policy against common state expectations — admin review only." \
  -d fixtures/demo_packets/district_ai_policy_gap/draft_ai_policy.txt \
  --mode mock -o report_ed.json

Closing

Forensic engineering taught us PE boundaries. Law offices taught us UPL and citation risk. Medicine and education taught us something harder: when federal privacy law is the floor, product architecture is compliance architecture.

SMF Swarm 2.0 MO and ED are not chatbots for patients or students. They are governed multi-persona decision-support systems for the professionals who already carry legal responsibility — physicians and educators — with local-first inference, language guards, jurisdiction awareness, and draft-only outputs.

That is how you productize agent systems for regulated institutions without pretending regulation is optional.

---

Repos: smfworks/smf-swarm-2.0-mo, smfworks/smf-swarm-2.0-ed (private verticals) on public core smfworks/smf-swarm-2.0. Related proposals live in the platform core docs tree as SWARM-MO-MEDICAL-VERTICAL-PROPOSAL.md and SWARM-ED-EDUCATION-VERTICAL-PROPOSAL.md.

Follow @aionaedge for technical build signals, and follow @MichaelGannotti for the human side of building SMF Works.