The federal-engineering
vocabulary, plain.
Terms we use across the site, defined in plain language. For federal readers this is review; for everyone else it's a quick way to follow the writing without a defense-acquisition decoder ring.
A
- Acquisition programProcess
- A directed, funded effort to acquire a new system or capability. In the federal context, programs move through phased milestones with formal review gates. The phases include the engineering decisions, contracting actions, and operational tests that lead to a fielded system.
C
- Common Operating PictureCOPMission Data
- A shared situational display that integrates data from multiple sources so distributed teams reason from the same view. Good COPs preserve the operational distinctions analysts care about; poor ones flatten everything to a single object class and lose meaning at the boundary.
- Concept of OperationsCONOPSArchitecture
- A document describing how a capability will be used in the field — who operates it, under what conditions, in service of what mission. CONOPS bridges between high-level mission needs and detailed system requirements.
- Counter-Unmanned Aircraft SystemsC-UASMission Domain
- Capabilities for detecting, identifying, tracking, and (when authorized) defeating unmanned aerial systems. Spans sensors, classifiers, command-and-control, and effectors — typically integrated under tight latency and rules-of-engagement constraints.
D
- Defensible engineeringOCEANS terminology
- Engineering whose conclusions survive technical, operational, and executive review. Every recommendation traces to a validated requirement; every metric was measured the way it was measured for a documented reason. We use this phrase a lot.
- DOTMLPF-PProcess
- Doctrine, Organization, Training, Materiel, Leadership, Personnel, Facilities, and Policy — the dimensions DoD uses to analyze whether a capability gap requires a materiel solution or a non-materiel one. Acquisition decisions usually inspect each dimension.
F
- Five EyesFVEYInternational
- The intelligence-sharing alliance comprising the United States, United Kingdom, Canada, Australia, and New Zealand. References to FVEY on this site typically mean engagements with allied partners in those nations.
I
- Intelligence, Surveillance, and ReconnaissanceISRMission Domain
- The activities and systems that gather, process, and disseminate information for decision-making. ISR ranges from satellite imagery to ground sensors to operator reports.
M
- Measures of EffectivenessMOET&E
- Mission-level metrics that indicate whether a capability achieves its intended operational outcome. MOEs are tied to what an operator or commander cares about — distinct from sub-system performance metrics.
- Measures of PerformanceMOPT&E
- Sub-system or component-level metrics that indicate whether a piece of the capability performs to specification. Many MOPs roll up into a single MOE.
O
- Ontology (data)Mission Data
- A formal model that defines the entities, attributes, and relationships a data system represents. Ontology-driven architectures preserve the distinctions operators care about — instead of flattening everything to a single object class during ingestion.
- Operational Test and EvaluationOT&ET&E
- Testing performed by operational users (rather than developers) under realistic conditions, to determine whether a system meets mission needs. OT&E produces the evidence that informs fielding decisions and is independent from developmental testing.
R
- Rules of EngagementROEOperations
- The authorities and constraints that govern when force or specific actions may be applied. ROE shape the operational logic of a system — particularly anything involving classification, tracking, or response to identified threats.
S
- Sea stateMaritime
- A standardized scale (0 through 9) describing wave height, wind speed, and ocean conditions. Sea state is a common condition variable in maritime test requirements — performance claims often depend on which sea states a system is qualified against.
T
- Technology Readiness LevelTRLArchitecture
- A 1–9 scale describing how mature a technology is, from basic principles observed (TRL 1) to a system proven in operational use (TRL 9). TRL assessments inform whether a capability is ready to transition to fielding or needs more development.
- Test planT&E
- The structured document specifying what will be tested, under what conditions, against which thresholds, and how the data will be analyzed. A good test plan is approved before testing begins; a post-hoc test plan is a story written to fit the data.
- Threshold / ObjectiveT&E
- Threshold is the minimum acceptable level of performance. Objective is the desired level. Requirements that state only thresholds tell you when something fails — they don't tell you when it succeeds well.
- Traceability matrixRequirements
- A live document linking every requirement back to a validated mission need and forward to the test that verifies it. The matrix exists to answer 'why are we doing this?' for every engineering choice — not as a deliverable, but as a query interface.
W
- White Team / Blue Team / Red TeamT&E
- In an operational test: Blue is the operators using the system as they would in the field. Red is the adversarial play (threats, attackers). White sits between them — runs the engagement, records observations, enforces the test design, keeps the assessment honest.
Missing a term?
Tell us — we'll add it. This glossary is here to make the rest of the site readable, not to be a definitive reference.