Air Force readiness data.

The first modeling decision on an effort like this is one teams often skip: what does "current" mean. A continually ingested platform can answer as of this moment, as of the last complete ingest, or as of the reporting date a staff section would recognize. Those produce different numbers, and a commander comparing the platform against a briefed figure needs to know which question was answered. Modeling the assessment as a point-in-time object with an explicit effective date, rather than overwriting a status field, is what makes that answerable at all.

Retaining history is the other half of the same decision. A status field that gets overwritten cannot answer whether readiness improved, and improvement over time is most of what leadership asks about. Preserving snapshots as objects lets trend analysis fall out of queries rather than requiring a separate reporting warehouse, but only if the retention model is designed at the start. Reconstructing history after the fact is not possible from data that was overwritten.

Aggregation is where policy hides inside what looks like arithmetic. Rolling readiness up from unit to wing is not an average. Depending on the assessment, it may be the worst case, a weighted figure driven by mission-essential equipment, or a rule where any single failing category caps the whole. Those rules are policy decisions with authoritative sources behind them, and they belong encoded in the ontology where every application inherits the same answer, rather than reimplemented in each view by whoever built it.

Scenarios earn their place once the model holds. The recurring question is not only what readiness is now but what it becomes under a planned change: a deployment, a maintenance window, a personnel action. Projecting that requires a model where the inputs to an assessment are explicit objects rather than precomputed numbers, so a hypothetical change to one input propagates through the same aggregation rules the live picture uses. Programs that precompute readiness into a summary table cannot do this, and usually discover it late.

Readiness is not purely computed. Commanders make judgments that override what the source data implies, and those judgments carry authority. A platform that only reads is therefore incomplete: it produces a picture the chain of command then annotates somewhere else, reintroducing the parallel spreadsheet the effort was meant to retire.

Handling this properly means modeling the commander's assessment as a first-class object written back through an Action, with the author, the timestamp, and the justification captured alongside the computed value it supersedes. That preserves both numbers, which is what an inspector general or an audit needs, and keeps the override inside the system rather than beside it. It also requires the security model to permit write access along the chain of command without permitting it laterally, which is an ontology permissions question rather than an application one.

Department scale introduces a governance problem that unit-scale work never surfaces. Each source system has an owning office that controls its schema and release cadence, and none of those offices reports to whoever owns the readiness picture. Reference data makes this concrete: unit type codes, equipment categories, and status definitions are maintained elsewhere and change without notice to downstream consumers. Treating those as managed reference objects with explicit versions, rather than as strings copied into transforms, is the difference between a schema change being detected in a health check and being discovered by a commander looking at a number that moved for no reason. The governance model is not documentation produced after delivery. It is a design input, because it decides which parts of the object model any one team is permitted to change.