Warp Core.

The phrase "readiness data" implies a category of data that exists somewhere and needs collecting. It does not. Readiness is an assessment produced from personnel records, equipment status, training completion, medical qualification, and planning documents, each held in a different system, each maintained by a different office, each correct on its own terms and inconsistent with the others.

The specific failure is that these systems disagree about what a unit is. One tracks the unit as a manning document with authorized and assigned positions. Another tracks it as a maintenance activity with equipment on hand. A third tracks it as a training audience. Reorganizations land in these systems at different times and sometimes not at all. Asking what a unit's readiness is therefore requires first deciding which of several incompatible definitions of that unit is authoritative for the question being asked.

That decision is ontology work, and it is the whole job. Modeling the unit as an object with explicit link types to personnel, equipment, and training records preserves each source system's structure while making the relationships traversable. Echelon matters here and is routinely modeled wrong: the relationship between a squadron and the wing above it is a link type, not a column on the squadron record. Model it as a column and every question that crosses echelons becomes a special case. Model it as a link and aggregation up the hierarchy follows from the graph.

Cross-domain integration adds the constraint that makes this program harder than its commercial equivalents. Integrating across security levels and networks means the object model carries markings that govern which records a given user resolves at all, and those markings must survive every traversal. A query that aggregates readiness up an echelon has to produce a correct answer for a viewer cleared to see part of the underlying data, without leaking the existence of what they cannot see. That property is designed into the ontology or it is absent.

Programs of this class tend to be scoped and funded around a dashboard. The dashboard is visible, demonstrable, and the thing a commander asks for. It is also the least durable artifact produced. Workshop applications built on a sound object model take days. The same applications built on an unresolved object model take months and then get rebuilt when the next question arrives, because each one encodes its own private answer to a modeling question nobody settled.

The tell is a request for a readiness view that "just needs a couple more fields." If the fields require joining a source that was never modeled, the request is not a change to the application. It is a change to the ontology, and it will surface everywhere. Engineers who have delivered this work recognize the pattern early and price the object model as the deliverable, with the applications as what the object model makes cheap.

Ingestion cadence is the other underestimated piece, and the Department of the Air Force line item names it directly: continual automatic ingestion, not periodic upload. That distinction changes the engineering. A pipeline run monthly can be repaired by hand when a source system changes a field. A pipeline feeding a readiness picture that commanders check daily cannot, so schema drift has to be detected rather than discovered. Health checks on dataset freshness and row counts, versioned transforms with test coverage, and explicit handling for a source that goes quiet are the difference between a platform people trust and one they quietly stop opening.

Trust, in the end, is what determines whether any of this succeeds. A readiness system that is right most of the time gets checked against the spreadsheet it was meant to replace, and once a staff maintains both, the platform has failed regardless of its architecture. The engineering standard on this class of program is therefore higher than the demonstration suggests, because the system has to be correct on the edge cases a commander already knows about.