Why English? | Reporting REFINE Foundation and Large Language Model Research Through Model Versions, Prompts, Stochasticity, Evaluation and Governance

REFINE foundation-model and large-language-model reporting matters because a familiar model name is not a complete method. People searching for LLM research reporting, prompt reproducibility, medical AI evaluation or foundation-model governance need dates, versions, prompts, datasets, generation settings, output-selection rules, failure analysis and intended-use boundaries.

The primary REFINE publication record, published online on 26 February 2026 and checked on 5 November 2026, reports a 44-item framework across six sections. The official interactive REFINE checklist covers model specification, prompt design, stochasticity control, dataset characteristics, output evaluation and implementation. The EQUATOR record confirms that it is a whole-report guideline for foundation and large language models in medical research.

English is valuable because terms such as version, pretraining, fine-tuning, prompt, testing, memory, hallucination and clinical utility do different jobs. This article turns those differences into a practical reading route for students, parents and future professionals. It is educational information, not medical advice or deployment approval.

Connect this guide to eduKate’s CONSORT-AI trial-reporting guide, TRIPOD+AI prediction-model guide and the SETC English library for claims, evidence and academic reading.

---

Identify the Foundation or Large Language Model Study

State the medical research task, study design and model-centred contribution clearly.

What REFINE asks readers to locate

REFINE is a 44-item, six-section consensus framework for reporting foundation-model and large-language-model studies in medical research. For identify the foundation or large language model study, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For identify the foundation or large language model study, a team studies a hosted model but reports only a brand name; another team could receive a different model build months later, so the result is not reproducible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under identify the foundation or large language model study, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Reporting completeness is not proof of methodological quality, clinical usefulness, safety, fairness or regulatory approval.

Practical action for students, parents and future professionals

For identify the foundation or large language model study, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Record Model Identity and Dates

Name developer, version, release, access and knowledge-cutoff dates where available.

What REFINE asks readers to locate

Its six sections cover model specification, prompt design, stochasticity control, dataset characteristics, output evaluation and implementation. For record model identity and dates, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For record model identity and dates, researchers revise prompts after inspecting test failures; unless prompt development and test evaluation are separated, the final score can contain hidden optimisation. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under record model identity and dates, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A proprietary system may prevent full disclosure; the limitation should be named rather than filled with guesses.

Practical action for students, parents and future professionals

For record model identity and dates, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Describe Architecture and Modalities

Explain relevant architecture, text or image inputs, outputs and technical constraints.

What REFINE asks readers to locate

The checklist asks for model name, developer, version or API identifier, release date and a training or knowledge-cutoff date when available. For describe architecture and modalities, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For describe architecture and modalities, one prompt is run five times and the best answer is selected, but the paper reports a single attempt; selection makes the observed output look more stable than use really is. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under describe architecture and modalities, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A model card or vendor claim is useful context but does not replace study-specific methods and observations.

Practical action for students, parents and future professionals

For describe architecture and modalities, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Separate Pretraining, Post-Training and Inference-Time Adaptation

Show whether weights changed or prompts, retrieval and tools shaped behaviour at use time.

What REFINE asks readers to locate

Prompt reporting includes development protocol, version history, strategy, format, length, clinical-information source, interaction style and memory policy. For separate pretraining, post-training and inference-time adaptation, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For separate pretraining, post-training and inference-time adaptation, a public benchmark predates the model’s knowledge cutoff and may have appeared in pretraining data; the report treats contamination as a possibility rather than proof. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under separate pretraining, post-training and inference-time adaptation, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Prompt transparency should not disclose private patient information, credentials or protected system details.

Practical action for students, parents and future professionals

For separate pretraining, post-training and inference-time adaptation, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Report Language Capabilities and Limits

Name evaluated languages, domain specialisation and untested language claims.

What REFINE asks readers to locate

Stochastic output requires generation settings, prompt-operator characteristics, attempt counts and a rule for selecting the output that is evaluated. For report language capabilities and limits, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For report language capabilities and limits, human evaluators rate clinical usefulness, yet their specialty, experience and agreement are omitted; readers cannot judge what the rating represents. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under report language capabilities and limits, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Repeated generation can estimate variability under stated conditions without proving stability after a vendor update.

Practical action for students, parents and future professionals

For report language capabilities and limits, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Report Compute and Access Conditions

Describe hardware, hosted services, runtime and access constraints relevant to reproduction.

What REFINE asks readers to locate

Dataset reporting includes origin, prior use, real or synthetic composition, representation, processing, missingness and separation of development from testing. For report compute and access conditions, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For report compute and access conditions, average performance is strong while an under-represented language group receives more omissions; subgroup denominators and uncertainty keep the disparity visible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under report compute and access conditions, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Subgroup comparisons need adequate samples and context; small differences should not be converted into identity claims.

Practical action for students, parents and future professionals

For report compute and access conditions, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Version the Prompt-Engineering Process

Preserve contributors, datasets, success criteria, iterations and prompt history.

What REFINE asks readers to locate

Output evaluation includes human reviewers, reliability, uncertainty, subgroup performance, failure analysis, reproducibility limits and clinically relevant benchmarks. For version the prompt-engineering process, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For version the prompt-engineering process, a retrieval system changes both the model’s information and its provenance; the report describes retrieved sources, update dates and failure routes separately from the model. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under version the prompt-engineering process, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Clinical deployment requires governance beyond a reporting checklist, including applicable ethics, privacy, security and professional responsibility.

Practical action for students, parents and future professionals

For version the prompt-engineering process, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Describe Prompt Strategy and Content

Report zero-shot, few-shot, structured, multimodal or other formats without exposing private data.

What REFINE asks readers to locate

Implementation reporting covers intended use, workflow, measured utility, non-use cases, safety monitoring, privacy, governance and auditability. For describe prompt strategy and content, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For describe prompt strategy and content, a school team borrows the method by recording an AI tutor’s version, prompt, attempts, source materials, output rule and known non-use cases before comparing answers. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under describe prompt strategy and content, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Transfer to education means transferring the audit habit, not assuming a medical framework fits every classroom decision unchanged.

Practical action for students, parents and future professionals

For describe prompt strategy and content, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Describe Retrieval, Tools and External Sources

Trace what the model could consult and when those sources were updated.

What REFINE asks readers to locate

REFINE is a 44-item, six-section consensus framework for reporting foundation-model and large-language-model studies in medical research. For describe retrieval, tools and external sources, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For describe retrieval, tools and external sources, a team studies a hosted model but reports only a brand name; another team could receive a different model build months later, so the result is not reproducible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under describe retrieval, tools and external sources, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Reporting completeness is not proof of methodological quality, clinical usefulness, safety, fairness or regulatory approval.

Practical action for students, parents and future professionals

For describe retrieval, tools and external sources, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

State Interaction Style and Memory Policy

Distinguish one-shot from multi-turn use and session from persistent memory.

What REFINE asks readers to locate

Its six sections cover model specification, prompt design, stochasticity control, dataset characteristics, output evaluation and implementation. For state interaction style and memory policy, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For state interaction style and memory policy, researchers revise prompts after inspecting test failures; unless prompt development and test evaluation are separated, the final score can contain hidden optimisation. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under state interaction style and memory policy, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A proprietary system may prevent full disclosure; the limitation should be named rather than filled with guesses.

Practical action for students, parents and future professionals

For state interaction style and memory policy, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Explain Output Controls and Schemas

Report prompt-only, generation-time and post-generation constraints.

What REFINE asks readers to locate

The checklist asks for model name, developer, version or API identifier, release date and a training or knowledge-cutoff date when available. For explain output controls and schemas, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For explain output controls and schemas, one prompt is run five times and the best answer is selected, but the paper reports a single attempt; selection makes the observed output look more stable than use really is. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under explain output controls and schemas, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A model card or vendor claim is useful context but does not replace study-specific methods and observations.

Practical action for students, parents and future professionals

For explain output controls and schemas, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Report Generation Parameters

Include temperature, sampling, token limits, seeds and relevant image settings.

What REFINE asks readers to locate

Prompt reporting includes development protocol, version history, strategy, format, length, clinical-information source, interaction style and memory policy. For report generation parameters, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For report generation parameters, a public benchmark predates the model’s knowledge cutoff and may have appeared in pretraining data; the report treats contamination as a possibility rather than proof. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under report generation parameters, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Prompt transparency should not disclose private patient information, credentials or protected system details.

Practical action for students, parents and future professionals

For report generation parameters, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Name Prompt Operators and Attempt Counts

Describe who interacted, their expertise and how many generations were tried.

What REFINE asks readers to locate

Stochastic output requires generation settings, prompt-operator characteristics, attempt counts and a rule for selecting the output that is evaluated. For name prompt operators and attempt counts, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For name prompt operators and attempt counts, human evaluators rate clinical usefulness, yet their specialty, experience and agreement are omitted; readers cannot judge what the rating represents. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under name prompt operators and attempt counts, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Repeated generation can estimate variability under stated conditions without proving stability after a vendor update.

Practical action for students, parents and future professionals

For name prompt operators and attempt counts, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Prespecify Output Selection

Explain whether first, best, majority, adjudicated or all outputs were analysed.

What REFINE asks readers to locate

Dataset reporting includes origin, prior use, real or synthetic composition, representation, processing, missingness and separation of development from testing. For prespecify output selection, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For prespecify output selection, average performance is strong while an under-represented language group receives more omissions; subgroup denominators and uncertainty keep the disparity visible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under prespecify output selection, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Subgroup comparisons need adequate samples and context; small differences should not be converted into identity claims.

Practical action for students, parents and future professionals

For prespecify output selection, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Describe Dataset Origin and Ethics

Report sites, dates, approvals, consent or waiver and governance.

What REFINE asks readers to locate

Output evaluation includes human reviewers, reliability, uncertainty, subgroup performance, failure analysis, reproducibility limits and clinically relevant benchmarks. For describe dataset origin and ethics, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For describe dataset origin and ethics, a retrieval system changes both the model’s information and its provenance; the report describes retrieved sources, update dates and failure routes separately from the model. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under describe dataset origin and ethics, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Clinical deployment requires governance beyond a reporting checklist, including applicable ethics, privacy, security and professional responsibility.

Practical action for students, parents and future professionals

For describe dataset origin and ethics, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Examine Prior Dataset Use and Contamination

Relate public-release dates and prior use to the model’s possible training exposure.

What REFINE asks readers to locate

Implementation reporting covers intended use, workflow, measured utility, non-use cases, safety monitoring, privacy, governance and auditability. For examine prior dataset use and contamination, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For examine prior dataset use and contamination, a school team borrows the method by recording an AI tutor’s version, prompt, attempts, source materials, output rule and known non-use cases before comparing answers. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under examine prior dataset use and contamination, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Transfer to education means transferring the audit habit, not assuming a medical framework fits every classroom decision unchanged.

Practical action for students, parents and future professionals

For examine prior dataset use and contamination, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Describe Real and Synthetic Data

Report generation methods, proportions and purposes of synthetic material.

What REFINE asks readers to locate

REFINE is a 44-item, six-section consensus framework for reporting foundation-model and large-language-model studies in medical research. For describe real and synthetic data, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For describe real and synthetic data, a team studies a hosted model but reports only a brand name; another team could receive a different model build months later, so the result is not reproducible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under describe real and synthetic data, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Reporting completeness is not proof of methodological quality, clinical usefulness, safety, fairness or regulatory approval.

Practical action for students, parents and future professionals

For describe real and synthetic data, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Analyse Representation and Missingness

Show sample composition, under-representation, missing-data mechanisms and handling.

What REFINE asks readers to locate

Its six sections cover model specification, prompt design, stochasticity control, dataset characteristics, output evaluation and implementation. For analyse representation and missingness, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For analyse representation and missingness, researchers revise prompts after inspecting test failures; unless prompt development and test evaluation are separated, the final score can contain hidden optimisation. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under analyse representation and missingness, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A proprietary system may prevent full disclosure; the limitation should be named rather than filled with guesses.

Practical action for students, parents and future professionals

For analyse representation and missingness, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Protect Separation of Development and Testing

Keep prompt optimisation, fine-tuning, internal testing and external testing independent.

What REFINE asks readers to locate

The checklist asks for model name, developer, version or API identifier, release date and a training or knowledge-cutoff date when available. For protect separation of development and testing, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For protect separation of development and testing, one prompt is run five times and the best answer is selected, but the paper reports a single attempt; selection makes the observed output look more stable than use really is. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under protect separation of development and testing, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. A model card or vendor claim is useful context but does not replace study-specific methods and observations.

Practical action for students, parents and future professionals

For protect separation of development and testing, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Evaluate Outputs With Appropriate Measures

Connect human ratings, task metrics, uncertainty and clinical benchmarks.

What REFINE asks readers to locate

Prompt reporting includes development protocol, version history, strategy, format, length, clinical-information source, interaction style and memory policy. For evaluate outputs with appropriate measures, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For evaluate outputs with appropriate measures, a public benchmark predates the model’s knowledge cutoff and may have appeared in pretraining data; the report treats contamination as a possibility rather than proof. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under evaluate outputs with appropriate measures, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Prompt transparency should not disclose private patient information, credentials or protected system details.

Practical action for students, parents and future professionals

For evaluate outputs with appropriate measures, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Report Failures, Bias and Stochasticity

Classify errors, subgroup differences and repeated-generation variation.

What REFINE asks readers to locate

Stochastic output requires generation settings, prompt-operator characteristics, attempt counts and a rule for selecting the output that is evaluated. For report failures, bias and stochasticity, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For report failures, bias and stochasticity, human evaluators rate clinical usefulness, yet their specialty, experience and agreement are omitted; readers cannot judge what the rating represents. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under report failures, bias and stochasticity, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Repeated generation can estimate variability under stated conditions without proving stability after a vendor update.

Practical action for students, parents and future professionals

For report failures, bias and stochasticity, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Define Intended Use, Non-Use and Governance

State workflow, users, utility, safety, privacy, auditability and oversight.

What REFINE asks readers to locate

Dataset reporting includes origin, prior use, real or synthetic composition, representation, processing, missingness and separation of development from testing. For define intended use, non-use and governance, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For define intended use, non-use and governance, average performance is strong while an under-represented language group receives more omissions; subgroup denominators and uncertainty keep the disparity visible. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under define intended use, non-use and governance, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Subgroup comparisons need adequate samples and context; small differences should not be converted into identity claims.

Practical action for students, parents and future professionals

For define intended use, non-use and governance, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Did You Know? The Same Prompt Can Produce Different Answers

Explain why generation settings, model updates and output selection matter.

What REFINE asks readers to locate

Output evaluation includes human reviewers, reliability, uncertainty, subgroup performance, failure analysis, reproducibility limits and clinically relevant benchmarks. For did you know? the same prompt can produce different answers, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For did you know? the same prompt can produce different answers, a retrieval system changes both the model’s information and its provenance; the report describes retrieved sources, update dates and failure routes separately from the model. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under did you know? the same prompt can produce different answers, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Clinical deployment requires governance beyond a reporting checklist, including applicable ethics, privacy, security and professional responsibility.

Practical action for students, parents and future professionals

For did you know? the same prompt can produce different answers, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Finish With a REFINE Audit

Check all six sections and preserve every important unknown as an explicit limitation.

What REFINE asks readers to locate

Implementation reporting covers intended use, workflow, measured utility, non-use cases, safety monitoring, privacy, governance and auditability. For finish with a refine audit, write the method as a chain that another reader can reconstruct: model identity, prompt or adaptation, data, generation conditions, evaluation, user and intended action. Words such as tested, aligned, validated and safe should be attached to an observable procedure rather than used as free-standing approval labels.

Worked foundation-model example

For finish with a refine audit, a school team borrows the method by recording an AI tutor’s version, prompt, attempts, source materials, output rule and known non-use cases before comparing answers. Separate facts supplied by the authors from facts supplied by a vendor, and separate both from the reader’s inference. Then record dates. A model name can remain familiar while weights, safety layers, context limits, retrieval sources or API behaviour change.

Reproducibility, failure and safety boundary

Ask whether the same inputs under the same stated conditions can be repeated, whether variation was measured and how failures were classified. Under finish with a refine audit, describe hallucination, omission, bias-related error, formatting failure and clinically unsafe output as different categories. Name their denominators and consequences instead of combining them into one vague error rate. Transfer to education means transferring the audit habit, not assuming a medical framework fits every classroom decision unchanged.

Practical action for students, parents and future professionals

For finish with a refine audit, create a six-column note: model, prompt, data, randomness, evaluation and implementation. Under each heading, record what is known, what is missing and what would change the decision. A student can use it for research claims; a future professional can preserve version, provenance and accountability.

---

Frequently Asked Questions

What is REFINE?

REFINE is a 2026 consensus reporting checklist for foundation-model and large-language-model studies in medical research.

How many items and sections does it have?

The primary publication reports 44 items in six sections.

Why report the exact model version?

Hosted and proprietary models can change while retaining a familiar product name, so dates and identifiers help readers know what was evaluated.

Why does stochasticity matter?

The same prompt can produce different outputs. Generation settings, attempt counts and selection rules affect the evidence.

Does REFINE prove a model is safe?

No. It supports complete reporting. Safety, fairness, clinical value and governance still require appropriate evidence and oversight.

Can students use REFINE outside medicine?

They can transfer its audit habits—version, prompt, data, variability, evaluation and limits—while adapting ethics and evidence to their own domain.

---

Useful Next Reading

• Use the official REFINE checklist.
• Read the primary REFINE publication record.
• Connect model reporting to CONSORT-AI trials.
• Continue with the SETC English learning library.

Closing thought: REFINE shows the practical value of English: it turns a changing model and a variable conversation into a dated, inspectable account of what was tested, how and within which limits.