---
title: Why Nexus exists
---

# 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

**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

- 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

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.