Provenance-Labelled, Independently Verifiable Encounter Records in AI-Assisted Clinical Simulation: System Design and Formal Verification

SYNTAX Engineering · Truffaire Private Limited, Bengaluru, India

Correspondence: hello@truffaire.in · Version 1.0 · 23 July 2026

1. Introduction

Medical curricula built around competency rather than recall — in India, the National Medical Commission's CBME framework — require students to rehearse clinical reasoning under supervision before they perform it on a patient. Simulated patients have long served this purpose; what has changed is that a growing share of them are now driven by large language models, which converse fluently, respond to unscripted questions, and scale far beyond what standardised-patient programmes can staff ^[7][8][9].

That scale comes with a cost the field has already identified. When the same model that plays the patient — or a separate model layered on top — also decides the grade, the result cannot presently be standardised, and a 2025 review concludes plainly that such systems are “unlikely to be used as part of summative clinical examinations” ^[1]. Separately, transparency about how an AI system reached a given output is inconsistent across medical AI generally: a bibliometric study finds AI-use disclosure in medical education journals often “more performative than informative” ^[4], and an audit of FDA-reviewed AI/ML medical devices found that only 1.8% report the source of their training data ^[5]. A conceptual architecture for provenance-tracked, auditable clinical AI has been described in the decision-support literature ^[6], but, to our knowledge, not shipped in a learner-assessment product.

This paper makes three contributions. First, we give a formal definition of the provenance model SYNTAX uses to label every judgement in a clinical encounter report (§3). Second, we specify five invariants that follow from that model, implement them as a build-enforced test suite, and validate that the suite is not vacuous by mutation testing — deliberately breaking the invariant in the source and confirming the tests catch it (§4). Third, we report a structured review of six systems operating in adjacent categories and find that none, as far as we can establish, implements an equivalent combination of per-judgement provenance labelling and independent verifiability (§5). We then state directly what this does not prove, and what would be required to strengthen it (§7, §8).

2. Related work

2.1 LLM-driven virtual patients

Cornell, Weill Cornell Medicine, Yale, and UCSF jointly developed MedSimAI, an LLM-based virtual patient offering text and voice conversation modes approximating a telehealth visit ^[7]. Oxford Medical Simulation ships voice-controlled virtual patients within a broader VR simulation product ^[8], and Geeky Medics' SimChat offers AI virtual patients for communication practice ^[9]. A 2026 systematic review of LLM-based virtual-patient systems for history-taking maps forty studies in this space between 2023 and 2025, and finds the category converging on conversational fidelity, with assessment methodology as an open problem ^[2]. A related account in Communications Medicine describes LLM-agent-based simulated patients as offering “potential for transforming medical education,” framing rigorous evaluation as future work rather than a solved problem ^[3].

2.2 Grading, standardisation, and disclosure

The limitation motivating this paper is stated directly in the literature: LLM-driven virtual-patient training is, at present, “unlikely to be used as part of summative clinical examinations” because its grading cannot be standardised to the degree a licensing or academic assessment requires ^[1]. Where AI involvement in an educational artefact is disclosed at all, a bibliometric review finds the disclosure typically names the tool without describing what it did to the artefact, and characterises the practice as “more performative than informative” ^[4]. Outside education, an audit of FDA-reviewed AI/ML medical devices found that only 1.8% disclose the source of their training data and only 3.6% their testing data source ^[5]— evidence that provenance disclosure is uncommon even where regulatory stakes are highest.

2.3 Auditable and verifiable AI architectures

A framework integrating retrieval-augmented clinical decision support with explicit data provenance and a tamper-evident audit log has been proposed for clinical AI decision support, recording which data and references informed a given output ^[6]. The framework is presented as conceptual; we are not aware of a published account of an equivalent architecture implemented and shipped for learner assessment, which is the gap this paper addresses.

2.4 Verifiable credentials

Separately, credential-verification platforms such as Sertifier issue tamper-evident certificates with a public verification URL ^[10]. These systems verify that a certificate of completion was issued by an institution; they do not attest to the content of a clinical encounter or to how any judgement within it was produced. §5 treats this as a distinct category from the one this paper addresses.

3. System design

This section specifies the provenance model formally, then describes the two subsystems that make it possible: a scoring engine that has no path by which a language model can influence a grade, and a public verification endpoint.

3.1 The provenance type

Every judgement reported to a student is a tuple (name, score, provenance) where provenance ∈ P = {measured, derived, ai}, with the following meaning:

• measured — the value is a direct output of the deterministic scoring engine (§3.2) against the student's recorded actions. No language model participates in its computation.
• derived — the value is a closed-form function of one or more measured values (e.g. an average across domains). Still model-free.
• ai — the value is an estimate produced by a language model from the encounter transcript. In the current system this applies to exactly two domains, Communication and Professionalism, for which no rule-based signal exists.

The graded total is defined as overall = round( mean( { d.score : d ∈ domains, d.provenance = measured } ) ). By construction, no derived or ai value is a term in this sum. §4 verifies this holds in the shipped implementation, under adversarial input.

3.2 Deterministic scoring engine

Encounters are scored against a fixed rubric spanning five clinical domains — history, examination, investigations, diagnosis, and management — each carrying a fixed point allocation and an explicit criteria list checked against the recorded transcript and action log. The scoring function is pure: for a given encounter recording, it is deterministic and idempotent, and its implementation contains no network call, so its output cannot vary with an external service's availability, latency, or model version. §4.4 reports the direct test of this property against the shipped source.

3.3 Verification endpoint

Each finalised report is issued a public identifier resolvable at /verify/[reportId], requiring no authentication. The endpoint returns certificate-level fields only — student name, institution, specialty, case, overall score, generation timestamp, scoring engine version, and guideline corpus version — and never the case answer, the transcript, or the domain-level breakdown, so verification cannot be used to reconstruct the assessment content itself. The engine and guideline corpus version fields allow a verifier to establish which rule set was in force when a given score was produced.

4. Formal verification methodology

Rather than assert that §3's properties hold, we specify them as machine-checked invariants that run on every change to the codebase and block release on failure. This section states the invariants formally, describes how they are tested, and reports a fault-injection exercise establishing that the test suite actually discriminates a violation from a pass — the standard objection to any self-reported test result being that a suite which always passes proves nothing.

4.1 Invariant specification

Let D be the set of domains in a competency framework and provenance : D → P. We specify:

1. I1 (closure). ∀ d ∈ D, provenance(d) ∈ {measured, derived, ai} — no domain may carry an undeclared provenance value.
2. I2 (fidelity). For every d with provenance(d) = measured, d.score equals the scoring engine's output for that domain exactly — no smoothing, clipping, or blending is applied between the engine and the report.
3. I3 (AI non-interference). The overall score is invariant under any value substituted for an ai-labelled domain, including values outside the valid range.
4. I4 (compositional purity). overall is invariant under any value substituted for a derived-labelled domain.
5. I5 (label-set stability). The set {d ∈ D : provenance(d) = ai} equals a fixed, named set (currently {Communication, Professionalism}). A change to this set requires an explicit, reviewed edit to the test, so a routing change that lets a model influence a new domain cannot land silently.

A sixth property is checked independently of the domain model: I6 (determinism). the scoring engine's source contains no invocation of a network primitive, verified by static inspection of the compiled function source at test time rather than by runtime mocking, which could be defeated by an implementation that only calls out under production configuration.

4.2 Test implementation

I1–I6 are implemented as a Vitest suite (convex/provenance.test.ts) that runs on every commit as part of continuous integration and gates deployment. I3 and I4 are tested by substitution, including hostile out-of-range input (e.g. a communication estimate of −9999) to confirm the invariant holds beyond the domain a well-behaved model would produce.

4.3 Discriminative validity: mutation testing

A test suite that reports success is only informative if it is capable of reporting failure. We evaluated this directly by fault injection: a single line in the competency-assembly function — provenance === "measured" — was changed to provenance !== "derived", which folds ai-labelled domains into the graded average — precisely the failure mode I3 and I4 exist to catch. The suite was re-run against the mutated source.

4.4 Results

All six invariants held against the production source at time of writing, and the suite was shown by fault injection (§4.3) to fail precisely and only when the underlying property is actually violated. This does not establish the properties will hold under all future changes — only that a violation, should one be introduced, is caught before release rather than after.

5. Comparative analysis

We reviewed six publicly documented systems in categories adjacent to SYNTAX — AI-driven virtual-patient simulators and credential-verification platforms — against two criteria: whether individual judgements in an assessment output are labelled by provenance, and whether an independent third party can verify a specific record without an account. Systems were identified through the literature reviewed in §2 and general web search; the review is not exhaustive (see §7).

The credential-verification category is the closest analogue on the verification axis, but certifies that an institution issued a credential of completion — not the content of a clinical encounter, and not how any individual judgement inside it was produced. No system reviewed combines per-judgement provenance labelling with record-level independent verification.

6. Discussion

The literature reviewed in §2 converges on a single practical requirement for AI-assisted simulation to be usable in summative assessment: an institution adopting it must be able to state, for any given score, exactly which parts were computed by rule and which by a model, and must be able to defend that computation to an external examiner. A system that reports only an aggregate score cannot make that distinction after the fact — the information is discarded at generation time. The provenance model in §3 keeps it, structurally, for every judgement in every report.

This has a direct procurement implication. An institution cannot verify a vendor's internal claim that “the score is computed by logic, not a language model” without either auditing the vendor's source or trusting the vendor's word. §4 replaces that trust relationship with a falsifiable one: the invariants are stated formally, the test suite that checks them is described precisely enough to be reproduced, and §4.3 demonstrates the suite is not vacuous. A reviewing institution is not asked to take the claim on faith; it is told exactly what to check.

We note that determinism and provenance labelling are necessary conditions for defensible summative use, not sufficient ones. Rubric design, content validity of the case library, and inter-rater agreement with human examiners on the same cases are separate questions this paper does not address, and are natural targets for the studies proposed in §8.

7. Limitations

1. The priority claim cannot be exhaustively verified. “First” asserts a global negative — that no equivalent system exists anywhere — which no literature review or web search can establish exhaustively. §2 and §5 report a good-faith, dated review that found no counterexample; that is evidence, not proof. We commit to correcting this document if a counterexample is identified, and to re-running the review at least every six months, since a priority claim decays as the field moves.
2. No human-subjects study has been conducted. Nothing in §4 measures whether provenance labelling changes a student's or an examiner's trust, comprehension, or downstream learning outcomes. §8 proposes, without conducting, a study design for this question.
3. Two of fourteen competency domains remain AI-estimated by necessity. Communication and Professionalism have no rule-based signal in the current system and are explicitly excluded from the graded total (I3) rather than measured. This is disclosed, not resolved — a future rule-based proxy for either domain would need the same invariant treatment given in §4 before being reclassified.
4. The comparative review in §5 is not exhaustive. It covers six systems identified through literature search and is limited to what each system's public documentation discloses; an undisclosed internal capability at any reviewed vendor would not be visible to this method.
5. The invariants in §4 constrain the current codebase, not all future versions of it. The test suite blocks a regression from being deployed; it cannot retroactively verify code that predates it, and a change to the test itself is possible in principle, which is why §4.3's mutation-testing result — and not the mere presence of the tests — is offered as the substantive evidence.

8. Proposed future work

8.1 Study 1 — Provenance labelling and assessor trust

Objective. Determine whether per-judgement provenance labelling changes a clinical faculty assessor's stated trust in, and interpretation of, an AI-assisted encounter report, relative to an equivalent report with provenance labels removed.

Proposed design. Within-subjects, counterbalanced: faculty assessors at partner institutions review a matched pair of reports for the same encounter, one with provenance labels shown and one with them redacted, order randomised. Primary endpoint: a validated trust instrument administered after each review. Secondary endpoints: time to form a grading decision, and agreement between the assessor's independent judgement and the engine's measured score.

Target enrolment. To be determined by an a-priori power analysis once the primary instrument is selected; institutional ethics approval would be sought prior to any recruitment or data collection.

8.2 Study 2 — Deterministic score and independent examiner agreement

Objective. Estimate the agreement between the deterministic engine score (§3.2) and an independent OSCE-format assessment of the same students on matched case content, as a construct-validity check on the rubric itself — a question distinct from, and complementary to, the provenance claim this paper addresses.

Proposed design. Cross-sectional, single cohort per participating institution: students complete a SYNTAX encounter and a proctored OSCE station on matched clinical content within the same assessment cycle. Planned analysis: intraclass correlation between the two scores, reported alongside a Bland–Altman comparison; pre-registration of the analysis plan prior to data collection.

9. Conclusion

The literature identifies a specific, named gap: LLM-driven clinical simulators cannot presently be used for summative assessment because their grading cannot be standardised or audited, and provenance disclosure for AI-generated educational output is rare even where the underlying architecture has been proposed conceptually. This paper specified the provenance model SYNTAX uses to address that gap, stated the properties it must hold as formal invariants, verified those invariants against the production source, and confirmed by fault injection that the verification is discriminative rather than vacuous. A structured review of six comparable systems found none implementing an equivalent combination of per-judgement provenance labelling and independent, account-free verification. We do not claim this proves no such system exists anywhere; we claim it is the best evidence available to us, that we have stated its limits plainly, and that we will correct this document if the evidence changes.

Declarations

Conflict of interest

This whitepaper is authored and published by Truffaire Private Limited, the commercial developer and operator of SYNTAX. It is not an independent third-party evaluation.

Funding

This work was produced internally by Truffaire Private Limited. No external research funding was sought or received.

Data and code availability

The test specifications summarised in §4.2–§4.3 are excerpted from convex/provenance.test.ts in the SYNTAX production codebase. Individual encounter reports can be independently verified with no authentication at /verify/[reportId]. Full source is proprietary to Truffaire Private Limited and available for institutional due-diligence review on request.

Human subjects

No human-subjects research was conducted for this paper. §8 describes proposed protocols only.

Corrections

Reports of a counterexample to §5, or of an error elsewhere in this document, may be sent to hello@truffaire.in and will be reflected in the next revision.

References

1. [1] Embracing the Future of Medical Education With Large Language Model–Based Virtual Patients: Scoping Review. Journal of Medical Internet Research, 2025. https://www.jmir.org/2025/1/e79091
2. [2] Large Language Model–Based Virtual Patient Systems for History-Taking in Medical Education: Comprehensive Systematic Review. JMIR Medical Informatics, 2026. https://medinform.jmir.org/2026/1/e79039
3. [3] Simulated patient systems powered by large language model-based AI agents offer potential for transforming medical education. Communications Medicine (Nature). https://www.nature.com/articles/s43856-025-01283-x
4. [4] The Presence and Nature of AI-Use Disclosure Statements in Medical Education Journals: A Bibliometric Study. Perspectives on Medical Education. https://pmejournal.org/articles/10.5334/pme.2431
5. [5] Evaluating transparency in AI/ML model characteristics for FDA-reviewed medical devices. npj Digital Medicine, 2025. https://www.nature.com/articles/s41746-025-02052-9
6. [6] An auditable and source-verified framework for clinical AI decision support: integrating retrieval-augmented generation with data provenance. https://pmc.ncbi.nlm.nih.gov/articles/PMC12913532/
7. [7] Medical students use AI to practice communication skills. Cornell Bowers College of Computing and Information Science. https://infosci.cornell.edu/news-stories/medical-students-use-ai-practice-communication-skills
8. [8] Using Your Voice: Communicating with Virtual Patients. Oxford Medical Simulation. https://oxfordmedicalsimulation.com/using-your-voice-communicating-with-virtual-patients/
9. [9] Simulation with AI Virtual Patients | SimChat. Geeky Medics. https://geekymedics.com/simulation-with-ai-virtual-patients/
10. [10] Digital Badges and Certificates Software. Sertifier. https://sertifier.com/
11. [11] Clinical Simulation Platform for Medical Students & Educators. ClinicalBridge. https://clinicalbridge.ai/
12. [12] AI-Powered E-CBME Software & NMC CBME Platform for Medical Colleges in India. EdMedAI. https://edmedai.in/