eTMF intelligence on a commons

The premise this inverts

One sentence, taken seriously and then reversed.

This bundle reimagines one specific published design: IntuitionLabs' eTMF Intelligence prototype, credited in detail in Credit below. That design is explicit about where it starts: the sponsor's electronic Trial Master File stays the system of record, and the reasoning layer sits on top of it. Starting there was the correct call. A single repository was the only substrate available, so software that read trial records had to read one party's copies of them.

ICH E6(R3) never asked for one building. It asked for records held by their responsible parties and an index of where they are. The industry built a building because a container was the only implementable answer.

Three clauses say it plainly. C.2.3: essential records "should be maintained in or referred to from repositories," plural, and "referred to from" means a pointer discharges the obligation. C.2.4: each party should maintain a record of where essential records are located. C.2.7: "the original records should generally be retained by the responsible party who generated them." And C.2.3's own phrasing, "these repositories may be referred to as a trial master file," makes the TMF a naming convention applied to a slice, not a defined object with required properties.

The container model

An intelligence layer over one repository

Completeness is a property of what the repository holds
One version of every answer exists, by construction
Changing vendors is a migration project
A participant's records are a copy the sponsor holds
"Available upon request" is satisfied by holding copies in advance
The vendor that owns the repository owns the surface every other vendor reaches through

The graph model

An intelligence layer over plural custody

Completeness is bounded by the fraction of custodians who answered, and says so
Two custodians can disagree, and the disagreement is the finding
Nothing to migrate; the sponsor's view and its grants move, the records do not
A participant's records are the participant's, referred to from the sponsor's view
Availability is a locator handle plus a scoped, revocable, logged grant
No vendor owns the substrate, so every vendor reaches the same surface

The second row is the commercially interesting one. A single system of record holds one version of every answer, so it has nothing to compare against, and it cannot form a cross-custodian contradiction at all. Not slowly, not partially. The eTMF holds consent v2.1, the participant's own record holds v3.0, both records are internally valid and correctly filed, and the problem exists only in the relation between them.

What is actually being offered

A substrate, an encoding of the guideline against it, and a boundary that vendors sit outside.

653

E6(R3) clause nodes

mechanically extracted from the PDF; 515 encoded, 138 registry-only

executable pathways

54 are named by a clause as its encoding; 23 are substrate mechanics no clause asks for

domains, 7 custody roots

51 morphisms, 14 hyperedges, 9 predicted composites

design patterns

17 from IntuitionLabs' design, 4 this bundle's own

The three layers

Layer 0 · the graph Records as nodes with a custody root, a content digest and authorship metadata. The bodies stay with their custodians. A locator index that reports its own coverage.

Layer 1 · the guideline Every addressable ICH E6(R3) clause as a registry row: role, obligation strength, page locator, record implication, disposition. Produced by a tool, not a hand-written list.

Layer 2 · the pathways 77 executable process definitions, each with a privacy floor, an autonomy gate, a register of non-delegable acts, and license terms that survive a fork.

The boundary, which is the whole offering

1. A vendor reads Under a scoped grant naming the party, subset, purpose, period and clause basis. Every resolution is logged and visible to the custodian.

2. A vendor proposes A classification, an extraction, a quality finding, a discrepancy, a readiness signal. With its confidence, its route, and its evidence locator.

3. A vendor stops The substrate holds no key that can file into a participant's, a site's, or an IRB's records. Not a permission that could be granted: no such key exists.

4. The custodian files Under their own key. Non-delegable acts stay non-delegable by key arithmetic rather than by access-control policy someone can misconfigure.

An offering proposes; only the custodian files. This is the constraint every adopted capability had to be re-expressed under, and it is the reason the market can have more than one vendor in it. When writing is a capability the substrate does not have, no vendor can become the substrate.

See the six capabilities working on synthetic data: the Trials SDG console.

For a vendor

You compete on how well you read, and you publish the rate at which you were wrong.

What you get

One surface instead of N integrations. A read grant against a graph rather than a connector per sponsor per platform. The clause registry as a shared vocabulary, so "this discharges C.2.4" means the same thing to you and to your competitor.

And a capability no single-repository product can offer: you can form findings across custodians. Cross-system reconciliation stops being a differentiator you build and becomes a class of finding the substrate makes possible.

What you give up

The write. You never hold the repository, so you never hold the lock-in. A sponsor who prefers a competitor's classifier switches by changing a grant, and there is no migration to make that expensive.

And your rejection rate becomes public. Trial.Ecosystem.PublishAttestation@v1 publishes adopted-versus-rejected per check. A high rate is not a scandal. It is a check whose rule nobody agreed yet, or a model wrong about this study. Not publishing it is the scandal.

Forking is permitted and attribution is not

Every pathway declares license_terms.survives_fork. Trial.Ecosystem.ForkOffering@v1 inherits attribution monotonically: a fork may add attribution requirements and may never narrow one. Take the pathways, change them, ship a better offering. The one thing you cannot do is remove the credit.

For a sponsor or CRO

Read this section as the one most likely to contain a cost you did not agree to.

What gets better

Completeness computed from your own study's records rather than a template list, with a denominator you can dispute. Findings that span custodians. Inspection readiness over a locator index instead of over one repository's contents. Qualification evidence rooted at the person, so one currency check serves every study that references it.

What gets slower

Correction. A data manager cannot edit a participant-rooted record; they raise a query and the custodian resolves it. This is slower and it is more correct. A sponsor-applied correction to someone else's source record, with the sponsor's reason attached, is exactly what E6(R3) 4.2.3's attribution requirement exists to make visible.

What you lose

The single confident number. Completeness now arrives bounded by index coverage, and the readiness composite refuses to compute when a custodian has not answered. If you need one percentage to put in a board pack regardless of what is behind it, this substrate is worse for you, and you are not wrong to notice.

Your accountability does not change at all. Sponsor responsibility under 3.6.7 for assessing service provider suitability, under 3.9.1 for oversight of delegated activities, and under 3.11.4 for monitoring, is untouched. Delegating an activity to a vendor is not delegating responsibility for it, and nothing in this design pretends otherwise. What changes is where records live and how they are reached.

Submission formats are not touched either. Trial.Agreement.SubmitToAuthority@v1 defers entirely to the authority's specification. This bundle has no view on eCTD and proposes no alternative.

For a participant

The part of this that is a promise, and the part that is not.

What this does

Your records root at your health record

Consent, symptom diaries, patient-reported outcomes and source observations are yours; the sponsor's file refers to them
You must acknowledge the anchoring, because a record you do not know about is not sovereignty, it is a sponsor asset with a nicer label
Access is a grant you can see and revoke, and every read is logged
Returning trial results to you becomes a view over the graph rather than a project
Your obligations travel with you when you change institution

What this does not do

Revocation is not deletion, and we will not say otherwise

Withdrawing revokes the grant, not the record. Clause 2.9.1 lets you end participation; C.2.6 and 3.16.3 require retention of what was already collected. The record, its digest, its index entry and its audit trail remain
Revocation is not retroactive. Prior disclosures stand, and the system states this to you at the moment you revoke
Some records must not root with you. The randomisation list stays with the sponsor, because holding it would unblind you
Whether you are the data controller under GDPR, or a covered entity under HIPAA, is unresolved. It is named in the clause registry and not answered
No participant has been consulted about any of this

The economics, and who loses

A page that only describes winners is a page nobody should trust.

Party	Direction	Why
Specialist intelligence vendors	better	One surface instead of N integrations, no platform gatekeeper between them and the records, and a class of cross-custodian finding they could not previously form.
Sites and institutions	better	They stop shipping copies of their own records into someone else's repository, and their expectations name them rather than being tracked on a list they cannot see.
Participants	better, conditionally	Custody and visible grants, if they want them. A design requiring participant engagement has an adoption problem, and this one has never been tested with a participant.
Sponsors and CROs	mixed	Better findings and no migration cost; slower corrections and the loss of the single confident number. Whether that trade is worth it is H-CTM2 and it is untested.
Incumbent single-vendor platforms	worse	The repository stops being the moat. This is the honest cost of the design and it is not dressed up as anything else.
Anyone selling migration projects	worse	There is much less to migrate. Records stay put; views and grants move.

The market mechanism

Published rejection rates per check, per offering. That is the whole mechanism, and it only works because writing is not on offer. When a vendor cannot lock a sponsor in by holding their repository, the only thing left to compete on is whether their proposals get adopted, which is measurable, publishable, and exactly what Trial.Oversight.AdoptRecommendation@v1 records over the life of a study.

Credit, in the place it is most likely to be read

What is theirs

Confidence is a routing signal, not a truth claim, with the threshold set from a labelled sample reflecting the real document mix.
Consequence and confidence are independent axes, so the same score authorises a draft suggestion and forbids a lifecycle advance.
Derived expected documents, computed from a named source and a countable set rather than a generic checklist. The delegation-log-to-CV example is theirs. This is the single idea this bundle borrows most directly.
The candidate check state, in which a check stays candidate until its rule, threshold, exceptions and expected action are agreed with the sponsor. A model detects that a CV is two years old; only the sponsor determines whether that requires replacement. The discipline this bundle admires most, reproduced without modification.
Deterministic and model results are never blended into one score.
The unresolved state is part of the output, so two plausible answers are reported as two, and a hold carries its reason rather than a low number.
Cross-system reconciliation as the differentiating capability, with four named checks: consent version against subject-level events, active site status against filed signature pages, monitoring visit timeliness against committed cadence, and eConsent completions against audit certificates.
Field-level provenance, the weighted readiness composite with visible weights, the named weakest input, remediation ranked by projected score movement, the reason as the interface, integration-user attribution kept separate from human signature, and measuring your own rejection rate.

What is not taken

No code, in any language.
No models, weights, thresholds, or calibration data.
No check definitions or rule catalogues.
No datasets, synthetic or real. COMMONS-STUDY-001 was written from scratch for this bundle.
No interface layouts, components, screenshots, or visual design.
No text beyond short quoted phrases, attributed in place.

What is this bundle's own

Custody root as a field that varies. Availability without possession. Refusing to compute over a view known to be partial. An offering that proposes and never files. The custodian member on a derived expectation. The explicit resolved / explained / open terminal states grounded in C.3.3. Locator index coverage as a third denominator. And the argument that a single system of record cannot form a cross-custodian contradiction at all.

IntuitionLabs was not contacted about this bundle and has not reviewed it. Nothing here should be read as their view. No affiliation, endorsement, partnership, or agreement is claimed or implied. eTMF Intelligence and IntuitionLabs are used nominatively to identify the design being credited. This bundle makes no claim that their offering is wrong; it inverts one assumption their design states explicitly. Any error in characterising their design is this bundle's.

Veeva

Veeva, Vault, Vault eTMF, Vault CRM, X-Pages and TMF Bot are trademarks of Veeva Systems. Nothing in this bundle is a Veeva product, integrates with a Veeva product, or carries Veeva endorsement. Veeva was not contacted. The platform is named only to describe the single-vendor system-of-record architecture this bundle departs from. No criticism of Veeva's products is intended or implied. The container architecture was the right answer to the problem as it stood, and building it well is not a fault.

Reproduced accurately because it is the kind of boundary that gets blurred in retelling: IntuitionLabs' X-Pages partnership is a Vault CRM designation. It is not an eTMF certification, and it does not constitute Veeva endorsement of the solution.

Everyone else

ICH has not reviewed or endorsed anything here; the guideline text is reproduced in the bundle and the argument built on it is ours. HL7 and FHIR are registered trademarks of Health Level Seven International, and CDISC, CDASH, SDTM and ADaM are trademarks of CDISC; neither organisation was consulted and no conformance is claimed. The TMF Reference Model project was not contacted; the zone crosswalk is one reading of a published taxonomy and if the model and the crosswalk disagree, the model is right. The oncology SDG supplies the hypergraph-and-pullback formalism and its domain-expert context is David L. Stark's. Nothing in this clinical-trials bundle is his and he was not consulted about it. Sealed Accord supplies the sealed-disclosure mechanism, whose own reference implementation runs against a stub.

What is not true yet

Two claims are checkable today. Five are not, and one unanswered question gates most of them.

Checked by a validator confirmed

H-CTM0a: every reference in the trial-domain registry resolves; no orphan domains.

H-CTM0b: every one of the 653 mechanically extracted E6(R3) clauses carries a disposition, and every encoded_by reference resolves to a pathway on disk.

Run ruby tools/validate_tsdg.rb. The denominator comes from a tool that reads the PDF, so it cannot be quietly shrunk to make coverage look better. H-CTM0b proves coverage is complete, not that the readings are right.

Untested nothing confirmed

H-CTM1 availability without possession · H-CTM2 cross-custodian contradictions occur often enough to matter · H-CTM3 obligations survive a custody change · H-CTM4 signals-only inspection disclosure · H-CTM5 derived expectations differ materially from templates.

H-CTM1 is load-bearing: if it falls, H-CTM2, H-CTM3 and H-CTM4 fall with it. None has a verification command, because each requires a clinical trial.

The question that gates the rest

No regulatory authority has been asked whether a locator handle plus a scoped grant satisfies P9.5. If availability requires the possibility of full record production rather than a sufficient answer to a question, this design does not comply, and no amount of engineering fixes that. It is not our question to answer and we have not answered it.

Named, and not solved

commons custody has no accountable party. Who is liable when the locator index is wrong? C.2.4 requires the record of location to exist and says nothing about who owns it. This is the most legitimate objection to the whole approach.
Controller and processor status under GDPR and HIPAA is unresolved.
Destruction leaves a tombstone, because a node that stops resolving is otherwise indistinguishable from a custodian who has gone offline. A mitigation, not an answer.
Sealed disclosure signals may be re-identifying at realistic study sizes. There is no noise mechanism, no privacy budget, and no minimum cell size in the design.
Requiring every custodian to authorise a disclosure creates a veto. We chose the guarantee over majority rule and the operational cost is real.
Privacy floors are declarations about behaviour that has never occurred. Every attestation would currently report itself vacuous.
Pathway step logic is unverified. The steps are specifications, not code. Nothing executes them, so nothing can check them. This is the largest gap between what this bundle contains and what it would need to be operational.

If H-CTM1 is falsified, what survives is the clause registry: 653 addressable E6(R3) nodes with role, obligation strength, page locator and record implication, produced mechanically and useful to anyone reasoning about the guideline. That is the floor, and it does not depend on a single custody argument being right.

A sovereign commons, and vendors that plug into it