A Two-Axis Record of License and Provenance for Biomedical Datasets: Schema, Adjudication Rules, and Evidence Requirements

1. Background and problem

Reusing a dataset for model training or evaluation raises a licensing question that is hard to answer from a single place. In practice the relevant text is in several locations:

• a LICENSE file in a code repository, which may cover code only;
• license metadata on a hosting platform's dataset card;
• a README or data statement that may add restrictions ("research use only");
• a paper;
• the terms of the upstream datasets from which the data was derived;
• third-party mirrors, which repeat or alter any of the above.

These sources can be inconsistent. A large audit of text datasets by the Data Provenance Initiative reports frequent miscategorisation of licenses on widely used hosting sites, with license information missing in a large share of cases [4]. That audit concerns general text data; we make no claim that medical datasets differ.

Existing documentation frameworks (Section 8) ask authors to describe a dataset. They do not, as far as we could determine, require that each license claim be backed by quoted source text with a date, nor do they separate "what the license says" from "what a downstream user or a catalogue operator may do". The method below addresses that narrow gap. It is not a replacement for legal advice, and the card states this explicitly.

2. Card design

The card is a JSON document validated against a JSON Schema (draft 2020-12). The field reference is schema/README.md; the schema is schema/dataset-card.schema.json. The license-related design has six parts.

Two status axes.

hosting is not free text. It follows from the status, the source-risk flags and the sign-off: conflict, unstated and unverifiable give pending; restricted, or any risk flag, gives link-only; permissive with no flag gives eligible, and hosted only with a recorded human sign-off. The validator rejects any card whose hosting does not follow (validation rule 3). At the data version of this report no card is hosted or eligible: all 12 permissive cards carry at least one risk flag and are therefore link-only.

Evidence as quoted text. Each license statement is an entry with a location (for example repo-license, readme, hf-card-metadata, paper, site-policy, upstream-terms), a verbatim excerpt, a URL, a snapshot_id, the date verified, how it was observed (page, search-snippet, secondary-source, not-opened), and a secondhand flag. Second-hand evidence (no URL, only a search snippet, or a third-party mirror) cannot alone support permissive or restricted.

Source-risk flags. Independently of the license, a card can carry exam-derived, scraped, real-patient-text, model-generated, derived or unknown-provenance. A permissive license on content whose own provenance is doubtful is not a clean bill; the flags keep that visible, and they move a permissive dataset from eligible to link-only.

Repository license versus data license. A card has a separate repo_license object. A repository license counts as a data license only when the repository holds data only (data_only, backed by a snapshot) or the documentation says the license covers the data. Otherwise the card records the repository license, and the data status is unstated. A badge in a README that points to a LICENSE file not found in the snapshot is recorded as badge-only and verified: false.

Parts, conditions and custom licenses. When the publisher states different licenses for different parts, the card records each in license_parts, flags a separable restricted part with has_restricted_parts, and requires the public summary sentence to mention it. License conditions are a controlled list (attribution, share-alike, no-derivatives, notice-required, territory-dependent, registration-required). Datasets labelled with a model license or another custom license are flagged custom_license and given a LicenseRef- identifier.

Identifiers. Identifiers follow the SPDX License List [5]; when the status is conflict, unstated or unverifiable the identifier is NOASSERTION. A map of 84 identifiers (schema/license-map.json) assigns each to one of five classes (permissive, permissive with conditions, restricted, manual review, treated as no statement); identifiers absent from the map go to manual review.

3. Adjudication policy

The overall principle is restrictions are read broadly, permissions narrowly. A permissive verdict needs an explicit statement about the data. A restrictive sentence in the publisher's official notice counts for the data even if it is worded for the whole project. The reason given in the project's rules is that the two errors have unequal cost: calling a restricted dataset permissive is the error to avoid most. Statements explicitly about model weights or code do not extend to the data but are quoted in the card's known issues. conflict is reserved for a publisher contradicting itself about the same object; different licences for different parts are not a conflict.

The policy is written as 26 numbered articles (the adjudication section of the card specification), implemented as 39 machine-readable rules (version 2.6) evaluated in a fixed order: capture rules, statement filtering, identifier mapping, parts and conditions, conflict and aggregation, hosting. Table 1 gives each article with the design reason and, where we have a test case, the public statement behind it or a description of the constructed case. Quoted sentences are from page snapshots saved on 2026-11-12 and are checked by scripts/casebook.mjs; they report what the page said at that time. They are not our evaluation of the resource. Implementation details of the rules are not reproduced here.

Table 1. Articles, reasons and test cases. Reasons are the design logic of the rule set; the last column gives the public wording or, for constructed cases, a description.

Two further cases show the restriction rules at work where statements disagree. In case A18 a dataset's hosting-page metadata reads license: apache-2.0 (snapshot s01) while its README states "本项目相关资源仅供学术研究之用，严禁用于商业用途。" (academic research only, commercial use strictly prohibited; snapshot s03); the rules give conflict, spdx NOASSERTION, hosting pending. In case A19 another dataset's metadata reads license: cc-by-4.0 while its card text says it is available under "Creative Commons NonCommercial (CC BY-NC 4.0)"; status conflict. A third case (A16, constructed) shows that an apache-2.0 field next to "For research use only" is conflict rather than permissive, whereas a sentence about design purpose or medical advice (A15) is a usage note and changes nothing.

3.1 Version record of the rule set

Table 1b. Article, rule and case counts are those recorded at each version; 2.3 was observed as a transient state. This report describes version 2.6; the figures were checked against the version-2.6 rule, case and license-map files whose checksums are recorded with the report's scripts (figures/VERSION.json).

4. Capture and machine gates

Evidence is gathered by a capture script that saves page text as numbered snapshots with a hash, time and HTTP status. Failed or refused fetches are recorded and not retried around access controls. The structure of the pipeline is: a model proposes extracted statements from snapshots, deterministic rules decide the status, and scripts verify. The model does not give a verdict.

Three scripts act as gates before publication. (i) The validator (a validation script) enforces the schema and the cross-field rules of schema/README.md: hosting follows from status, repository-only licenses cannot be permissive, share-alike and no-derivatives must appear in the conditions, and so on. (ii) A quote gate checks that every excerpt occurs in the snapshot of its URL after a light normalisation (Unicode NFKC, case folding, unification of quotation marks and dashes, collapsing whitespace); an excerpt that is not found is dropped from the card or sent to review, never kept. (iii) A numbers gate checks that structured size values are readable from the raw size text. Gate results are recorded in a report that Mdexa keeps for each build.

Because the quote gate normalises, "verbatim" has a precise meaning here: the excerpt equals a substring of the snapshot up to those normalisations. We report both measures in Section 5.

5. State of the first-release data (43 cards, statistics of 2026-11-13)

Source: scripts/stats.mjs, run on the card set with public fingerprint ea894e8472bc (the 43 cards of the first-release catalogue, frozen as a read-only version; the catalogue has since grown and later cards are not included. The change logs of these cards were split into a public and an internal layer on 2026-11-13; no determination field changed). The public version is identical field by field to the internal archive, except that the change logs are worded for the public; the internal archive's fingerprint is 9ff1d63a933d. The 43 cards cover Chinese-language medical and traditional-medicine datasets, compiled by the project team with model assistance (converted from an earlier manual catalogue, then filled in and checked); they are not a random sample of any population.

Table 2. Status and hosting of the 43 cards.

Verification level: 23 verified, 10 verified-no-license-statement (the page was read and contains no license statement), 5 partially-verified, 5 unverified. All cards were last verified on 2026-11-12. 33 of 43 cards carry at least one risk flag (scraped 11, exam-derived 9, real-patient-text 9, derived 6, model-generated 6, unknown-provenance 4).

Table 3. Evidence statistics. The two excerpts without a snapshot id are upstream-terms entries that are not machine-checked.

The evidence entries come from 11 location types; the most common are Hugging Face metadata (16), repository license files (12), README text (12) and repository sidebars (7).

Repository license versus data license: 13 cards record a repository license; for 9 of them the data status is not permissive, and for 4 it is unstated. This is the situation Articles 2–3 were written for. Structural features exist in the schema but are lightly used at this data version: no card uses license_parts or license_conditions yet (the 12 permissive cards were not back-filled with conditions such as attribution), two cards are custom_license, one is declared_broader_than_upstream.

The rule system has 26 articles and 39 rules (version 2.6) and 64 adjudication test cases: 24 derived from a pilot batch of candidate datasets, 29 constructed, 11 from existing cards. The offline run of the cases reports 64 of 64 passing. Two of the 64 (A03 and A28) are flagged as having inputs still to be captured and are excluded from the card back-test, not from the case run. Replaying rules 2.6 over the 43 first-release cards agrees with the recorded status and hosting on 43 of 43 cards, with 0 direction errors (a rule more permissive than the card). These cards took part in adjusting the rules over several rounds, so this agreement is not an accuracy estimate. The unseen holdout of human-judged items needs 50 judgements and has 0 so far, so accuracy cannot be reported. All of these numbers are read by scripts/stats.mjs from the acceptance outputs of the build (case run, back-test file, quality file).

6. Limitations

1. Small sample, compiled by the project team. 43 cards in one language area. Proportions in Table 2 describe this set and do not generalise.
2. One team and one process adjudicate. Rules were written by the project team; the verdicts were produced by the same model-assisted process and checked by the same team. No external legal review is recorded in the project files. Verdicts report what sources state and are not legal advice.
3. The back-test is not an accuracy estimate. Rules 2.6 agree with the recorded status and hosting on all 43 first-release cards, but those cards took part in adjusting the rules in several rounds (the first rule version agreed with 37 of the 43, 86.0%, and rules were added for the disagreements), so 100% is not an independent figure. The back-test inputs are converted from card evidence, so it exercises the rule layer and not the extraction. Accuracy on an unseen holdout cannot be reported: none of the 50 required holdout items has been judged by a human yet.
4. No independent cross-vendor review. The second extraction pass used the same model with a different prompt. We do not describe this as independent dual-model review. The review mode is stated as single model plus rules plus audit; the random human audit has no completed sample yet.
5. A small self-check. In a pilot batch, the drafting process's own spot check compared nine drafted cards (about 90 fields) with the saved snapshots and found 8 problems, roughly 91% field accuracy. This was not an independent human review. Factual fields were mostly reliable; risk flags and upstream relations were the most error-prone and are not auto-approved. It is a single small sample.
6. Not every excerpt is machine-checked. 47 entries have an excerpt but only 45 have a snapshot id; the other two are not covered by the gate. Normalised matching is looser than byte equality (Table 3).
7. Snapshots are page text, not live pages, and licenses change. All 43 cards were verified on a single date. A re-verification script exists and flags changed license text, but its latest report covers a single card.
8. Rules were shaped by failures we saw. The pilot exposed nine gaps (for example parts, official site-wide policies, share-alike, territory licenses, custom identifiers), each patched as an article. Further gaps are likely: the map excludes regional ports of Creative Commons licenses, and nine copyleft software licenses used for data still need a human decision.
9. Language. Some excerpts and statements are in Chinese; we translate them for this report and the card keeps the original.

7. Discussion

The main design choice is to make the status axis a description of sources and to confine decisions to the second axis. This lets a reader dispute a hosting decision without disputing a fact, and lets the policy change (for example when a sign-off process starts) without rewriting facts. The second choice, a quoted excerpt with a snapshot and a date for each claim, turns "check the license" into something a script can partly verify and a reader can check in minutes. The cost is effort per dataset and a high share of unverifiable or unstated verdicts where sources are silent or inaccessible; we think reporting "not found" is more useful than guessing. Future work: independent holdout evaluation, a second reviewer from another provider, human capture for pages that refuse scripted access, and wider coverage.

8. Relationship to existing work

• Datasheets for Datasets [1] proposes a question-based document on a dataset's motivation, composition, collection, uses and maintenance. Our card is narrower and machine-readable and focuses on license and provenance claims. The two are complementary; a datasheet's "legal and ethical considerations" section is the place where a card like ours could be cited.
• Data Cards [2] are structured summaries of dataset facts aimed at stakeholders across the lifecycle. They describe dataset documentation broadly; our schema specialises in verifiable license evidence.
• Croissant [3] is a metadata format for ML-ready datasets. Its specification includes a license property on the dataset and recommends using the URL of a known license (for example from the SPDX list). In the specification page we read, we did not find a field recording quoted evidence or a verification date for the license. Our license_status, evidence and hosting fields could be carried alongside such a record; we have not built a Croissant export.
• Hugging Face dataset cards [6] carry a license field in YAML metadata and allow other with a license_name and a LICENSE file. We use these fields as evidence and treat them as a claim by the page author; we did not find a statement in the documentation we read about how the value is verified. Our rule set treats other and unknown as no statement.
• SPDX [5] supplies the license identifiers and the LicenseRef- convention we use for custom and public-domain declarations.
• The Data Provenance Initiative audit [4] measures license information across 1,800+ text datasets at scale. Our work is a per-dataset recording method rather than a population audit; the audit's finding on miscategorisation motivates recording the source text itself.

9. Reproducibility

The scripts that produced this report's tables and figures accompany the report. They read the card files and the snapshot files and write only to this report's figures/ directory.

• node scripts/stats.mjs regenerates figures/stats.json, tables.md, fig1-status.svg and fig2-evidence.svg, and reads the frozen first-release cards after checking the fingerprint of the internal archive (9ff1d63a933d) against its manifest; if the fingerprint differs, the frozen version has been altered and the script stops with an error. Readers can recompute the public version's fingerprint (ea894e8472bc) with the verify script in releases/first-release/ of the public repository. The public version is identical field by field to the internal archive, except that the change logs are worded for the public; the internal archive's fingerprint is 9ff1d63a933d.
• node scripts/figures-zh.mjs draws the Chinese versions of the two figures (fig1-status.zh.svg, fig2-evidence.zh.svg) from the committed figures/stats.json, without recomputing any number.
• The rule figures are frozen to rules 2.6: figures/VERSION.json records the checksums of the rule, case and license-map files they were checked against. If any of these files changes, the check mode of scripts/stats.mjs reports a difference and nothing is rewritten.
• node scripts/casebook.mjs re-checks the 16 quotations and one capture-failure record used in Table 1 and Section 3 against the saved page snapshots.
• Public inputs: the information cards (cards/), the schema (schema/dataset-card.schema.json), the rules (schema/adjudication-rules.json), the license map (schema/license-map.json), the evidence index with snapshot hashes (evidence-index/) and the validator (tools/validate-cards.mjs) are in the public database repository.
• The saved page text of the snapshots, the adjudication test cases and the pipeline and quality reports are kept by Mdexa and are available on request. This report gives aggregate statistics and a few examples; it does not reproduce per-card data.

How to cite

Mdexa Research. A Two-Axis Record of License and Provenance for Biomedical Datasets: Schema, Adjudication Rules, and Evidence Requirements. Technical report, not peer reviewed. 2026-11-13. Data version: first-release catalogue of 43 cards, frozen (public fingerprint ea894e8472bc, released as releases/first-release/ in the public repository; identical field by field to the internal archive, fingerprint 9ff1d63a933d, except that change logs are worded for the public); adjudication rules 2.6; license map 1.1; schema 1.0.