event_id (and, for multi-step workflows, a shared run_id).
This design means a record exists even when inference fails, and lets outcomes or feedback be added
later — sometimes hours or days after the model ran.
All examples below authenticate with an API key passed in the
X-API-Key header. Every endpoint is
write-only: collectors accept events but never return record contents.Emit a record
1
Record the start of inference
The first message captures everything available at invocation: the header,
model instance,
user and
target identities, and the
inputs. It mints the
event_id (and a run_id if
this is part of a multi-step workflow).2
Append internal artifacts (optional)
Reasoning traces, retrieved context, uncertainty estimates, and other intermediate artifacts are
referenced back to the same
event_id. This field is optional.3
Record the human-facing output
The prediction, generation, or recommendation shown to a clinician or patient.
4
Attribute an outcome and capture feedback (when available)
Outcomes and feedback often arrive later. Post them whenever they become observable, referencing
the original
event_id.Minimal implementations
MedLog scales down. In low-resource or offline settings you can log only a small set of fields — Header, Model instance, and Outputs — and add more fields as local capacity grows.Next steps
The record schema
Understand the nine fields in depth.
Example record
An annotated, real MedLog record showing every field.
Integration patterns
Wrap model calls at API gateways, LLM proxies, and agent frameworks.
API reference
The five write-once event endpoints.