BiobadamexAI architecture
System map
Section titled “System map”flowchart TB
UI["React console"] --> API["Hono API"]
M2M["Service intake"] --> API
RAI["RheumAI audit proxy"] --> AUD["Audit API"]
AG["Dedicated clinician agent"] --> AGA["Agent API"]
API --> R2[("R2 · encrypted originals")]
API --> DB[("PostgreSQL · metadata and drafts")]
API --> Q["pg-boss"]
AUD --> EXT["Extractor"]
AGA --> Q
Q --> EXT
EXT --> NEB["Nebius · de-identified note"]
EXT --> CORE["Tri-state schema · DAS-28 · completeness"]
CORE --> DB
UI --> REVIEW["Review and correction"]
REVIEW --> DB
DB --> SUB["Submission request"]
SUB --> Q2["registry-submit queue"]
Q2 --> TENKI["Tenki microVM"]
TENKI --> REG["BIOBADAMEX ASP.NET"]
REG --> RECEIPT["idpac + summary"]
RECEIPT --> DBComponents
Section titled “Components”Web application
Section titled “Web application”The React console uses one note list for daily work. Filters show what needs attention. Review screens show source, structured record, corrections, treatment episodes, and a separate submission confirmation.
Mounted surfaces include intake, uploads, drafts, RheumAI audit, dedicated agent, and PHI-light lifecycle routes. Console routes require authentication, resolved user, and research access. Machine-to-machine routes use separate service keys.
Storage
Section titled “Storage”R2 holds encrypted original files. PostgreSQL stores metadata, jobs, drafts, audit, and submission outcomes. agentRecord is the immutable extraction; record is the clinician-correctable copy. Draft source text is encrypted when master-key configuration is available.
pg-boss separates extraction from registration. Workers register only when BIOBADAMEX_QUEUE_ENABLED=1. Extraction has retries and dead letter. Registration is a separate queue processed one at a time per worker. Multiple app instances need extra coordination for global serialization.
Domain package
Section titled “Domain package”@pokta/biobadamex-registry owns the record schema, unknown semantics, disease rules, DAS-28, job contracts, external field map, corrections, and completeness.
Registry worker
Section titled “Registry worker”A Playwright worker runs in a disposable microVM. It logs in, traverses crdA through crdE, reads idpac after crdA, and requires the final summary to show the same id.
Three distinct boundaries
Section titled “Three distinct boundaries”| Boundary | Controls | Does not prove |
|---|---|---|
| Extraction | Turns note into typed record | Every value is correct |
| Clinical review | Corrects and approves | External platform received every field |
| Worker confirmation | Reads idpac and summary | Field-by-field read-back |