Rails and Provenance

Clinical responses use versioned rails to make evidence, patient context, and execution route auditable. The backend emits the contract and the frontend resolves it through one adapter.

Canonical Objects

Object	Responsibility	Main fields
ClinicalEvidencePacket	Evidence used or rejected for a response.	packet_hash, query_frame, evidence_outcome, ledger_summary, items, provider_plan, provider_trace, exclusion_counts, gate_snapshot
PatientContextManifest	Patient context available to the response.	manifest_hash, patient_context_status, patient_refs, included_sections, omitted_sections, freshness, phi_egress_state, case_state_ref, open_decisions
CorvusProvenance	Route, gates, and response-version record.	provenance_hash, provenance_status, packet_hash, manifest_hash, route, agent_type, finalizer_route_context, gate_precedence_applied, gate_snapshot, verifier_snapshot, feature_flag_snapshot

Use these backend names exactly. Do not document older frontend-only shapes such as included_domains or path_selection as fields on these objects.

Response State

final_answer_state is answerability state, not a native field on CorvusProvenance. The frontend extracts it from answerability fields and normalizes it:

Backend	UI
clinical_answer_ready	ready
partial_but_useful	partial
safe_insufficiency	insufficient_evidence
wrong_domain_blocked	blocked
safety_blocked	blocked
needs_clinician_review	review

Additional quality states such as safe_partial_with_actionable_guidance, partial_but_unsupported, and unsafe_or_misleading_partial are review signals, not automatic approval.

Frontend Rule

agentResponseResolvers.ts is the propagation point for these objects. CorvusHub, ResearchQualityPanel, ChatMessage, and response cards should consume the resolver instead of parsing payloads ad hoc.

Non-canonical surfaces such as academy research, helper actions, lab analysis, and parts of the clipboard/plan pipeline may expose limited provenance and should be labeled that way.