How We Work · Method
Assurance begins by stating exactly what must be true, and where.
Technical assurance starts with the property, mission consequence, boundary, evidence need, and acceptable residual uncertainty, then selects formal verification, analysis, test, review, or certification support proportionately. Compliance is an input; the objective is a defensible claim.
Property and boundary
An assurance claim has a property and a boundary or it is a slogan
“Secure,” “verified,” and “proven” mean nothing unqualified. The method begins by writing the claim precisely: which property must hold, at which boundary, under which assumptions, with what consequence if it fails. Everything else (method selection, evidence, cost) follows from that statement.
Proportionate methods
The risk selects the method
Formal specification and machine-checked verification are reserved for properties whose consequence justifies their cost: cryptographic cores, isolation boundaries, protocol state machines. Program analysis covers defect classes across wider surfaces. Automated verification and validation regenerate evidence on every change. Testing exercises real behavior in real environments; independent review challenges the argument itself.
Most systems need a portfolio, not a method. The assurance case is the document that says which method covers which property, and why that allocation matches the risk.
The assurance case
Evidence is assembled into an argument, not a pile
An assurance case connects the claim to the evidence: property, boundary, methods applied, results, coverage, and, critically, limitations and residual uncertainty. Proof, analysis, test, and validation are distinguished throughout, because they warrant different confidence and different words.
Certification support
Certification support, without borrowing the authority
Where a certification or authorization regime applies, the assurance case is built to serve it: evidence mapped to the framework's requirements, packaged for the evaluating authority. The decision remains the authority's. ExistX produces the evidence and the argument, and says exactly that, no more.
Residual risk
What was not covered is stated with what was
Every assurance result on an ExistX effort carries its limitation: assumptions, environments not exercised, properties out of scope, and the residual uncertainty the accepting authority is being asked to accept. Stating residual risk is not hedging. It is the difference between an assurance claim and an advertisement.
Claims boundaries
What this page does and does not claim
- “Secure,” “verified,” “proven,” and “certification-ready” are used only with a bounded property and evidence.
- Proof, analysis, test, validation, certification support, and decision authority are distinguished wherever results are described.
- Galois tool history is not transferred into ExistX corporate performance; method and tool attribution follows the work.
- Certification and authorization decisions belong to their authorities. ExistX provides engineering support and evidence.
Related
Where this connects
- Cryptographic EngineeringWhere the highest-consequence properties live, and formal methods earn their cost.
- Cybersecurity EngineeringWhere assurance evidence meets threat models, architecture, and authorization support.
- Software Engineering & ModernizationWhere automated testing and analysis protect the mission baseline through change.
- What We DeliverVerification evidence, cybersecurity evidence packages, and bounded certification-ready baselines as deliverable classes.
Next step
Request a technical discussion
Bring the property that must hold and the authority that must accept it. The assurance discussion starts there, not with a tool list.
Do not include classified, controlled, proprietary, export-controlled, or customer-sensitive information in any message sent through this site.