Questions & assumptions notes
Ask the question first. If the answer is unavailable, state the default assumption and show how it shapes the design.
Opening cue
“Before I show the architecture, I want to clarify six decisions that materially change how the system should work. If any answer is unknown, I’ll state my assumption explicitly.”
Question 01
Panel and ownership
“Is the 1,200-patient panel owned by one clinician or shared across a care team? When Praxis identifies work, who is responsible for completing it?”
Why it changes the design
Ownership determines permissions, personalized ranking, task routing, duplicate prevention and accountability.
Default assumption
Prioritization is personalized for the clinician, while execution may be shared across the care team. Every task has one accountable owner and deadline.
Many people may collaborate, but every action must have one owner.
Question 02
Data and freshness
“Which sources can Praxis access—EHR, claims, labs, pharmacy and inbox—and how quickly does each source update?”
Why it changes the design
The ingestion model and safety controls change when data arrives immediately, daily or weeks later.
Default assumption
EHR changes, labs and inbox events arrive near real time. Claims and outside records may be delayed. Every fact stores its source, clinical date and ingestion date.
Praxis must understand both when something happened and when the system learned about it.
Question 03
Reasoning triggers
“Should Praxis run on a schedule, react to clinical events, respond to clinician requests, or support all three?”
Why it changes the design
Running deep reasoning after every small chart update would be expensive and create unnecessary alerts.
Default assumption
Use a hybrid model: events trigger urgent workflows, scheduled runs refresh panel priorities, and clinician requests trigger on-demand analysis.
Use a cheap trigger and relevance check before expensive clinical reasoning.
Question 04
Autonomy boundaries
“Which actions may Praxis complete automatically, and which must remain drafts or recommendations for clinician approval?”
Why it changes the design
Summarizing information, drafting a message, placing an order and changing treatment require different safety boundaries.
Default assumption
Praxis may summarize, rank and create internal tasks. Patient messages, orders and care-plan changes remain drafts. Clinical actions require approval.
Autonomy is determined by the action’s risk—not by how confident the model sounds.
Question 05
Approval and escalation
“Who may approve each action, how long should approval remain valid, and what happens when nobody responds?”
Why it changes the design
Patient information can change while an action waits, and urgent work cannot remain unowned indefinitely.
Default assumption
Each proposal has an approver, risk level and expiration. Praxis rechecks patient state before execution. Urgent unanswered work escalates.
Approval applies to one action based on one patient-state snapshot—not as permanent permission.
Question 06
Success measures
“What outcomes define success, and what safety, latency and cost limits must the system satisfy?”
Why it changes the design
A fluent response can still be unsafe, badly ranked, too slow, too expensive or never acted upon.
Default assumption
Measure safety, grounding, ranking quality, clinician acceptance, completed work, time to attention and cost per patient screened.
A fluent recommendation is not success; a safe, useful and completed action is.
Closing transition
“I’ll proceed using these as explicit assumptions. The architecture will isolate them so the system can evolve when the real constraints become clear.”