Filing
Evidence-first classification; high confidence routes to a proposal, never a write.
Custody root is a routing axis alongside confidence.
Open in console →Enter the access password to open the reference applications.
Incorrect password.
The capabilities in today's eTMF-intelligence tools are good, and this bundle keeps almost all of them. What it changes is the substrate: records stay with the custodian who generated them, and intelligence reads across all of them. You do not migrate into a repository. You join a graph, and vendors compete on how well they read it.
A single container was the only implementable answer, until the guideline itself is read as plural custody.
Every eTMF-intelligence product starts from the same assumption: the sponsor's electronic Trial Master File is the system of record, and the software that classifies, checks, and scores records sits on top of it. That assumption was correct for as long as one repository was the only substrate anyone could build on.
The reason the eTMF became strategically central is that it is where a single document lands. ICH E6(R3) is the one text that sponsors, sites, IRBs, CROs, and their vendors all answer to, and regulators across the ICH regions enforce a version of it. The guideline is shared; the systems that serve it are not. So the industry needed one place where compliance with the shared text could be demonstrated to an inspector, and the eTMF became that place. Not because the guideline asked for a container, but because a container was the only way to show that the clauses had been met.
Read closely, the guideline asks for something looser. C.2.3 says essential records are maintained in, or referred to from, repositories held by more than one party. C.2.4 asks each party to keep a record of where its records are. C.2.7 says originals should generally stay with the party that generated them. On that reading the Trial Master File is a view over records held in several places, not a building that holds them.
This bundle encodes the shared text itself. Every addressable clause of ICH E6(R3) becomes a registry row carrying its role, obligation strength, page locator, and record implication, and 77 executable Pathways discharge those clauses on the graph. Because what is encoded is the document everyone already answers to, rather than any single product's data model, a clause reference means the same thing to two vendors, two systems, and two jurisdictions looking at the same trial.
One consequence outlasts the rest. When records stay with their custodians and every read, proposal, and rejection is logged against a clause and a custodian, the substrate accumulates a longitudinal record as a side effect of being used. A trial is already a longitudinal study; this makes the conduct of the trial longitudinally observable as well, and it does so across studies, sponsors, and years rather than inside one vendor's tenancy.
That is what makes an otherwise unanswerable question answerable with evidence: which models, agent harnesses, and reasoning frameworks actually proposed correctly, on which clause, for which custodian, and how often a human rejected the proposal. Adoption and rejection rates are published per check and per vendor instead of being held privately, so the efficacy of automation in trial operations becomes something the ecosystem measures rather than something each contract asserts.
Full premise, clause citations, and economics · the published design this bundle reimagines, credited in full
Everything above is argued as an offering. Everything below is what the bundle actually encodes against ICH E6(R3) on a participant-anchored graph, and it is the layer the rest of the ecosystem would build on.
The graph holds locators and relations, and record bodies stay with their custodians. Seven custody roots (participant, site, sponsor, IRB, manufacturer, shared, commons) appear throughout the reference console, so plural custody is visible rather than inferred.
Because each proposal, grant, and rejection is written against a clause and a custodian, the graph is a longitudinal instrument by construction. The same ledger that shows an inspector where a record lives also shows, across studies and years, which vendor's model was right about which check.
Bundle depth: ruby tools/validate_tsdg.rb ·
offering section on layers and boundary
Each view re-expresses a familiar eTMF-intelligence screen over the graph. They are wired together in the console: start at Readiness (it refuses when a custodian has not answered), then follow how that refusal propagates.
Evidence-first classification; high confidence routes to a proposal, never a write.
Custody root is a routing axis alongside confidence.
Open in console →Expected records derived from the study’s own records, not only a template list.
Locator index coverage is the honest denominator.
Open in console →Catalogue of checks with candidate and agreed states; findings are proposals.
A custodian spends a grant to act on a finding.
Open in console →Discrepancies live between two custodians’ valid records.
A single system of record cannot form this finding.
Open in console →Weighted composite with visible weights, and a refusal when input is missing.
Not a degraded score: the unanswered custodian is named.
Open in console →Vendor conformance and published rejection rates per check.
A high rejection rate is a signal, not a secret.
Open in console →
Open the full Trials SDG console tour →
· synthetic study COMMONS-STUDY-001, six custodians, two initially unresponsive
Same graph, different trade-offs, spelled out in the long-form offering page.
One read surface, cross-custodian findings, and public rejection rates, in exchange for giving up the write and the lock-in.
For a vendor →Better completeness and inspection locators; slower correction; you lose the single confident number when custodians have not answered.
For a sponsor or CRO →Custody root at the person: trial evidence referred from the sponsor’s view, not copied into it by default.
For participants →Capability surface substantially from IntuitionLabs’ published design, re-expressed here with no code reuse. Veeva names are descriptive, not endorsement.
Credit & trademarks →H-CTM0a/b are structurally checked; H-CTM1–5 need a trial. The console shows shape, not confirmation.
Falsifiers & status →