Formal Methods and Machine-Checked Reasoning: How Computation Can Be Verified

Last Updated June 17, 2026

Formal methods bring mathematical rigor into the design, analysis, verification, and governance of computational systems. They ask whether programs, protocols, algorithms, models, and workflows can be specified precisely enough that their properties can be checked by formal proof, automated search, model exploration, type discipline, or machine-checked reasoning.

Machine-checked reasoning extends this discipline by using software tools to verify formal claims. A proof assistant can check whether a proof follows from definitions and rules. A model checker can search a state space for violations. A solver can test whether constraints are satisfiable. A type checker can reject invalid programs before they run. A formal specification can make assumptions, states, invariants, and intended behavior explicit.

Formal methods matter because computational systems increasingly operate inside infrastructure, science, finance, medicine, public administration, artificial intelligence, security, and institutional decision-making. When systems become consequential, “it seems to work” is not enough. We need stronger evidence about what was specified, what was checked, what was proved, what remains unknown, and what still requires human interpretation.

This article explains formal methods and machine-checked reasoning as disciplines for making computational claims explicit, testable, and reviewable. It introduces specifications, preconditions, postconditions, invariants, proof obligations, model checking, proof assistants, theorem proving, SAT and SMT solving, type systems, contracts, refinement, static analysis, counterexamples, formal verification, assumptions, limits, and governance. It emphasizes that formal methods do not remove judgment. They make the boundary between formal evidence and interpretation clearer.

Why Formal Methods Matter

Formal methods matter because complex systems often fail in ways that ordinary testing does not reveal. A program may pass many tests but still fail under an untested input, concurrency interleaving, invalid state, boundary condition, numerical edge case, or misunderstood requirement. Formal methods help move from example-based confidence toward structured evidence.

They do this by making computational claims precise. What should the system do? Under what assumptions? What inputs are valid? What states are reachable? What properties must always hold? What outcomes are forbidden? What does the implementation guarantee? What evidence supports that guarantee?

Formal methods do not guarantee that the real-world goal is wise, ethical, complete, or contextually appropriate. They help verify formal claims within stated assumptions.

Back to top ↑

What Formal Methods Are

Formal methods are mathematically grounded techniques for specifying, modeling, verifying, and reasoning about computational systems. They include formal specification languages, proof systems, model checkers, type systems, theorem provers, proof assistants, decision procedures, refinement methods, and static analysis.

The common feature is explicit formal structure. Instead of relying only on prose requirements, informal intuition, manual inspection, or test examples, formal methods represent claims in forms that can be checked by rules.

Formal methods replace vague confidence with structured evidence. The quality of that evidence depends on the quality of the formalization.

Back to top ↑

Specifications

A specification states what a system is expected to do. It may describe valid inputs, required outputs, state transitions, safety properties, liveness properties, invariants, timing expectations, resource constraints, data assumptions, or policy rules.

Specifications are not merely documentation. In formal methods, a specification can become an object of reasoning. A program, protocol, or model can be checked against it.

A specification is only useful if it states the right property. A system can satisfy a formal specification and still fail the real purpose if the specification is incomplete or wrong.

Back to top ↑

Preconditions, Postconditions, and Invariants

Preconditions, postconditions, and invariants are core tools for formal reasoning. A precondition states what must be true before a procedure runs. A postcondition states what must be true after it finishes. An invariant states what must remain true throughout execution or across state transitions.

These tools connect algorithms to proof, testing, debugging, and governance. They force a procedure to state what it assumes and what it promises.

Back to top ↑

Proof Obligations

A proof obligation is a formal claim that must be established for a verification effort to succeed. When a program is checked against a specification, the verification system may generate obligations such as: the precondition is strong enough, the postcondition follows, an invariant is preserved, a loop terminates, or a data constraint is maintained.

Proof obligations are valuable because they turn broad correctness claims into smaller, checkable claims.

Proof obligations make verification auditable. Instead of saying “the system is verified,” a team can show which obligations were generated, which were discharged, and which remain open.

Back to top ↑

Machine-Checked Reasoning

Machine-checked reasoning uses computational systems to verify formal reasoning. The machine does not need to understand the social purpose of the system. It checks whether formal claims follow from formal rules.

This is powerful because human proofs, specifications, and reviews can contain mistakes. A machine checker can enforce rigor at a level that informal reading cannot provide. But the checker only verifies the formal artifact. It does not decide whether the artifact captures the full real-world problem.

Machine-checked reasoning is strongest when paired with clear interpretation boundaries.

Back to top ↑

Proof Assistants

Proof assistants are systems that help users construct and check formal proofs. They often use expressive type theories or higher-order logics. Users define objects, state theorems, build proof terms, apply tactics, and rely on a small trusted kernel to check proof validity.

Proof assistants are used in formal mathematics, verified software, compiler verification, cryptographic proof, programming-language semantics, hardware reasoning, and safety-critical systems.

A proof assistant does not make proof effortless. It makes proof explicit enough to be checked.

Back to top ↑

Model Checking

Model checking verifies whether a formal model satisfies a property. The model usually describes states and transitions. The property may express safety, liveness, reachability, fairness, timing, or temporal behavior.

Model checking is especially useful when systems have many possible paths: concurrent programs, distributed protocols, hardware circuits, control systems, workflow engines, and communication protocols.

Model checking can produce powerful evidence, but the evidence applies to the model. If the model omits a real-world condition, the checked result may still be incomplete.

Back to top ↑

SAT, SMT, and Decision Procedures

SAT solvers decide whether Boolean formulas are satisfiable. SMT solvers extend satisfiability solving with background theories such as arithmetic, arrays, bit-vectors, strings, and uninterpreted functions. Decision procedures are algorithms for deciding specific formal theories or fragments.

These tools support model checking, symbolic execution, bounded verification, test generation, compiler optimization, scheduling, configuration, hardware verification, security analysis, and constraint reasoning.

Solver output is not automatically a real-world conclusion. It is a formal result about the encoded constraints.

Back to top ↑

Type Systems and Contracts

Type systems are everyday formal methods. They classify values and expressions so invalid uses can be rejected before execution. Contracts, assertions, preconditions, postconditions, and refinement types extend this discipline by adding richer behavioral conditions.

A type checker is a machine-checked reasoning system. It proves that a program obeys certain structural rules. More expressive type systems can encode stronger guarantees, but they can also require more annotation, expertise, and proof effort.

Type systems and contracts show that formal methods are not separate from ordinary programming. They are often built into the language and workflow.

Back to top ↑

Refinement and Implementation

Refinement connects abstract specifications to concrete implementations. An abstract model may describe what a system should do without specifying every implementation detail. A refined design adds detail while preserving the abstract behavior. The implementation should refine the specification rather than contradict it.

Refinement is especially important because a system can be correct at one level and fail at another if assumptions shift.

Back to top ↑

Counterexamples and Failure Evidence

Formal methods are not only about proof. They are also powerful tools for finding failures. A counterexample is structured evidence showing that a property does not hold. In model checking, it may be a path through states. In constraint solving, it may be a satisfying assignment that violates an expected condition. In testing, it may be a minimized input that exposes failure.

Counterexamples are valuable because they make abstract failure concrete.

A well-governed formal-methods workflow preserves counterexamples, traces, solver results, assumptions, and unresolved obligations.

Back to top ↑

Limits of Formal Methods

Formal methods have limits. Some properties are undecidable in general. Some state spaces are too large to explore exhaustively. Some specifications are incomplete. Some tools require expertise. Some proof efforts are expensive. Some assumptions fail when software enters a real environment.

The most important limit is representational: formal methods verify what has been formalized. They do not automatically verify the informal human purpose behind the formalization.

Formal methods are strongest when they are presented as rigorous evidence within scope, not as magic certainty.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A central form of program specification is the Hoare triple:

Invariant preservation can be represented as:

Model checking asks:

Refinement relates implementation to specification:

Solver-based verification often checks unsatisfiability:

These formulas show the core pattern: state a claim formally, then check whether it follows from defined assumptions and rules.

Back to top ↑

Python Workflow: Formal Methods Audit

The Python workflow below creates a dependency-light audit for formal-methods claims. It scores specification clarity, assumption documentation, invariant strength, proof-obligation traceability, machine-check status, counterexample handling, model-scope clarity, implementation-refinement evidence, unknown-status handling, and governance readiness.

# formal_methods_audit.py
# Dependency-light workflow for evaluating formal-methods and machine-checked reasoning claims.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class FormalMethodsCase:
    case_name: str
    verification_context: str
    formal_claim: str
    specification_clarity: float
    assumption_documentation: float
    invariant_strength: float
    proof_obligation_traceability: float
    machine_check_status: float
    counterexample_handling: float
    model_scope_clarity: float
    refinement_evidence: float
    unknown_status_handling: float
    governance_readiness: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def formal_methods_quality(case: FormalMethodsCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.specification_clarity
            + 0.10 * case.assumption_documentation
            + 0.10 * case.invariant_strength
            + 0.12 * case.proof_obligation_traceability
            + 0.12 * case.machine_check_status
            + 0.10 * case.counterexample_handling
            + 0.10 * case.model_scope_clarity
            + 0.08 * case.refinement_evidence
            + 0.08 * case.unknown_status_handling
            + 0.08 * case.governance_readiness
        )
    )


def verification_overclaim_risk(case: FormalMethodsCase) -> float:
    weak_points = [
        1.0 - case.specification_clarity,
        1.0 - case.assumption_documentation,
        1.0 - case.proof_obligation_traceability,
        1.0 - case.machine_check_status,
        1.0 - case.model_scope_clarity,
        1.0 - case.refinement_evidence,
        1.0 - case.unknown_status_handling,
        1.0 - case.governance_readiness,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 82 and risk <= 22:
        return "strong formal-methods posture with clear machine-checked evidence and interpretation boundaries"
    if quality >= 68 and risk <= 38:
        return "usable formal-methods posture with review needs"
    if risk >= 55:
        return "high verification-overclaim risk; formal evidence or scope may be unclear"
    return "partial formal-methods posture; strengthen specification, obligations, machine checks, scope, or governance"


def build_cases() -> list[FormalMethodsCase]:
    return [
        FormalMethodsCase(
            case_name="Verified sorting function",
            verification_context="Function is checked against sortedness and permutation properties.",
            formal_claim="The output is sorted and contains the same elements as the input.",
            specification_clarity=0.88,
            assumption_documentation=0.80,
            invariant_strength=0.84,
            proof_obligation_traceability=0.86,
            machine_check_status=0.84,
            counterexample_handling=0.78,
            model_scope_clarity=0.80,
            refinement_evidence=0.76,
            unknown_status_handling=0.74,
            governance_readiness=0.78,
        ),
        FormalMethodsCase(
            case_name="Protocol model checking",
            verification_context="A distributed protocol model is checked for unsafe reachable states.",
            formal_claim="No modeled execution path reaches an unsafe agreement state.",
            specification_clarity=0.82,
            assumption_documentation=0.78,
            invariant_strength=0.80,
            proof_obligation_traceability=0.78,
            machine_check_status=0.86,
            counterexample_handling=0.90,
            model_scope_clarity=0.76,
            refinement_evidence=0.70,
            unknown_status_handling=0.78,
            governance_readiness=0.80,
        ),
        FormalMethodsCase(
            case_name="SMT-backed contract check",
            verification_context="A solver checks whether function contracts can be violated.",
            formal_claim="No satisfying assignment violates the encoded contract within the supported theory.",
            specification_clarity=0.84,
            assumption_documentation=0.76,
            invariant_strength=0.74,
            proof_obligation_traceability=0.82,
            machine_check_status=0.86,
            counterexample_handling=0.84,
            model_scope_clarity=0.78,
            refinement_evidence=0.72,
            unknown_status_handling=0.76,
            governance_readiness=0.76,
        ),
        FormalMethodsCase(
            case_name="Institutional rule verification",
            verification_context="A rule-governed workflow is checked for consistency and escalation behavior.",
            formal_claim="Clear cases are classified consistently and ambiguous cases are routed for review.",
            specification_clarity=0.78,
            assumption_documentation=0.74,
            invariant_strength=0.70,
            proof_obligation_traceability=0.76,
            machine_check_status=0.70,
            counterexample_handling=0.76,
            model_scope_clarity=0.78,
            refinement_evidence=0.68,
            unknown_status_handling=0.86,
            governance_readiness=0.88,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = formal_methods_quality(case)
        risk = verification_overclaim_risk(case)
        rows.append({
            **asdict(case),
            "formal_methods_quality": round(quality, 3),
            "verification_overclaim_risk": round(risk, 3),
            "diagnostic": diagnose(quality, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_formal_methods_quality": round(mean(float(row["formal_methods_quality"]) for row in rows), 3),
        "average_verification_overclaim_risk": round(mean(float(row["verification_overclaim_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["formal_methods_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["verification_overclaim_risk"]))["case_name"],
        "interpretation": "Formal-methods quality depends on specification clarity, documented assumptions, invariants, proof obligations, machine checks, counterexamples, model scope, refinement evidence, unknown-status handling, and governance."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)

    write_csv(TABLES / "formal_methods_audit.csv", rows)
    write_csv(TABLES / "formal_methods_audit_summary.csv", [summary])
    write_json(JSON_DIR / "formal_methods_audit.json", rows)
    write_json(JSON_DIR / "formal_methods_audit_summary.json", summary)

    print("Formal methods audit complete.")
    print(TABLES / "formal_methods_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats formal methods as structured evidence. It asks whether the claim, assumptions, proof obligations, machine checks, counterexamples, and governance boundaries are explicit.

Back to top ↑

R Workflow: Verification Evidence Summary

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares formal-methods quality and verification-overclaim risk across synthetic systems.

# formal_methods_summary.R
# Base R workflow for summarizing formal-methods and machine-checked reasoning claims.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "formal_methods_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_formal_methods_quality = mean(data$formal_methods_quality),
  average_verification_overclaim_risk = mean(data$verification_overclaim_risk),
  highest_quality_case = data$case_name[which.max(data$formal_methods_quality)],
  highest_risk_case = data$case_name[which.max(data$verification_overclaim_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_formal_methods_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$formal_methods_quality,
  data$verification_overclaim_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Formal-methods quality", "Verification-overclaim risk")

png(
  file.path(figures_dir, "formal_methods_quality_vs_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Formal Methods Quality vs. Verification Overclaim Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "formal_methods_dimensions.png"),
  width = 1400,
  height = 800
)

dimension_means <- colMeans(data[, c(
  "specification_clarity",
  "assumption_documentation",
  "invariant_strength",
  "proof_obligation_traceability",
  "machine_check_status",
  "counterexample_handling",
  "model_scope_clarity",
  "refinement_evidence",
  "unknown_status_handling",
  "governance_readiness"
)]) * 100

barplot(
  dimension_means,
  las = 2,
  ylim = c(0, 100),
  ylab = "Average score",
  main = "Average Formal-Methods Evidence by Dimension"
)

grid()
dev.off()

print(summary_table)

This workflow helps compare proof-assisted verification, model checking, solver-backed contract checking, rule-engine verification, and other formal-methods cases by how clearly they expose formal evidence and limits.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, and formal-methods diagnostics that extend the article into executable examples.

articles/formal-methods-and-machine-checked-reasoning/
├── python/
│   ├── formal_methods_audit.py
│   ├── proof_obligation_examples.py
│   ├── invariant_checker_examples.py
│   ├── model_checking_examples.py
│   ├── refinement_examples.py
│   ├── calculators/
│   │   ├── formal_methods_quality_calculator.py
│   │   └── verification_overclaim_risk_calculator.py
│   └── tests/
├── r/
│   ├── formal_methods_summary.R
│   ├── verification_evidence_visualization.R
│   └── proof_obligation_report.R
├── julia/
│   ├── formal_specification_examples.jl
│   └── invariant_audit_examples.jl
├── sql/
│   ├── schema_formal_methods_cases.sql
│   ├── schema_proof_obligations.sql
│   └── formal_methods_queries.sql
├── haskell/
│   ├── SpecificationTypes.hs
│   ├── VerificationEvidence.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── formal_methods_audit.c
├── cpp/
│   └── formal_methods_audit.cpp
├── fortran/
│   └── verification_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── proof_obligation_rules.pl
├── racket/
│   └── machine_checked_reasoning_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── formal-methods-and-machine-checked-reasoning.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_formal_methods_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── formal_methods_and_machine_checked_reasoning_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Formal-Methods Review

A practical formal-methods review begins by separating the formal claim from the broader real-world claim. The formal claim can be checked. The broader claim must be interpreted.

Formal-methods review is not only a technical workflow. It is an evidence discipline.

Back to top ↑

Common Pitfalls

A common pitfall is treating formal verification as total verification. A proved theorem may apply only to a model, a function, a language subset, a property, or a set of assumptions. It may not cover hardware faults, deployment context, misunderstood requirements, adversarial misuse, human workflows, or institutional consequences.

Another pitfall is hiding failed obligations. Verification is most useful when open questions remain visible.

Common pitfalls include:

• specification error: proving that the system satisfies the wrong property;
• model mismatch: checking a model that omits important real-world behavior;
• scope overclaim: presenting a limited proof as broad system assurance;
• tool opacity: failing to explain what a proof assistant, solver, or model checker actually checked;
• unknown-status suppression: treating timeouts or unproved obligations as success;
• counterexample loss: failing to preserve traces that show how a property can fail;
• assumption drift: deploying a system after assumptions have changed;
• verification without governance: proving a property once but not maintaining evidence over time;
• formalism without purpose: using sophisticated tools without a meaningful specification;
• ignoring human interpretation: treating machine-checked evidence as self-explanatory.

The remedy is explicit scope, visible assumptions, preserved evidence, documented unknowns, and careful interpretation.

Back to top ↑

Why Machine-Checked Reasoning Still Needs Judgment

Formal methods and machine-checked reasoning are among the strongest tools available for reliable computation. They can expose assumptions, generate proof obligations, check proofs, explore states, find counterexamples, verify models, constrain programs, and preserve evidence. They help make computational reasoning more rigorous than intuition, testing, or review alone.

But formal methods do not eliminate judgment. Someone must decide what to specify, which model to use, which assumptions matter, which properties are worth proving, which risks remain, and how formal evidence should affect real decisions. The machine can check whether a claim follows within a formal system. It cannot decide whether the formal system captures the whole human, institutional, scientific, or ethical situation.

The value of formal methods is therefore not absolute certainty. Their value is disciplined clarity: what was specified, what was checked, what was proved, what failed, what remains unknown, and where human responsibility begins.

Back to top ↑

Related Articles

• Logic and Computation
• Formal Languages and Symbolic Representation
• Proof, Correctness, and Algorithmic Verification
• Termination, Invariants, and Edge Cases
• Computability and the Limits of Procedure
• The Halting Problem and the Limits of Automation
• Automated Reasoning and Mechanical Inference
• Lambda Calculus, Functions, and Formal Computation
• Representation and the Shape of Computation

Further Reading

• Apt, K.R. and Olderog, E.-R. (2019) Verification of Sequential and Concurrent Programs. 3rd edn. Cham: Springer. Available at: SpringerLink.
• Baier, C. and Katoen, J.-P. (2008) Principles of Model Checking. Cambridge, MA: MIT Press. Available at: MIT Press.
• Bertot, Y. and Castéran, P. (2004) Interactive Theorem Proving and Program Development: Coq’Art: The Calculus of Inductive Constructions. Berlin: Springer. Available at: SpringerLink.
• Clarke, E.M., Grumberg, O. and Peled, D.A. (1999) Model Checking. Cambridge, MA: MIT Press. Available at: MIT Press.
• Dijkstra, E.W. (1976) A Discipline of Programming. Englewood Cliffs, NJ: Prentice-Hall. Related archive available at: Edsger W. Dijkstra Archive.
• Floyd, R.W. (1967) ‘Assigning meanings to programs’, in Schwartz, J.T. (ed.) Mathematical Aspects of Computer Science. Providence, RI: American Mathematical Society, pp. 19–32. Conference record information available through: American Mathematical Society.
• Hoare, C.A.R. (1969) ‘An axiomatic basis for computer programming’, Communications of the ACM, 12(10), pp. 576–580. Available at: ACM Digital Library.
• Huth, M. and Ryan, M. (2004) Logic in Computer Science: Modelling and Reasoning about Systems. 2nd edn. Cambridge: Cambridge University Press. Available at: Cambridge University Press.
• Kroening, D. and Strichman, O. (2016) Decision Procedures: An Algorithmic Point of View. 2nd edn. Berlin: Springer. Available at: SpringerLink.
• Nipkow, T., Paulson, L.C. and Wenzel, M. (2002) Isabelle/HOL: A Proof Assistant for Higher-Order Logic. Berlin: Springer. Available at: SpringerLink.
• Pierce, B.C. et al. (2024) Software Foundations. Electronic textbook series. Available at: University of Pennsylvania.
• Wing, J.M. (1990) ‘A specifier’s introduction to formal methods’, Computer, 23(9), pp. 8–23. Available at: IEEE Xplore.

References

• Apt, K.R. and Olderog, E.-R. (2019) Verification of Sequential and Concurrent Programs. 3rd edn. Cham: Springer. Available at: https://link.springer.com/book/10.1007/978-1-84882-745-5.
• Baier, C. and Katoen, J.-P. (2008) Principles of Model Checking. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262026499/principles-of-model-checking/.
• Bertot, Y. and Castéran, P. (2004) Interactive Theorem Proving and Program Development: Coq’Art: The Calculus of Inductive Constructions. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/978-3-662-07964-5.
• Clarke, E.M., Grumberg, O. and Peled, D.A. (1999) Model Checking. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262032704/model-checking/.
• Dijkstra, E.W. (1976) A Discipline of Programming. Englewood Cliffs, NJ: Prentice-Hall. Related archive available at: https://www.cs.utexas.edu/users/EWD/.
• Floyd, R.W. (1967) ‘Assigning meanings to programs’, in Schwartz, J.T. (ed.) Mathematical Aspects of Computer Science. Providence, RI: American Mathematical Society, pp. 19–32. Conference record available at: https://www.ams.org/books/pspum/019/.
• Hoare, C.A.R. (1969) ‘An axiomatic basis for computer programming’, Communications of the ACM, 12(10), pp. 576–580. doi: 10.1145/363235.363259.
• Huth, M. and Ryan, M. (2004) Logic in Computer Science: Modelling and Reasoning about Systems. 2nd edn. Cambridge: Cambridge University Press. Available at: https://www.cambridge.org/core/books/logic-in-computer-science/2A99F074DDF91A7436C01B63BCA7D345.
• Kroening, D. and Strichman, O. (2016) Decision Procedures: An Algorithmic Point of View. 2nd edn. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/978-3-662-50497-0.
• Nipkow, T., Paulson, L.C. and Wenzel, M. (2002) Isabelle/HOL: A Proof Assistant for Higher-Order Logic. Berlin: Springer. Available at: https://link.springer.com/book/10.1007/3-540-45949-9.
• Pierce, B.C. et al. (2024) Software Foundations. Electronic textbook series. Available at: https://softwarefoundations.cis.upenn.edu/.
• Wing, J.M. (1990) ‘A specifier’s introduction to formal methods’, Computer, 23(9), pp. 8–23. Available at: https://ieeexplore.ieee.org/document/58215.

Back to top ↑