Formal methods apply logic and discrete mathematics to specification, design and verification, descriptively (unambiguous formal specification) or deductively (explicit assumptions and inference steps that a tool can check), most effectively early (requirements and high-level design) and targeted by FFPA at, for example, concurrent protocols or fault-tolerant logic, proving full function or selected properties (often the absence of undesirable behaviour); tools are assessed or qualified per 11.4. Requirements are stated formally and a formal model of the component analysed against them, either by model checking (decidable temporal logic, automatic, a failed proof giving a counter-example) for error detection, or by richer proof-based approaches (possibly on a synthesisable HDL model) for error preclusion. A successful proof completes the activity with assurance depending on model fidelity; every counter-example is resolved by correcting design or requirements, showing it unrealisable or using another method, then re-proving, and a tool that reports only one counter-example needs the process adapted to find the rest; where neither proof nor counter-example is found, simplify the design or split cases between proof and other means, feeding changes back to the FFPA. Data covers the approach and targets, formal requirements, models, proofs or proof scripts correlated in the traceability data, tools and their assessment, tests and requirements added, and the completeness achieved with unresolved discrepancies justified.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.