Army Vantage.

The instinct on hearing "180 data sources" is to picture 180 pipelines. That framing understates the problem by roughly an order of magnitude. Pipelines are the tractable part. The hard part is that those systems disagree about identity. Personnel appear under different identifiers in personnel, medical, training, and pay systems. Units appear under designations that changed during a reorganization one system tracked and another did not. Equipment appears with serial numbers recorded inconsistently across maintenance and supply.

Reconciling that disagreement is ontology work, not pipeline work, and confusing the two is the most common way these programs stall. A pipeline moves and shapes data. It cannot decide that the soldier in one system and the soldier in another are the same person, because that decision requires a definition of a soldier that the object model holds and every downstream application inherits. Get the object model right and the pipelines become mechanical. Get it wrong and every application built on it encodes the same ambiguity, separately.

The division of labor between Pipeline Builder and Code Repository follows from this. Feeds with stable schemas and declarative transforms belong in Pipeline Builder, where an analyst who understands the data can maintain them without an engineer. Entity resolution, custom matching logic, and anything requiring test coverage belongs in a Code Repository under version control. Teams that put everything in one or the other pay for it: all-declarative programs cannot test their matching logic, and all-code programs create a bottleneck where every schema change waits on an engineer.

Security markings are the constraint that most often gets deferred and most often should not be. A platform serving both Army and Joint users has to enforce, at the row and property level, which organization sees which record. That enforcement belongs in the object model, expressed as markings the platform applies to every query, rather than in application logic that a new Workshop module can forget to replicate. Programs that build the applications first and add the markings later end up revisiting every application, because access control written into a view does not survive the next view someone builds.

Scale also changes what a mistake costs. At 100,000 users, an object model revision is not a refactor. Applications, saved views, and downstream analyses all depend on the property names and link types that revision touches. This is why experienced teams treat the ontology as the interface it is, version it deliberately, and expand it additively rather than reshaping it. The instinct to clean up an imperfect object model is usually the wrong one at this scale.

A platform bought once, centrally, still has to be adopted command by command. Each adoption is a scoped body of work: map the systems of record, model the objects, build the transforms, validate the security markings, and deliver the applications the staff will actually open. That work is performed by primes and their subcontractors under task orders, not by the platform vendor.

The constraints on who can perform it are unusually specific. The data is frequently controlled, so the engineers need clearances. The schedule is set by an adoption deadline rather than by engineering estimate. And subcontracting plan requirements apply, which makes a cleared small business with genuine Foundry experience a scarcer thing than the size of the market would suggest.