NIH N3C Data Enclave Sources Sought: What Crosses the Platform Boundary

Date: August 25, 2026 · Author: Dmitrii Zatona  · Updated: September 29, 2026

TL;DR

• An August 2025 NIH sources sought for the N3C Data Enclave platform asks, four items apart, for data exportable in open formats to avoid lock-in and for every resource to be reproducible from exact upstream versions (Sections 1 and 2).
• The notice does not say whether avoiding lock-in covers only the data or the whole reproducible resource, meaning the dependency graph with pinned versions, replay, and branches (Section 2).
• The incumbent’s documentation describes all six elements of that resource inside its platform; the documentation pages reviewed describe exports of data and code, and no serialization of the version graph or branch history (Sections 3 and 4).
• Open specifications cover the six elements one or a few at a time; none surveyed, with independent implementations, carries exact-version graph, replay, branches, and change impact together across systems (Sections 4 and 8).
• The incumbent contract’s ordering period ended on September 27, 2026, with no extension recorded as of September 29, 2026; a new NCATS-funded order for the N3C researcher environment went to the same vendor, and no record calls it the recompetition’s result (Sections 6 and 7).
• No document reviewed says whether anything of the reproducible resource was lost or kept in the 2025 to 2026 platform transition, and the article claims neither outcome (Section 8).

The N3C Data Enclave is the federal research environment that held harmonized clinical records on more than 23 million people as of November 2024, and in August 2025 the National Institutes of Health asked the market, in a sources sought notice, who could run the platform behind it. The notice’s software requirements set two demands four items apart. One is an open architecture whose stated goal is to “avoid system lock-in.” The other is per-resource reproducibility: every dataset, analysis, plot, and report traceable to exact upstream versions and replayable, with prior versions and branches kept. Inside one platform both are deliverable, and the notice names an incumbent whose documentation covers the second in detail.

Whether openness extends to the reproducible resource decides what survives a change of platform, and that is where the open specifications surveyed here run out. Months after the notice closed, a change of platform happened: the enclave paused, reopened on a different cloud provider, and saw its incumbent contract run out, which turned the question from a reading exercise into a record. This article takes the two requirements apart into six elements of a reproducible resource and checks which of them an open specification can carry.

1. What was published

The notice is 75N95025R00046 , “Secure Platforms Support for the N3C Data Enclave,” a Sources Sought notice that the contracting office of the NIH’s National Institute on Drug Abuse posted on SAM.gov on August 8, 2025. It was revised on August 21 and again on August 22, 2025. The first revision added one sentence announcing an extension and moved the response deadline from August 25 to September 2; the second changed the deadline stated in the body text to match. A programmatic diff of the original and final versions shows no requirement added, removed, or reworded. The notice carries no attachments, so its entire content is the description text, and it archived on September 25, 2025.

Responses went to Brian O’Laughlin, Contracting Officer. NIDA’s acquisition office contracts on behalf of NCATS, the NIH center that leads the program; an earlier notice for the same platform says so, and the contract records show NIDA as the contracting office and NCATS as the funding office. The notice invokes FAR 10.002 market research and states what it is not: no commitment to issue a solicitation, and responses “will not be considered as proposals or quotes.”

The notice names its incumbent in the background section: the environment “currently uses Palantir Technologies, Inc’s Foundry platform,” serving NCATS, NCI, PEPFAR, and N3C. In September 2025 the acquisition it belongs to was documented as open. The government’s September 2025 justification for a contract modification states that “NCATS has started the recompetition process for FY26” and names this notice’s ID as the market-research stage. The incumbent contract’s ordering period ran through September 27, 2026, and FPDS recorded no extension as of September 29, 2026. What followed is in Section 6.

This is the third teardown in a series; the previous one, INL Reviewing Smarter RFI: Four Readings of “Every Output Traceable”, read an AI licensing-review requirement for traceable citations four ways.

2. What the requirements say

The notice lists professional-services requirements and thirteen software requirements, and two of the thirteen are the subject here. Requirement 2, in full:

“An open data architecture, where data always remains under the full control of NCATS and other data owners and can be easily exported in open, non-proprietary data formats via open APIs. The software should be built on an open, distributed microservices architecture with well-documented REST APIs and out-of-the-box connectors that are designed to seamlessly interface with other systems, adapt to meet evolving needs, and avoid system lock-in.”

And requirement 6, in full:

“The ability to maintain data and scientific provenance and reproducibility of all integrated data sources. Every resource (dataset, analysis, code, plot, report) contains provenance, metadata, and can be both traced back to the exact version of all upstream dependencies, and where the dependency tree can be easily replayed given new data or updated analysis logic, while still retaining prior versions and branches.”

Requirement 6 is a compact specification of what the National Academies’ 2019 consensus report calls reproducibility, “obtaining consistent results using the same input data; computational steps, methods, and code” (Reproducibility and Replicability in Science, Chapter 3). The requirement extends that definition with version pinning, re-execution under changed inputs, and retained branches. The other requirements circle these two. Requirement 3 closes with a Git repository for data pipelining. Application 10.5 asks that usage of every shared artifact be tracked automatically for attribution. Application 10.6, quoted in Section 4, asks for alerts when vocabulary changes affect existing code sets.

The two requirements concern different objects, and that distinction has to be drawn before they can be evaluated together. Requirement 2’s subject is data: exportable in open, non-proprietary formats and under the control of NCATS and the data owners. Two actors are in play. Researchers inside the enclave work under a regime the notice states plainly, where the data cannot be downloaded or removed, so requirement 2 concerns the custodian’s control and the researcher’s access is a separate matter.

Requirement 6’s subject is the resource. That is the reproducible whole: data, code, the dependency graph with exact versions, the ability to replay, and the branch history. Established open formats can represent much of the first object, subject to the authorized export path: tabular content in Parquet or CSV, clinical data in the OMOP common data model, code in Git. Whether open formats can represent the second object is the question of Section 4.

That gives requirement 2’s closing words, avoid system lock-in, two possible readings. Under reading (a), lock-in avoidance covers the data. The bytes come out in open formats, and what made each resource reproducible is an in-platform capability, rebuilt on any future migration. Under reading (b), lock-in avoidance covers the resource. Then the dependency graph, the pinned versions, the replay capability, and the branches need a form that survives a system boundary, and Section 4 goes looking for that form. The text does not select a reading.

3. The anatomy of a reproducible resource

Requirement 6’s sentence breaks into six elements. For each, the list gives what the notice’s text asks and which open interchange form exists. The incumbent’s documented in-platform capability is kept separate throughout, because what the notice requests, what the vendor documents, and what would happen on a transition are three different things. No reviewed document establishes the third.

1. Artifact identity and version. Explicit in the text: every resource “contains provenance, metadata.” Open forms exist per artifact class, such as content hashes, DOIs, and Git commits for code.
2. Dependency graph with exact versions. Explicit: “traced back to the exact version of all upstream dependencies.” Open vocabularies express dependency topology (W3C PROV’s derivation relations, OpenLineage’s column-level input fields). The version-pinning qualifier is where they thin out, as Section 4 details.
3. Transform logic, versioned. Explicit: “code” is one of the enumerated resources, and requirement 3 names Git. Git covers this element as well as anything in the survey, since commits pin bytes and branches are native.
4. Replay. Explicit: the dependency tree “can be easily replayed given new data or updated analysis logic.” This is re-execution under changed inputs. The notice does not ask for bit-identical reproduction, and the analysis here does not read the requirement as asking for it.
5. Branches and retained prior versions. Explicit: “while still retaining prior versions and branches.”
6. Change impact. Explicit in application 10.6: users alerted when vocabulary changes affect existing code sets.

The incumbent’s documentation describes in-platform machinery across all six. Dataset transactions are the basis of versioning, “sometimes referred to as ‘Git for data’” (Foundry datasets ), with historical views per branch. Dataset branches work like Git branches with one documented limit, “Unlike Git, there is no support for merging dataset branches” (Foundry branching ). Under retention policies, rollback to a transaction deleted by retention is documented as unavailable. Code repositories are Git-backed, and a lineage application shows per-node history, code, and build timelines. Staleness tracking, event triggers on new logic or updated data, and health-check alerting complete the set.

The N3C program’s own peer-reviewed description (Haendel et al., JAMIA 2021) states that “the platform automatically builds a provenance graph for every dataset and analysis.” None of that is in dispute here. None of it is portable merely because it exists either. The question that reading (b) poses is what form the six elements take outside the platform.

4. Three questions at the platform boundary

Each reading of requirement 2 prices differently. Reading (a) asks for data and code in open formats, which the incumbent’s documentation already describes as exportable. Reading (b) asks for an open form that carries all six elements together, and for change impact, the element the notice raises in its own application, such a form would have to reach past the edge of the platform.

4.1 The two readings price out differently

Under reading (a), the pair of requirements is satisfiable today, and the notice’s own text shows how: data out in open formats, code in a Git repository, and the reproducibility machinery a property of whatever platform is current. The limit of that reading shows at a platform change. The data and the code travel in their open forms, and the requirement’s words say nothing about the connective tissue between them: which exact upstream versions fed which resource, which code version built it, the replay capability, the branches. Whether that tissue transfers or is rebuilt lies outside what reading (a) asks for.

Under reading (b), the pair demands an open interchange form for that connective tissue, and the distinction shows in what the incumbent’s documentation describes as exportable. Dataset contents have documented egress paths. The export overview  covers file and table exports to external systems and states “Data is always exported from the master branch,” which matters because branches belong to the requirement-6 bundle. An API returns tables as Arrow or CSV. On the pages reviewed, transform code has one documented path out, cloning the repository to a local machine.

Pipelines can be packaged; the DevOps overview  lists “Flexible packaging of any combination of Foundry resources as a product,” with automatic dependency identification and versioning. The documented way to consume such a package is installation through the platform’s Marketplace, that is, into another Foundry environment. The lineage graph exports as an SVG image and a read-only share link (Data Lineage navigation ).

Nine pages were reviewed for the export question: DevOps overview, product creation, Marketplace overview, the Pipeline Builder Marketplace page, the export overview, the Read Table API, local development for Python transforms, and the Data Lineage overview and navigation pages. As of September 29, 2026, none of them describes a serialization of a product package, a build-specification graph, or a transaction and branch history for use outside the platform. That is a bounded statement about those nine pages, and the article makes no claim about the product’s full capability surface.

The diagram’s resource graph and its coverage marks are an inference from requirement 6 and the survey in Section 4.2, not something the notice defines.

4.2 Open standards cover the elements one or a few at a time

Reading (b) is deliverable only if an open, non-proprietary form preserves the six elements together across systems. Surveyed against the versions named below, each standard covers some elements, and none covers the combination.

W3C PROV  expresses derivation topology at any granularity but defines no semantics for version identifiers. Its revision relation is “a derivation for which the resulting entity is a revised version of some original,” and the specification’s own example records a version number in an application-specific attribute. It contains no replay or branch concept. OpenLineage  (core schema 2-0-2) records run events, with column-level input references through a facet. Its dataset identity carries no version, its version facet is one optional opaque string, and it is an observation protocol, so nothing in it re-executes. Git 2.56.0 pins bytes and does branches natively, and its object model knows nothing of datasets, transforms, or execution (gitglossary , “object type”). At large scale the data lives outside the object store by design, since Git LFS stores pointer files under 1,024 bytes.

RO-Crate 1.2  with the Workflow Run and Provenance Run  profiles, version 0.6 of September 2026, is the closest genuine standard. It is a portable JSON-LD package with several independent implementations that describes a workflow execution down to the step. Checked against the three profile texts (Process Run, Workflow Run, Provenance Run), a tool’s version is recommended, as version or the more specific softwareVersion, and not required, nothing requires input datasets to carry versions, no procedure for re-running a recorded workflow on new inputs appears, and branches are absent.

CWLProv 0.6.0 , which describes itself as an informal profile, packages one completed run as a BagIt bag (RFC 8493 ). The bag holds input and output files content-addressed under data/, the workflow, and a W3C PROV trace of the execution. It is a retrospective record of one run and describes neither re-execution under new inputs nor branches. FHIR R5’s Provenance resource  makes version-specific references within one server’s version space. BagIt packages files with checksum manifests. Croissant 1.0 is dataset metadata with semantic versioning and checksums, and it has no derivation graph. Croissant 1.1 , published January 29, 2026, keeps both and recommends PROV-O for provenance, with prov:wasDerivedFrom for derivation at several levels of granularity. Its provenance section sets no version requirement on the source of a derivation, so the edge carries PROV’s lack of version semantics, and the specification describes no re-running of a derivation, no branches, and no change impact.

The strongest coverage in the survey is a tool rather than a standard. DVC’s dvc.yaml and dvc.lock pin every dependency edge by content hash, re-execute the graph when data or logic changes, and ride Git branches (DVC project files ). That functionally covers five of the six elements. It is not an interchange form. DVC’s maintainers publish a dvc.yaml schema for editor validation, and as of September 29, 2026, searches of the IETF Datatracker and the W3C technical reports index found no conformance specification for those files from a standards organization. A GitHub repository search on September 29, 2026 found no dvc.lock parser and one DVC reimplementation, a personal educational project, so no maintained independent implementation was identified.

Individual elements have open forms, several of them good ones. In the specifications surveyed, none with more than one independent implementation preserves the combination of exact-version graph, replay, branches, and change impact across a system boundary. The table in Section 8 lists each form with its version and the elements it lacks.

4.3 Change impact stops at the platform edge

Application 10.6, in full:

“Application for creation and management of code sets. This should allow automatic integration and updates for multiple terminologies and include the ability to version code sets, track their usage, and document them with metadata such as their provenance and intention. Changes to vocabularies should be tracked and users should be alerted when these changes impact existing code sets.”

The vocabulary steward documents the rate of change this guards against. OHDSI’s release model states “Twice a year, a major release is issued,” and the content is fixed between releases (OHDSI vocabulary releases ). Its release notes are change manifests with old and new values, and from one release to the next concepts get deprecated; a deprecated concept “cannot be used as Standard,” per the Book of OHDSI. The requirement is an in-platform alerting capability, and the incumbent’s documentation describes in-platform machinery of that shape: staleness tracking, triggers on data updates, and health alerts.

The interchange side is thinner, and one artifact format makes the point concrete. The JSON expression format for OHDSI cohort definitions is defined by the circe  library. A current test expression file in that repository embeds full concept records, yet it has no field recording which vocabulary release the definition was written against; its only version-shaped field is a CDM compatibility range. A receiving system therefore cannot compute from the artifact alone whether the vocabularies have moved under the code set since it was written.

That observation concerns one interchange format; any platform’s alerting and other metadata channels are outside it. It has the same shape as a finding in the INL teardown for generative citation schemas. Within a platform, change-impact machinery is documented and demanded. A cross-system contract for what an upstream change implies for artifacts derived from the prior version was not identified in any specification surveyed in either article.

The diagram’s split into documented capability, documented egress, and an open question is an inference from the vendor’s documentation pages and the notice, not something either defines.

5. Scale

The corpus and the community these requirements serve are measured in agency and peer-reviewed numbers. At its 2021 description, N3C had 72 sites under data transfer agreements, harmonizing four source data models into OMOP 5.3.1. By the NCATS final report  of November 2024, more than 240 care delivery organizations had contributed de-identified records of more than 23 million individuals, and over 4,100 investigators from more than 400 organizations had conducted over 580 studies. Access runs in three tiers, limited, de-identified, and synthetic. Per the NCATS FAQ , “Data cannot be downloaded from this enclave or be removed,” and users may download aggregated research results after a data download committee reviews them.

The funder sets the context for reproducibility. NIH’s Data Management and Sharing Policy , effective January 25, 2023, defines the metadata accompanying scientific data to include “data provenance, data transformations,” and defines scientific data by their sufficiency to validate and replicate research findings. JAMIA, which published the program’s description, requires a data availability statement and states that “All analyses reported in an article must be repeatable using the archived data” (author instructions , archived January 29, 2026). These are institutional obligations enforced through plans, statements, and editorial review. None of the instruments reviewed specifies a machine-readable or cross-system form for the provenance they name. The FAIR principles , which NIH’s guidance cites by name, place detailed provenance in principle R1.2 and state of themselves that they are “not, themselves, a standard or a specification.”

6. The procurement record

The notice sits inside a documented contract chain, and the documents state their own connections. The incumbent IDIQ, 75N95023D00027 , was awarded to Palantir Technologies on September 27, 2023, without full and open competition, with an ordering period that ran through September 27, 2026. Its justification records that the enclave was stood up in May 2020 as a task order during the COVID emergency.

During 2025, three notices of intent to raise the contract’s ordering limit posted in sequence, in May, July, and August, proposing increases of $13.9M, $31M, and $23.5M. The May notice states “NCATS plans to recompete this requirement in FY2026.” The July notice drew a protest, filed July 10 and resolved August 8, and the justification for the eventual modification records that the government, in resolving it, clarified its intent to compete the follow-on contract. The August notice of intent is the document that ties the sources sought into the chain, directing interested vendors to it as the market-research stage of “a separate acquisition planning effort to determine next steps for the follow-on requirement.” The modification executed on September 30, 2025 raised the ceiling by $1,374,093.31, with a stated scope of infrastructure for the NCATS data portal and the closeout of NCI’s platform instance.

On December 10, 2025, NCATS wrote to the N3C community  that the platform would pause operations on December 12 for infrastructure updates, with reopening anticipated in early 2026. The letter describes a limited-time intake form for backups of project code, which “cannot be used to retrieve data.” An April 2026 justification for a separate N3C support contract records what happened next. The platform that hosts N3C was taken offline while HHS determined its acquisition strategy for Palantir software, and HHS then executed a contract with Palantir that allowed N3C to reopen publicly on March 2, 2026. In the justification’s words, N3C is now hosted within “a different cloud provider with a different set of features.”

The same justification concerns an order to Axle Informatics, 75N95025F00079 , for moving N3C toward modular, platform-agnostic components; USAspending lists it at $22.2M with a period of performance through December 30, 2026. No reviewed document states which contract reopened the platform or what the different features are. The records reviewed do not establish the identity of the current cloud provider either.

The incumbent IDIQ’s ordering period ended on September 27, 2026, and as of September 29, 2026, neither FPDS nor USAspending recorded an extension or any modification after the September 2025 one. On September 25, 2026, an HHS contracting office placed order 7571TE26F66007  with Palantir under the HHS SHARE blanket purchase agreement, 75P00122A00010. The order is worth $9,738,016, is funded by NCATS, and runs from September 28, 2026 to September 27, 2027. FPDS describes it as a cloud-based software-as-a-service platform serving as the trusted researcher environment for the National Clinical Cohort Collaborative, placed after fair opportunity among the agreement’s holders, with two offers. As of September 29, 2026, it had not appeared on SAM.gov as a notice. Each fact above is a document’s own statement, and the records reviewed draw no link between this order and the recompetition announced in 2025.

7. Who would build it

The public record through September 29, 2026 contains no solicitation for the recompetition that the 2025 documents describe. It does contain the September 2026 order, which carries its own solicitation identifier, RFQ-OMAS-SHARE-2026-08, and which no reviewed record connects to that recompetition. The incumbent’s platform is listed on the FedRAMP marketplace  at the High impact level, with the status FedRAMP Certified since November 19, 2024. The notice requires FedRAMP Moderate at minimum and itself notes the incumbent’s High authorization. The NCATS FAQ describes the Foundry platform in use for N3C as authorized at a Moderate impact level.

The contract values with documented scope are these. The 2020 standup task order came to $2.03M. The IDIQ whose ordering period ended in September 2026 had a $69.4M ceiling, and per its own justification it served an environment supporting several NIH institutes and federal programs, N3C among them. The public record does not show whether any respondent to the sources sought can satisfy the thirteen software requirements; that is what a capability statement asserts and a procurement tests.

8. What does not exist as a standard

The survey fits in one table: the six elements of requirement 6 against the closest open form found for each.

The table shows that every element exists somewhere, several in good open forms. In the specifications surveyed for this article, named with their versions in Section 4.2 and the table, as of September 29, 2026, no interchange form with independent implementations preserves the combination across a system boundary. That is the difference between the two readings of avoid system lock-in, stated as engineering. Reading (a) is buildable with what exists. Reading (b), within the survey documented here, calls for a standard that was not found.

The notice does not say which reading it means, and the record it now sits in gives the question its weight. The 2025 to 2026 transition is documented in outline: a pause, an intake form for code backups, a reopening on a different cloud provider with a different set of features, the end of the incumbent contract’s ordering period, and a new order to the same vendor. No document reviewed for this article says what became of the reproducible bundle across that transition, in either direction. For a research corpus whose funder defines its scientific data by the ability to validate and replicate findings, that is the unknown that matters most.

The two requirements sit four items apart, and between them is a question the text does not answer and the record has now raised twice, once in words and once in a platform transition. This article does not claim that anything was lost or preserved in that transition, and it does not claim that the incumbent’s platform lacks an export it has not documented on the pages reviewed. I work on verifiable provenance for derived outputs in this area, and that work is separate from this analysis. More write-ups are on the engineering blog.

If a research platform will have to show, after a migration, which data versions and code produced each result, designing that record so it survives the move is contract work I take on.