What We Deliver
The delivered system is more than the software.
ExistX combines four engineering disciplines and cross-cutting methods to produce high-assurance software-enabled mission systems, and the artifacts required to integrate, verify, sustain, and modernize them. The labels on this page describe classes of outputs; they are not proof of delivery.
Central category
High-Assurance Software-Enabled Mission Systems
The combined delivery category produced when the four disciplines work as one system. It is a system outcome — not a fifth discipline, a certification, or proof of deployment. One page defines the category: what the combined outcome contains, and the evidence needed to trust an instance of it.
Three layers
Deliverable classes, in three layers
System deliverables are what the mission operates. Engineering deliverables make the system buildable and testable. Assurance and sustainment deliverables make it trustworthy and maintainable. The work itself is tailored engineering. These are classes of output, not a product catalog.
System deliverables
- Modernized mission software
- Secure embedded systems
- Crypto-agile platforms
- Modular mission-system architectures
- Integrated hardware-software prototypes
- Interoperable system components
- Software-defined mission capabilities
- Upgradeable legacy platforms
- Cyber-resilient system baselines
Engineering deliverables
- System and software architectures
- Digital models and digital threads
- Open interface specifications
- Software APIs and component contracts
- Integration environments
- Modeling and simulation environments
- Automated test infrastructure
- Hardware-in-the-loop environments
- Technology and integration maturity evidence
Assurance and sustainment deliverables
- Verification and validation evidence
- Cybersecurity evidence packages
- Certification-ready baselines, only when bounded and approved
- Technical-data packages
- Configuration and provenance records
- Lifecycle sustainment strategies
- Modernization roadmaps
- Obsolescence and vendor-lock mitigation plans
Qualified terms keep their qualifications: “certification-ready” applies only when bounded and approved for a named baseline; “secure,” “interoperable,” and “Government-controlled” carry their boundary and evidence wherever they are used.
Evidence states
Every example carries its state
When a deliverable example appears on this site, it is labeled with an evidence state. Deliverable classes never substitute for evidence records.
- Deployed
- Demonstrated
- In Active Development
- Planned
- Conceptual
Provenance
Where deliverables come from
Deliverables come from the four disciplines working through the How We Work methods. Each class traces back to the disciplines that produce it and forward to the evidence that backs it.
- Cryptographic EngineeringConnects algorithm and key-management decisions to implementation, assurance, agility, embedded constraints, and lifecycle transition.
- Cybersecurity EngineeringIntegrates threat, architecture, software, components, evidence, and lifecycle decisions within a defined system boundary.
- Software Engineering & ModernizationMission-software and lifecycle engineering: architecture, modernization, DevSecOps, automated testing, assurance, migration, and incremental delivery.
- Systems Engineering & IntegrationConnects mission needs to architecture, embedded systems, interfaces, digital models, hardware-software integration, test, and lifecycle decisions.
- How We WorkThe methods that carry a deliverable from architecture through evidence.
- Work and evidenceApproved records stating what has actually been produced, in which environments, with what limitations.
Next step
Review work and evidence
Deliverable classes describe what ExistX can produce. Work records state what has been produced, by state, environment, and limitation. That distinction is the point.
Do not include classified, controlled, proprietary, export-controlled, or customer-sensitive information in any message sent through this site.