Why Nexus exists
Why Nexus exists
Section titled “Why Nexus exists”N1 uses workflow-specific clinical AI paths today. Nexus defines one standard way to build clinical AI products.
Product logic, token handling, patient-context access, model routing, telemetry, and output shaping are currently assembled per workflow in multiple paths. This increases delivery time, review overhead, and runtime variation.
| Problem | Why it hurts |
|---|---|
| Cross-cutting runtime concerns get rebuilt or re-wired locally | Fixes and policy changes must be applied in more than one place. |
| Product outputs use report- or CHR-shaped assumptions in some paths | Additional product surfaces require extra translation or parallel output logic. |
| Tool surfaces can grow large | Tool definitions and outputs become harder to review and use consistently. |
| Engineers spend more time writing framework code instead of product definitions | The boundary between product authoring and runtime internals becomes less explicit. |
The fix in one line
Section titled “The fix in one line”Nexus makes most engineers author product files, not runtime code; n1r.core loads and governs those packs; Pinax exposes shaped capabilities under real caller scope; the runtime emits clinical reasoning artifacts; Composer turns those artifacts into product surfaces.
What Nexus is not
Section titled “What Nexus is not”- It is not a renamed CHR pipeline.
- It is not a safety or security product.
- It is not a rename of any one execution substrate.
- It is not a wide-open plugin system for arbitrary Python hooks.
- It is not a promise that every old workflow can be replayed stochastically forever.
What Nexus changes
Section titled “What Nexus changes”Nexus defines a product-oriented structure: a new product slice is primarily a new authored pack plus any required artifact or Composer surface definition, rather than a new workflow-specific runtime implementation.