Nexus — the standard way N1 builds clinical AI products

Nexus defines one composition model for clinical AI products: authored files, n1r.core, Pinax, the Nexus runtime, clinical reasoning artifacts, and Composer.

N1 currently has workflow-specific clinical AI paths where product logic, data access, token handling, model routing, telemetry, and output shaping are assembled per workflow. Nexus defines a standard product structure for those concerns.

What	Count	Detail
Standard product model	1	Nexus is the standard way N1 builds clinical AI products
Main runtime library	1	`n1r.core` owns pack loading, tokens, models, observability, run bounds, and artifact emission
Capability layer	1	Pinax exposes governed capabilities under the caller’s scope
Durable reasoning unit	1	Clinical reasoning artifacts are the durable platform record
Surface layer	1	Composer turns artifacts into narrative, chart, card, UI, and API surfaces

The components

Component	What it is	Status
Nexus	The standard way N1 builds clinical AI products. Most engineers author files. The runtime owns the rest.	Being defined
`n1r.core`	The N1-owned Python runtime API. Loads packs, validates them, acquires and refreshes OAuth2 tokens, resolves models, emits PHI-safe observability, bounds runs, and emits artifacts.	Specifying now
Pinax	The deterministic capability layer in front of patient-context and other governed tools. It uses the token and runtime context it is handed. It does not mint auth.	Specifying now
Clinical reasoning artifacts	The durable structured output of reasoning. They hold facts, evidence, interpretation, uncertainty, and lineage-friendly references.	Specifying now
Composer	The layer that turns artifacts into human-facing surfaces such as cards, charts, reports, chat payloads, and API outputs.	Specifying now
Baseline trust rails	Auth, PHI handling, telemetry rules, eval hooks, guardrails, audit, and bounded runtime behavior. These are baseline rails, not the platform thesis.	Specifying now

The one-line boundary split

n1r.core owns runtime mechanics. Pinax owns governed capability access. api-backend owns policy enforcement. Composer owns presentation. Artifacts own the durable reasoning record.

Pages in this deck

Page	Title	What it covers
01	Why Nexus exists	N1 uses workflow-specific clinical AI paths today. Nexus defines one standard way to build clinical AI products.
02	How products are authored	Most engineers should build Nexus products by writing validated files, not by editing framework internals.
03	`n1r.core` — what the runtime owns	`n1r.core` is the N1-owned runtime surface. It hides substrate details and owns the cross-cutting mechanics every Nexus product needs.
04	Pinax — governed capability access	Pinax is the deterministic capability layer. It exposes governed tools through a small reviewed surface.
05	Clinical reasoning artifacts — the durable spine	Nexus uses clinical reasoning artifacts as the durable platform record.
06	Composer — turning artifacts into surfaces	Composer is the layer that turns durable artifacts into the human-facing things product teams actually ship.
07	Runtime and lineage	The Nexus runtime should make product execution bounded, observable, and easy to audit without leaking sensitive content.
08	Baseline trust rails	Auth, PHI handling, telemetry rules, eval hooks, guardrails, and audit are baseline rails. They are not the product thesis, but they must be present from day one.
09	Proofs we already have	Several Nexus design elements already exist in working or audited form.
11	Decisions still requiring explicit ratification	These items require explicit owner-level confirmation.