API reference¶
Generated from source by mkdocstrings — never hand-written, so it cannot go
stale.
Interactive OpenAPI documentation is served by the running application at
/docs.
Endpoints¶
| Method | Path | Purpose |
|---|---|---|
GET |
/healthz |
Liveness |
POST |
/conversations |
Start a run (202 with its id); the graph runs in the background. Pass follow_up_to (the latest run of a conversation) to ask a follow-up in the same conversation and patient |
GET |
/conversations/{id} |
The durable record: status, answer, per-node cost |
GET |
/conversations/{id}/thread |
Every turn of the conversation this run belongs to, oldest first |
GET |
/conversations/{id}/events |
SSE: replays every stored step, then tails the run to completion |
GET |
/personas |
The demonstration patients a visitor can ask as (a demo selector, not a login) |
GET |
/reviews |
Drafts held for a clinician |
POST |
/reviews/{id}/decision |
Approve, edit or decline; resumes the paused run from its checkpoint |
POST |
/conversations/stream |
Phase 0 walking-skeleton stream, kept as the streaming proof |
Every response carries the synthetic-data and not-a-medical-device statement.
Endpoints are rate limited per client IP and per route: routes that start or
resume a model run share a strict ceiling (10/minute by default), reads and the
event stream a generous one (120/minute). A limited request gets 429. Request
bodies are capped at the ASGI layer. POST /conversations only answers as one of the personas from GET /personas; any other patient_id gets a 404. Errors carry a human-readable detail
(for example 404 for an unknown patient_id, 409 when a review was already
decided), which the frontend shows as-is.
Settings¶
Settings
¶
Bases: AgentSettings
Application configuration, sourced from the environment.
Source code in src/navigator/settings.py
Streaming¶
stream_conversation_events(run_store, run_id, max_wait_seconds=None)
¶
Replays every event already persisted for a conversation, then — while the run is still executing — tails newly-appended events until it reaches a terminal status. Works identically whether the patient connects the instant a run starts or reconnects long after it finished (docs/PLAN.md §5.8).
These events are the patient's own record and are deliberately not redacted; redaction guards the log/trace boundary, not the answer a patient reads (§5.7).
max_wait_seconds bounds the tail: a run that never reaches a terminal
status ends the stream with its current status rather than holding the
connection open forever.
Source code in src/navigator/api/streaming.py
Graph¶
The only file that wires nodes and edges (docs/PLAN.md §9.3).
build_skeleton_graph is the Phase 0 walking skeleton, kept so the streaming
path stays proven. build_navigator_graph wires the real graph (§5.1): intake
loads the patient header; the pre-flight gate (screen_rules ∥ classify_intent ∥
detect_language → resolve_policy) routes to a templated branch or into the
investigate loop; the investigate loop drives the scoped executor; draft_answer
produces the cited PatientAnswer; post-flight (extract_claims -> post_flight)
runs the three safety checks and routes to publish, a templated escalation, the
review queue, or back into the loop for a missing citation (§5.3).
Node filename == registered node name == trace span name (§9.3 rule 3).
build_navigator_graph(settings, *, intent_chain=None, answer_writer_chain=None, explainer=None, claim_extractor_chain=None, scope_judge_chain=None, contextualizer_chain=None, checkpointer=None)
¶
The only function that wires the navigator graph's nodes and edges.
The LLM-backed pieces are injectable so the graph can be assembled and tested offline with stubs; in production they are built from the configured models.
Source code in src/navigator/graph/builder.py
77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 | |
build_skeleton_graph()
¶
Phase 0 walking skeleton: echo -> done.