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

Date: August 25, 2026 · Author: Dmitrii Zatona 

In August 2025, the National Institutes of Health posted a sources sought notice for the platform behind the N3C Data Enclave — the federal research environment holding harmonized clinical records on tens of millions of patients. The notice’s requirements list asks for two things in adjacent items: an open architecture whose stated design goal is to “avoid system lock-in,” and per-resource reproducibility — every dataset, analysis, plot, and report traceable to the exact versions of everything it was derived from, replayable, with prior versions and branches retained. Inside one platform, both are deliverable; the notice itself names an incumbent that documents the second extensively. What the notice does not say is whether the openness requirement extends to the data alone or to the reproducible resource as a whole — and between those two readings sits a missing category of standard. Months after the notice closed, the platform in question went through a documented transition that turned the question from analytical into practical. This article takes the two requirements apart, maps what open specifications cover, and reads the procurement record of what happened next.

1. What was published

The notice is 75N95025R00046 , “Secure Platforms Support for the N3C Data Enclave,” a Sources Sought notice posted on SAM.gov by the NIH’s National Institute on Drug Abuse office on August 8, 2025, and republished on August 22 with a single change beyond the deadline: one added sentence extending the response window from August 25 to September 2, 2025. A programmatic diff of the two versions shows no requirement added, removed, or reworded. The notice carries no attachments; its entire content is the description text. It archived on September 25, 2025. Responses went to Brian O’Laughlin, Contracting Officer — NIDA’s acquisition office contracts on behalf of NCATS, the center that leads the program, an arrangement the government’s own notices state directly and the contract records confirm (awarding office NIDA, funding office NCATS).

The notice invokes FAR 10.002 market research, and its own text is explicit about what a sources sought is not: not a commitment to issue a solicitation, with responses that will not be considered proposals. One precision worth a sentence: “sources sought” is a SAM.gov notice classification, not a term of FAR Part 10 — the phrase does not appear anywhere in that part as of the notice’s posting date, per the point-in-time edition.

Unusually for this genre, 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. And unusually for a closed notice, the acquisition it belongs to is documented as still open: the government’s own September 2025 justification states that “NCATS has started the recompetition process for FY26” and names this notice’s ID as its market-research stage, while an April 2026 justification for a related support contract records that a new solicitation number is yet to be identified. As of August 25, 2026, no solicitation for the platform requirement appears on SAM.gov — a statement bounded by what SAM.gov can show, since a solicitation issued through a GSA vehicle would not appear there as a public notice. The incumbent contract’s ordering period runs through September 27, 2026.

Method note: this is the third teardown in a series; the first two examined the FBI TSC’s “traceable lineage”  notice and the INL nuclear-licensing “every output traceable”  RFI.

2. What the requirements say

The notice lists professional-services requirements and thirteen software requirements. Two of the thirteen carry this article. 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 computational reproducibility — “consistent results using the same input data; computational steps, methods, and code” — extended with version pinning, re-execution under changed inputs, and branch retention. The other requirements orbit these two: requirement 3 closes with a Git repository for data pipelining; application 10.5 asks that usage of every shared artifact be automatically tracked for attribution; application 10.6, quoted in Section 4, asks for change alerts when vocabularies move under existing code sets.

One distinction has to be drawn before the requirements can be evaluated together, because they concern different objects. Requirement 2’s subject is data: exportable in open, non-proprietary formats, under the control of NCATS and the data owners. (Two different actors are in play here. Researchers inside the enclave work under a regime the notice states plainly — the data cannot be downloaded or removed, with results leaving only through a review process. Requirement 2 is about the custodian’s control, not the researcher’s.) Requirement 6’s subject is the resource: not the bytes of a dataset but the reproducible whole — data plus code plus the dependency graph with exact versions plus the ability to replay plus 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 they can represent the second object is Section 4’s question.

That gives requirement 2’s closing words — avoid system lock-in — two possible readings, and the notice does not say which it means. Reading (a): lock-in avoidance covers the data. The bytes come out in open formats; what made each resource reproducible is an in-platform capability, rebuilt rather than transferred on any future migration. 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 that form is what Section 4 goes looking for. Nothing in the notice selects a reading, and this article does not impute one. It prices them.

3. The anatomy of a reproducible resource

Requirement 6’s sentence decomposes into six elements. For each: what the notice’s text explicitly asks, and what open interchange form exists for it — with the incumbent’s documented in-platform capability, per its own public documentation, held separate throughout (what the notice requests, what the vendor documents, and what would happen on a transition are three different things, and the third is established by no document reviewed for this article).

1. Artifact identity and version. Explicit in the text: every resource “contains provenance, metadata.” Open forms exist per artifact class: content hashes, DOIs, 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: commits pin bytes, branches are native.
4. Replay. Explicit, and worth reading precisely: 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 this article does not upgrade the requirement to that stronger reading.
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 impact existing code sets.

The incumbent’s documentation describes in-platform machinery across all six: dataset transactions as the basis of versioning — “sometimes referred to as ‘Git for data’” — with historical views per branch; dataset branches analogous to Git branches, with a documented limit (“Unlike Git, there is no support for merging dataset branches”) and retention policies under which rollback to a retention-deleted transaction is documented as unavailable; Git-backed code repositories whose commits publish build specifications; a lineage application showing per-node history, code, and build timelines; staleness tracking, event triggers on new logic or updated data, and health-check alerting. 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, and none of it is portable by virtue of existing: the question requirement 2’s reading (b) poses is not whether the six elements exist inside a platform but what form they take outside one.

4. Three problems

4.1 The two readings price out differently

Under reading (a), the requirements pair is satisfiable today, and the notice’s own text shows how: data out in open formats, code in a Git repository, the reproducibility machinery a property of whatever platform is current. The scope 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 — which exact upstream versions fed which resource, which code version built it, the replay capability, the branches. Whether that tissue transfers, is rebuilt, or neither lies outside what reading (a) asks for. Under reading (b), the pair demands an open interchange form for precisely that connective tissue. The distinction is visible in what the incumbent’s own documentation describes as exportable. Dataset contents have documented egress paths: file and table exports to external systems (“Data is always exported from the master branch” — a detail with element-5 implications, since branches are part of the requirement-6 bundle), and an API returning tables as Arrow or CSV. Transform code has one: cloning the repository to a local machine. Pipelines can be packaged — “Flexible packaging of any combination of Foundry resources as a product,” with automatic dependency identification and versioning — and the documented consumption path for such a package is installation via the platform’s marketplace, that is, into another Foundry environment. The lineage graph exports as an SVG image and a read-only share link. The reviewed pages do not describe a serialization of a product package, a build-specification graph, or a transaction and branch history for consumption outside the platform — a bounded statement about nine documentation pages listed in the sources, not a claim about the product’s full capability surface.

4.2 The interchange survey comes back element-shaped

Whether reading (b) is deliverable turns on whether an open, non-proprietary form preserves the six-element conjunction across systems. Surveyed against current versions and profiles, the standards each cover elements, and none covers the conjunction. W3C PROV  expresses derivation topology at any granularity, but defines no version-identifier semantics — its revision relation is “a derivation for which the resulting entity is a revised version of some original,” with the spec’s own example resorting to an application-specific version attribute — and contains no replay or branch concept. OpenLineage  (schema 2-0-2) records run events with column-level input references, but its dataset identity carries no version, its version facet is one optional opaque string, and it is an observation protocol: nothing in it re-executes. Git pins bytes and does branches natively, and its object model knows nothing of datasets, transforms, or execution — at petabyte scale the data itself lives outside the object store by design (Git LFS stores pointers under 1,024 bytes). RO-Crate 1.2  with the Workflow Run and Provenance Run profiles (0.5) is the closest genuine standard: a portable JSON-LD package, with independent implementations, describing a workflow execution down to step level. Verified against the profile texts: exact-version pinning of upstream dependencies is not mandated (the profile’s own example carries a tool version inside an entity’s name string), no replay contract of any kind is defined, and branches are absent. CWLProv  packages a completed run as a BagIt bag with PROV metadata — and its current version’s changelog notes it will “no longer snapshot input files,” so the bag no longer necessarily carries the pinned upstream data it references. FHIR’s Provenance resource does version-specific references — within one server’s version space. BagIt is fixity; Croissant is dataset metadata with semantic versioning and checksums, no derivation graph.

The strongest coverage in the survey is not a standard but a tool: DVC’s dvc.yaml/dvc.lock pin every dependency edge by content hash, re-execute the graph when data or logic changes, and ride Git branches — five of the six elements, functionally. What it is not is an interchange form: no conformance specification published by a standards organization, and no maintained independent implementation reading or executing those files, was identified as of August 25, 2026 (the search method is in the sources). The bounded finding, then: individual elements have open forms, several of them good ones; no specification with more than one independent implementation was identified that preserves the conjunction — exact-version graph, replay, branches, change-impact — across a system boundary. The survey list, with each standard’s version and its specific missing elements, is in the sources.

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 change frequency this guards against is documented by the vocabulary steward itself: OHDSI’s release model states “Twice a year, a major release is issued,” with content fixed between releases, and its release notes are old-value/new-value change manifests; concepts get deprecated between releases, and a deprecated concept “cannot be used as Standard.” The requirement is an in-platform alerting capability, and the incumbent’s documentation describes in-platform machinery of exactly this shape (staleness tracking, triggers on data updates, health alerts). The interchange side is thinner, and one artifact-format observation makes it concrete: the JSON expression format for OHDSI cohort definitions, defined by the circe  library, embeds full concept records but, on direct inspection of a current expression file, carries no field recording which vocabulary release the definition was authored against; the only version-shaped field in the file is a CDM compatibility range. A receiving system cannot compute, from the artifact alone, whether the vocabularies have moved under the code set since authoring. That is an observation about one interchange format, not about any platform’s alerting implementation or other metadata channels — but it is the same shape as the previous article’s finding 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 here or there.

5. The scale

The corpus and community these requirements serve, 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 NCATS’s November 2024 program report , more than 240 contributing organizations, de-identified records of more than 23 million individuals, and over 4,100 investigators from more than 400 organizations who had conducted over 580 studies. Access runs in three tiers — limited, de-identified, synthetic — inside an enclave from which, per NCATS, “Data cannot be downloaded from this enclave or be removed”; results leave the enclave only as aggregated outputs approved through a download review process. The funder-side context: NIH’s Data Management and Sharing Policy, effective January 2023, defines the metadata accompanying scientific data to include “data provenance, data transformations,” and defines scientific data by their sufficiency to validate and replicate findings; journals in N3C’s publication venues require data availability statements, with one stating that “All analyses reported in an article must be repeatable using the archived data.” These are institutional obligations — plans, statements, editorial enforcement; 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 points to 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 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 (May, July, August), proposing increases of $13.9M, $31M, and $23.5M respectively; 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; the justification for the eventual modification records that, in resolving it, the government clarified its intent to compete the follow-on contract. The August notice of intent is also the document that links this article’s subject into the chain: it directs interested vendors to the sources sought 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 — its own stated scope being infrastructure for the NCATS data portal and the closeout of NCI’s platform instance.

Then the transition. On December 10, 2025, NCATS wrote to the N3C community that the platform would pause operations on December 12 for infrastructure updates, anticipating reopening in early 2026; the letter describes a limited-time intake form for retrieving existing project code — backups only, which “cannot be used to retrieve data.” The April 2026 justification for a separate N3C support contract records what happened next: the platform that hosts N3C was taken offline during this period while HHS determined its acquisition strategy for Palantir software; HHS then executed a contract with Palantir allowing N3C to reopen publicly on March 2, 2026 — and, in the justification’s words, N3C is now hosted within “a different cloud provider with a different set of features.” The same document covers a $22.2M order to Axle Informatics  for transitioning N3C toward a modular, platform-agnostic architecture, extended through December 2026. Which contract reopened the platform, and what the different features are, no reviewed document states; the identity of the current cloud provider is likewise not established by the records reviewed. Each fact above is a document’s own statement; no causal links beyond those the documents themselves draw are asserted here.

7. Who would build it

The recompetition the government’s documents describe remained, as of the reviewed record, without a solicitation number. The incumbent’s platform holds a FedRAMP High authorization (per the FedRAMP marketplace , as of November 2024); the notice requires FedRAMP Moderate at minimum and itself notes the incumbent’s High authorization; NCATS’s FAQ describes the N3C instance as operating at the Moderate impact level. The contract values with documented scope: the 2020 standup task order at $2.03M; the current IDIQ at a $69.4M ceiling — a vehicle that, per its own justification, serves an environment supporting several NIH institutes and federal programs, not N3C alone. Whether any respondent to the sources sought can satisfy the thirteen software requirements is exactly what a capability statement asserts and a procurement tests; the public record does not answer it, and this article does not either.

8. What does not exist as a standard

The teardown as a table — the six elements of requirement 6’s bundle against the survey:

Every element exists somewhere, several in good open forms; in the specifications surveyed for this article, no interchange form with independent implementations preserves the conjunction 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, names a standard that was not found. The notice does not say which it means. The record it now sits in gives the question its weight: the platform transition of 2025–2026 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 — and what became of the reproducible bundle across that transition, in either direction, is answered by no document reviewed for this article. For a research corpus whose funder defines its scientific data by the ability to validate and replicate findings, that is the load-bearing unknown.

A disclosure: I work on a specification in this area — verifiable provenance for derived outputs — and that work is separate from, and not linked in, this analysis.

The two requirements are on the page, four items apart. Between them sits a question the text does not answer and the record has now asked twice — once in words, once in a platform transition. The standard that would answer it was not found on any shelf surveyed here.

If you are building a response to this document and the provenance or attestation piece has to be designed and built, that is contract work I take on.