# What "Traceable Lineage" Requires: A Teardown of the FBI TSC AI Sources Sought > Source: > Published: 2026-08-25 07:37:25+00:00 # What “Traceable Lineage” Actually Requires: A Teardown of the FBI TSC AI Sources Sought **Date:** August 16, 2026 · **Author:** [Dmitrii Zatona ](https://zatona.dev/) On March 27, 2026, the FBI’s Threat Screening Center posted a market-research notice asking vendors how they would build, among other things, “Predictive Modeling Using Enhanced Data with Traceable Lineage.” The phrase reads like standard procurement language. It is not. Taken at face value, it names a technical property — reconstructible, audit-grade, record-level provenance across federated systems — that no standardized industry tool provides as a whole. This article takes the requirement apart: what the notice actually asks for, which known engineering problems it decomposes into, and where the gap between *lineage* as the data industry ships it and *lineage* as this document needs it becomes load-bearing. ## 1. What was published The document is a Sources Sought notice, identifier FBI-TSC-AIE, titled “Threat Screening Center AI Enhancement.” It was posted on [SAM.gov ](https://sam.gov/opp/1e01b3125fec412b8e13df34adc4013c/view) on March 27, 2026 by the FBI, with responses due April 10, 2026 and a place of performance of Clarksburg, West Virginia. The attached requirement document — “Attachment AS — Request for Information for Threat Screening Center Artificial Intelligence (AI) Enhancement, Version 1.2,” issued by the TSC’s Information Technology Unit — is publicly downloadable from the notice’s attachments. A Sources Sought notice is market research. It is not a solicitation, not a request for proposal, and not a contract. The document states this in a standard disclaimer and adds that responses may be used to formulate requirements and acquisition strategies for future competitive solicitations. Vendors were asked to respond with capability statements of up to 25 pages and to identify whether they hold a GSA Schedule contract. The notice was archived on April 25, 2026 and then republished on July 22, 2026 with one substantive change in its background section, discussed below. As of August 8, 2026, no follow-on solicitation and no award traceable to this notice appear in public SAM.gov or USAspending.gov records. That is a statement about public records, not about the procurement’s status: orders competed among GSA Schedule holders run through GSA eBuy, which is not publicly searchable, and neither of the TSC’s two existing analysis-services orders (Section 7) ever appeared on SAM.gov as a public solicitation. The notice received press attention after [Reason ](https://reason.com/2026/07/28/minority-report-fbi-seeks-ai-for-political-watch-list/) reported on it on July 28, 2026 (Daniel Boguslaw). ## 2. What the requirement actually says The RFI lists six use cases. Five of them are retrieval and reporting: an AI knowledge base over internal policies and SOPs with mandatory source citations; federated search across repositories with source attribution; identifier-driven recurring reports with per-element citations; natural-language query with synthesized answers that distinguish extracted facts from AI-generated synthesis; and natural-language-driven data visualization with citation metadata. Every one of the six carries an explicit traceability or citation clause. The sixth use case is the one this article is about. In full: “The solution must leverage existing enterprise datasets that include enriched or enhanced data elements with documented source attribution to develop predictive models. When new data is ingested, the system must analyze similarity, pattern alignment, and attribute correlation against existing records to predict where additional relevant information may be derived across federated systems. The solution must provide transparent reasoning for its predictions, including traceability to the specific source data, enhancement logic, and reference materials used in generating the inference. All predictive outputs must retain auditable lineage to ensure analytic defensibility and support oversight requirements.” Read as an engineering specification, this decomposes into four known problems. * Analyze similarity, pattern alignment, and attribute correlation against existing records* is probabilistic record linkage — deciding whether two records that are not textually identical refer to the same entity. The canonical framework is Fellegi and Sunter’s [“A Theory for Record Linkage”](https://doi.org/10.1080/01621459.1969.10501049)( *JASA*64(328), 1969): score agreement patterns between record pairs, threshold into link / possible link / non-link. Modern open implementations include [Splink](https://moj-analytical-services.github.io/splink/)(UK Ministry of Justice), [Zingg](https://github.com/zinggAI/zingg), and [dedupe](https://github.com/dedupeio/dedupe); [Senzing](https://senzing.com/senzing-sdk/)is the commercial reference point. * Predict where additional relevant information may be derived across federated systems* is candidate generation and link prediction: given a new record, rank which external systems and records are likely to hold related information. In record-linkage terms this is blocking — pruning the pair space to candidates worth comparing (Christen, *IEEE TKDE*24(9), 2012). This matters because it is a different task from predicting a person’s future behavior. Reason’s article characterized the goal as AI to “help predict who might be a terrorist.” The requirement’s text describes a system that predicts *where data about an entity may reside*, not *what the entity will do*. Both tasks are hard, but they fail differently: a record-linkage system’s characteristic failure is misidentification — merging two people into one identity or scattering one person across several — while a behavioral-prediction system’s characteristic failure is the base-rate problem quantified in Section 5. An analysis that critiques the requirement as behavior prediction critiques a system the text does not describe. The distinction collapses only if linkage scores are later repurposed as risk scores; nothing in the document states that, and nothing in it precludes that. * Enriched or enhanced data elements* are derived attributes: values computed by earlier processing — a resolved identity, a normalized name, a model-assigned label — that exist in no source system. Section 4 shows why these dominate the difficulty. * Documented source attribution* and *name provenance. The rest of this article is about the distance between that phrase and what shipping tools do.* **auditable lineage** One more clause deserves attention. The RFI’s background section grounds the TSC’s mission in Homeland Security Presidential Directive 6 and National Security Presidential Memorandum 7. Two unrelated documents carry that designation, each self-designated NSPM-7 in its official text: the memorandum of October 4, 2017, [“Integration, Sharing, and Use of National Security Threat Actor Information to Protect Americans” ](https://www.govinfo.gov/content/pkg/DCPD-201700722/pdf/DCPD-201700722.pdf) — the directive behind watchlisting-data interoperability — and the memorandum of September 25, 2025, [“Countering Domestic Terrorism and Organized Political Violence” ](https://public-inspection.federalregister.gov/2025-19141.pdf) (90 FR 47225). The original March 27 PDF cited NSPM-7 without a date. The July 22, 2026 republication resolved the ambiguity: the amended background dates the reference to October 5, 2017 and names the threat-actor-information memorandum. The Reason article, published July 28, described the reference as likely connected to the 2017 directive; the amended notice specifying this had been posted on SAM.gov six days earlier. ## 3. Lineage versus provenance The data industry uses “lineage” and “provenance” close to interchangeably. For this requirement the difference is the entire problem, so the terms need separating. **Lineage**, as shipped, is a graph over *data assets*: this table feeds that job, which writes that table. [OpenLineage ](https://openlineage.io/docs/spec/object-model), the emerging standard, models Jobs, Runs, and Datasets; its finest standardized granularity is the [column-level lineage facet ](https://openlineage.io/docs/spec/facets/dataset-facets/column_lineage_facet), which maps input columns to output columns. [Marquez ](https://github.com/MarquezProject/marquez), the reference implementation, stores these events in PostgreSQL. [DataHub ](https://docs.datahub.com/docs/features/feature-guides/lineage) supports fine-grained lineage down to the column and accepts lineage by automatic extraction, by API, or by manual UI editing — its documentation warns that “lineage added by hand and programmatically may conflict with one another.” [Apache Atlas ](https://atlas.apache.org/2.0.0/TypeSystem.html) models Process entities whose inputs and outputs are arrays of DataSets. Databricks Unity Catalog captures table- and column-level lineage. In each of these systems as documented, the built-in lineage model bottoms out at column granularity (usually the dataset), and the metadata store is an ordinary mutable database recording what pipelines *assert* about themselves. **Provenance**, in the sense this RFI needs, is a statement about an individual output record: *these* input records, transformed by *this* code at *this* version, produced *this* value — retained in a form that supports later scrutiny. The W3C [PROV data model ](https://www.w3.org/TR/prov-dm/) (Recommendation, 2013) can express exactly this: its Entities can be defined at any granularity, and `wasDerivedFrom` can link individual record-entities. But PROV is a vocabulary, not a mechanism. Nothing enforces that the graph is complete, and nothing protects it from modification; the companion note on access ([PROV-AQ ](https://www.w3.org/TR/prov-aq/)) addresses tampering only as informal guidance, with HTTPS as its concrete recommendation. Record-level provenance is not unknown to computer science. Database research built it decades ago: provenance semirings (Green, Karvounarakis, Tannen, PODS 2007) annotate every tuple with a polynomial recording exactly how it was derived; [ProvSQL ](https://github.com/PierreSenellart/provsql) implements this as a PostgreSQL extension; Trio and GProM are earlier systems in the same line; Cheney, Chiticariu, and Tan’s [survey ](https://homepages.inf.ed.ac.uk/jcheney/publications/provdbsurvey.pdf) (*Foundations and Trends in Databases* 1(4)) codifies the theory. The closest industry system is [Pachyderm ](https://docs.pachyderm.com/latest/learn/glossary/provenance/), whose immutable data commits link every output to the exact input commits and pipeline version that produced it — but its unit of work is the file, not the record, and its immutability is operational rather than tamper-evident. Separately, cryptographically protected provenance chains exist in research (Hasan, Sion, Winslett, [FAST 2009 ](https://www.usenix.org/legacy/events/fast09/tech/full_papers/hasan/hasan.pdf)) and existed briefly as a managed cloud product — Amazon QLDB, a ledger database with a cryptographically verifiable transaction log, which AWS retired on July 31, 2025. The precise state of the art, then: record-level granularity exists in research systems without integrity protection; integrity protection exists in systems without pipeline lineage; industry lineage catalogs have neither. No standardized primitive combines record-level granularity with tamper evidence, and that combination is what *auditable lineage* in service of *analytic defensibility* of individual predictions requires. A lineage catalog’s answer to the question *why is this attribute on this record* is an assertion by the system being questioned. The difference between an assertion and evidence surfaces at exactly one moment: when someone disputes the assertion. ## 4. Five engineering problems ### 4.1 Provenance survives transformation only if captured at the record level A pipeline joins records from systems A and B, applies a model, and writes an output record. A lineage catalog records: job J read datasets A and B and wrote dataset C, possibly with column mappings. It does not record which *rows* of A and B produced which row of C, under which code version, with which parameters. *Documented source attribution* implemented on catalog metadata attributes the output to *systems*, not to *statements* — it can say a value came from somewhere in dataset A, not which record of A, as of when, under what transformation. Federal control language already names the missing properties. NIST SP 800-53 Rev. 5 control AU-9 requires protecting audit information from modification and deletion, with enhancement AU-9(3) specifying cryptographic integrity mechanisms; AU-10 requires non-repudiation — irrefutable evidence that a given actor performed a given action. A mutable metadata store populated by self-reported pipeline events does not, by itself, provide the cryptographic integrity mechanisms AU-9(3) describes or the non-repudiation property AU-10 defines. The catalogs are not defective; they were built for impact analysis and debugging, where a trusted-operator assumption is fine. The RFI’s phrase *analytic defensibility* describes an adversarial setting, and the assumption does not transfer. ### 4.2 Derived attributes contaminate their own future evidence The requirement is explicit that the enterprise datasets already contain enriched and enhanced elements and that new predictive models are to be developed on top of them. This creates a loop worth drawing. An enrichment model computes a derived attribute — say, a resolved-identity link — and the attribute is written into the consolidated record. The consolidated store is later sampled to train the next model. That model’s outputs now partially encode the first model’s guesses. When the second model emits an attribute that agrees with the first, the agreement arrives looking like independent corroboration. It is not; it is the same inference, recycled through a training set. The provenance graph of the record store has stopped being acyclic, and any process that counts “how many indicators support this link” — human or automated — is at risk of counting one indicator several times. Detecting the cycle requires exactly the record-level edges that Section 4.1 established are not captured. At dataset granularity the loop is invisible: “enrichment dataset feeds training dataset feeds enrichment dataset” describes both a healthy retraining loop and a self-confirming one. Only the record-level graph distinguishes them. No catalog in Section 3 stores that graph. The screening context supplies a concrete reason to care about compounding derived signals: the Fourth Circuit’s opinion in *Elhady v. Kable*, 993 F.3d 208 (2021), recites from the factual record that the TSC received about 113,000 nominations annually, of which roughly 99% were accepted. The reported acceptance rate makes the provenance of attributes supplied with nominations — including computed ones — material to what the consolidated store contains. ### 4.3 Corrections do not propagate through a graph nobody stored Suppose a source record is corrected, or a nomination is withdrawn. Every derived attribute computed from that record, every model trained on those attributes, and every prediction served from those models is now partially built on retracted input. The technical name for handling this is revocation propagation: walk the transitive closure of everything downstream of the retracted fact and invalidate or recompute it. The cost of a correction is the cost of that walk. If the record-level graph was never stored, the walk cannot be performed, only approximated — typically by full recomputation or by not propagating at all. None of the lineage catalogs in Section 3 defines revocation semantics. Their edges say where data came from; they cannot express “this input is no longer valid; here is what must be recomputed.” The Privacy Act of 1974 anticipates the need at the record level: [5 U.S.C. § 552a(c) ](https://www.law.cornell.edu/uscode/text/5/552a) requires each agency to keep an accounting of each disclosure of a record — date, nature, purpose, recipient — for at least five years or the life of the record, and (c)(4) requires informing prior recipients of subsequent corrections and disputes. The FBI’s system-of-records notice for TSC records ([JUSTICE/FBI-019, 76 FR 77846 ](https://www.govinfo.gov/content/pkg/FR-2011-12-14/pdf/2011-32074.pdf)) claims exemptions under § 552a(j) and (k), implemented at [28 CFR 16.96(r) ](https://www.ecfr.gov/current/title-28/chapter-I/part-16/subpart-E/section-16.96): the system is exempt from (c)(3) (the subject’s access to the accounting) and (c)(4) (correction notices to prior recipients), among others. The statute’s structure leaves (c)(1)–(2) — the duty to *create and retain* the accounting — outside what (j)(2) can exempt. The engineering consequence is symmetrical with the legal one: the disclosure-and-derivation graph must exist and be maintained regardless of who is entitled to read it. The operational numbers give the propagation problem scale. [GAO-25-108349 ](https://www.gao.gov/products/gao-25-108349) (August 2025) reports roughly 20,000 DHS TRIP redress inquiries between December 2021 and September 2023, of which 1.5% (289) related to the watchlist, with about a third of those individuals (88) subsequently removed. DOJ OIG [Audit 14-16 ](https://oig.justice.gov/sites/default/files/legacy/reports/2014/a1416.pdf) (2014) measured a median of 78 days for the FBI to remove certain non-investigative subjects. A removal is precisely a revocation event. Whether it reaches every derived attribute and model that consumed the record is a function of whether the consumer graph exists. The retention schedule sets the time horizon. The FBI-019 notice specifies retention of 99 years for active screening records, 50 for archived ones, and 25 years for audit logs. Any lineage scheme adopted for this system is therefore committed to remaining interpretable across multiple generations of software, formats, and vendors — a constraint that favors simple, self-describing, verifiable structures over any particular product’s internal metadata schema. ### 4.4 Reproducing a decision at time T requires bitemporal, immutable state *Transparent reasoning for its predictions* is a statement about the past by the time anyone asks for it. To reconstruct why the system produced a given output years earlier, four things must be recoverable as they were at that moment: the feature values, the model version, the thresholds and rules, and the mapping between them. This is the bitemporal problem — distinguishing *valid time* (when a fact was true in the world) from *transaction time* (when the database recorded it) — formalized by Snodgrass and implemented in modern bitemporal SQL systems such as [XTDB ](https://docs.xtdb.com/concepts/key-concepts.html). The nearest industrial practice is the feature store. [Feast ](https://docs.feast.dev/getting-started/concepts/point-in-time-joins) and Tecton perform point-in-time-correct joins so that training data contains only feature values that were available at each historical event’s timestamp. This is the right machinery, but its guarantee is prospective: it prevents leakage when constructing training sets. It does not make the historical state provable after the fact — the join is only as good as the mutable offline store it reads at query time. Adjacent versioning tools stop at the same line. Delta Lake time travel reproduces old table versions only within the `VACUUM` retention window, seven days by default, after which the history is physically deleted. MLflow registries version models; DVC and lakeFS version files by content hash. All detect change; none produce evidence that history was not rewritten, because their storage remains administratively mutable and their references movable. Litigation over the No Fly List illustrates what reconstruction demands in practice. In *Latif v. Holder*, 28 F. Supp. 3d 1134 (D. Or. 2014), judicial review ran on an administrative record containing the information the government relied on for a listing decision — assembled for the court, with the petitioner seeing only his own submissions; the revised process documented in the 2016 follow-up opinion turned on whether a statement of reasons and the underlying material could be produced and reviewed. In *FBI v. Fikre*, 601 U.S. 234 (2024), the government’s declaration that a removed individual would not be relisted on the basis of currently available information failed to moot the case; the Court observed that the declaration “does not disclose what conduct landed Mr. Fikre on the No Fly List.” Both cases reduce, on the technical side, to the same artifact: a reconstructible account of what specific inputs produced a specific determination, at a specific time. That artifact is what Section 4.1’s record-level provenance plus this section’s bitemporal snapshots exist to produce. ### 4.5 Across a trust boundary, an assertion is not evidence The notice does not define *federated systems*; what the record shows is distribution across operators. Per the factual record recited in *Elhady*, the screening database is made available to federal, state, and tribal law enforcement, some foreign governments, and some private entities working in sensitive security areas, and the notice’s summary describes querying external systems for data enrichment. Where record data or its provenance metadata crosses between operators, the receiving side can check the claimed history only if a verification mechanism exists; none of the catalogs in Section 3 supplies one, so the receiving side can only store the claim. Every problem in Sections 4.1–4.4 now compounds: the record-level graph is split across operators, each mutable, none independently checkable. This exact shape — many mutually distrusting parties needing to rely on each other’s claims about history — has been addressed in three different domains, with a recurring pair of primitives. Certificate Transparency ([RFC 6962 ](https://datatracker.ietf.org/doc/html/rfc6962), [RFC 9162 ](https://datatracker.ietf.org/doc/html/rfc9162)) made certificate issuance auditable: every certificate goes into an append-only Merkle-tree log; an *inclusion proof* demonstrates a given entry is in the log, and a *consistency proof* demonstrates the log at time T₂ is an append-only extension of the log at T₁ — so history cannot be silently rewritten, and independent monitors verify it continuously. [Sigstore’s Rekor ](https://docs.sigstore.dev/logging/overview/) applies the same structure to software signatures and attestations. [in-toto attestations ](https://github.com/in-toto/attestation/blob/main/spec/README.md) bind signed metadata to artifacts by cryptographic digest, and [SLSA v1.0 ](https://slsa.dev/spec/v1.0/levels) layers build-provenance requirements on top, up to builds where forging provenance requires exploiting the platform rather than editing a database. [C2PA ](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html) does it for media: signed manifests whose hash bindings break if the asset’s bytes change. In none of these domains was the working answer a richer metadata catalog. Two primitives recur. The first is metadata cryptographically bound to the individual artifact by digest and signature — the in-toto, SLSA, and C2PA layer. The second, wherever parties must audit one another’s history over time, is a verifiable append-only log of those bound statements, checkable by parties who do not trust the log’s operator — the CT and Rekor layer, which is also where Sigstore anchors in-toto and SLSA attestations. The structural translation to this RFI’s setting is direct: entries bound to individual records and their derivations, proofs that the derivation history existing at decision time is a prefix of the history existing at review time. The regulatory direction of travel is compatible with this reading and stops short of mandating it. OMB [M-25-21 ](https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf) (April 2025), which rescinded and replaced M-24-10, presumes law-enforcement risk assessments about individuals and identification of criminal suspects to be “high-impact AI,” requiring documented pre-deployment testing, impact assessment, traceability-enabling monitoring processes, and human oversight — while excluding AI used as a component of national security systems from its coverage. The EU AI Act ([Regulation 2024/1689 ](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)) requires high-risk systems to log events automatically over their lifetime for traceability (Article 12), with providers and deployers retaining logs at least six months (Articles 19, 26(6)), and classifies specified law-enforcement uses, including individual risk assessment and profiling, as high-risk (Annex III, point 6); its 2026 “Digital Omnibus” amendment ([Regulation 2026/1744 ](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1744)) left these texts intact while postponing their application for Annex III systems to December 2, 2027. Both regimes mandate that logs and documentation *exist*. Neither specifies the property this section is about: that the logs be verifiable by a party who does not trust their keeper. NIST’s AI RMF (AI 100-1) names maintaining training-data provenance as an aid to transparency and accountability; the mechanism is left open. ## 5. The numbers One quantitative constraint applies to any system that scores rare events, and it is worth stating with explicit assumptions because it is routinely misattributed to model quality. Axelsson’s analysis of intrusion detection ([CCS 1999 ](https://dl.acm.org/doi/10.1145/319709.319710)) formalized it: when the condition being detected is rare, the posterior probability that an alarm is genuine is dominated by the false-positive rate, not the detection rate — in his words, “the false alarm rate is the limiting factor.” The arithmetic is three lines of Bayes. Let prevalence be the fraction of screened items that are true positives, *d* the detection rate, and *f* the false-positive rate. The probability that a flagged item is a true positive is *pd* / (*pd* + (1−*p*)*f*). Take a deliberately favorable hypothetical: a screening population of 1,000,000, of whom 100 are true positives (*p* = 10⁻⁴), a detector with *d* = 0.99, and *f* = 0.01 — a 1% false-positive rate, which is strong for models over noisy, heterogeneous records. Then flagged items number 99 true and 9,999 false; the probability a given flag is genuine is about 0.98%. Cutting *f* tenfold, to 10⁻³, raises it only to about 9%. For the posterior to reach even two-thirds, *f* must approach *p* — for this population, a false-positive rate near 5×10⁻⁵, two orders of magnitude below the favorable assumption. These are properties of the base rate, not of any particular model, and they apply identically to medical screening for rare conditions. Section 2’s distinction matters here. The requirement as written is record linkage — its output is “look in system X” — and linkage precision is measurable and improvable against ground truth. But any layer that converts federated-match signals into a per-person score against a rare outcome inherits this arithmetic in full, and inherits it multiplied by the record volumes involved: the *Elhady* record puts the screening database at 1,160,000 identities. The numbers above say what the flag stream of any such layer would be made of. They say nothing about whether to build one; that is not an engineering question. ## 6. What evaluation has shown elsewhere Person-based predictive scoring has been independently evaluated twice at scale in U.S. policing, in both cases by an arm’s-length reviewer with access to internal data. Chicago’s Strategic Subject List was evaluated by RAND researchers (Saunders, Hunt, Hollywood, [ Journal of Experimental Criminology 12(3), 2016](https://link.springer.com/article/10.1007/s11292-016-9272-0)) using a quasi-experimental design on version 1 of the model — 426 individuals flagged in 2013. Subjects were no more or less likely to become homicide or shooting victims than matched comparisons; the model identified fewer than 1% of homicide victims in its window (3 of 405); subjects were 2.88 times more likely to be arrested for a shooting, an effect the authors’ mediation analysis attributed to the list’s use as an investigative lead source rather than to increased contact. The City of Chicago OIG’s [2020 advisory](https://igchicago.org/wp-content/uploads/2020/01/OIG-Advisory-Concerning-CPDs-Predictive-Risk-Models-.pdf)added the operational record: 399,412 people carried scores; scores went un-updated from August 2016 to January 2019; versions 2 through 5 were never evaluated by anyone; the program was decommissioned November 1, 2019. The LAPD’s Operation LASER chronic-offender program was reviewed by the LAPD Inspector General ([March 2019 ](https://www.lapdpolicecom.lacity.org/031219/BPC_19-0072.pdf)). Of individuals in the chronic-offender database with detailed point calculations, 44% had zero or one violent-crime arrest and about half had no gun-related arrests; site visits found the selection criteria applied inconsistently across areas; and the OIG concluded it could not evaluate the program’s effectiveness at all, citing a “lack of clear, reliable data” on both inputs and outcomes. Data entry into the chronic-offender database had been suspended in August 2018. Two evaluations do not generalize to all predictive systems. Their published findings are of two kinds: an outcome evaluation that measured no effect on the harm the program targeted (RAND, on SSL version 1), and operational reviews that documented a different problem: Chicago’s subsequent model versions went unevaluated and ran on unreliable, stale scores (the Chicago OIG), and the LAPD OIG found its records insufficient to evaluate LASER’s effectiveness at all. The second kind is a lineage finding. ## 7. Who would build it The RFI does not arrive into empty space. The TSC already buys analysis services at scale, and the notice describes an automation layer over data those services already work with. Two delivery orders, current as of August 8, 2026, define the landscape, both competed under multiple-award GSA Schedules with seven offers received, per [FPDS ](https://www.fpds.gov/) and [USAspending ](https://www.usaspending.gov/) records: BAE Systems Technology Solutions & Services holds order 15F06725F0001209 for TSC Intelligence Analysis Services, signed September 2, 2025, with an initial ceiling of $128.7M — reduced by three subsequent modifications to $122.0M, the last signed March 13, 2026 — and a potential period of performance to September 2030. IntelliWare Systems Inc. (parent: IntelliBridge LLC) holds order 15F06726F0000362, same service description, signed March 13, 2026, at $144.7M including options, with a potential period to October 2031. Both orders were competed through the Schedule fair-opportunity process, which does not produce public solicitations — consistent with the absence of public follow-on records for the RFI itself noted in Section 1. Whatever becomes of this market research, the plausible path runs through the same contracting channel, layered onto an ecosystem that is already occupied. ## 8. What does not exist Summarizing the teardown as a property table: | Property the requirement implies | Closest existing tooling | What it lacks | |---|---|---| | Record-level derivation graph | Provenance semirings, ProvSQL (research) | Standardization, integrity protection | | Pipeline lineage capture | OpenLineage, DataHub, Atlas, Marquez | Record granularity; store is mutable and assertion-based | | Tamper-evident history | CT (RFC 9162), Rekor, in-toto/SLSA, C2PA | Applies to certificates, software, media — not data-pipeline records | | Point-in-time state | Feature stores, bitemporal DBs, Delta time travel | Prospective correctness only; history administratively deletable | | Revocation propagation | — | Not defined in any tool surveyed here | | Cross-boundary verifiability | Transparency-log monitors/auditors | Not defined for federated record systems | Every row exists somewhere; no column is complete anywhere. One managed product that combined verifiable history with a database interface — Amazon QLDB — was retired by its vendor in 2025. *Predictive Modeling Using Enhanced Data with Traceable Lineage*, implemented to the standard its own wording sets — traceability to specific source data and enhancement logic, auditable lineage on every predictive output, across federated systems, on a records system whose retention schedule runs to 99 years — requires a combination the industry has built for certificates and software artifacts, and in signed-manifest form for media files, but not for records in ML pipelines: per-record cryptographic bindings anchored in an append-only, independently verifiable provenance log. I am currently writing a specification for that primitive, and it will be published separately. Whether any response to this Sources Sought proposes such a thing, and whether the eventual procurement — if there is one — holds vendors to the sentence as written, are questions the public record does not yet answer. The requirement is on the page. The tooling is not on the shelf.