Problems, Procedures, and Formalization: Turning Questions into Algorithms

Last Updated June 17, 2026

Problems rarely arrive in computational form. They usually begin as questions, goals, frustrations, needs, observations, or institutional pressures: find the best route, detect fraud, rank documents, allocate resources, simulate disease spread, classify images, predict demand, schedule workers, summarize text, or decide who receives attention. Before any algorithm can act, the problem has to be formalized. It must be translated into inputs, outputs, constraints, states, operations, objectives, assumptions, and stopping conditions.

That translation is not a minor setup step. It is one of the most important acts in computational reasoning. The procedure can only solve the problem as it has been formalized. If the formalization is too narrow, misleading, incomplete, or poorly aligned with the real-world purpose, the algorithm may execute correctly while solving the wrong problem. Formalization turns ambiguity into procedure, but it also shapes what computation can see, ignore, measure, optimize, and return.

This article explains how ambiguous questions become explicit computational tasks. It examines the difference between a real-world problem, a formal problem, and an executable procedure. It shows why computational reasoning begins before coding: with careful attention to representation, scope, input design, output meaning, assumptions, edge cases, stopping conditions, and interpretive limits. It also provides examples from search, scheduling, public policy, databases, machine learning, simulation, and institutional workflows.

Why Formalization Matters

Formalization matters because algorithms do not solve vague problems directly. They solve formal tasks. A real-world concern must be translated into a computational form before a procedure can operate on it. That translation determines what counts as input, what counts as output, what relationships are visible, what constraints apply, what trade-offs matter, and what kind of result will be considered successful.

A routing app does not solve “mobility” in general. It solves a formalized route-selection problem using maps, road segments, traffic estimates, constraints, and objective functions. A search engine does not solve “knowledge” in general. It solves a formalized retrieval and ranking problem using documents, queries, indexes, signals, and relevance models. A hiring tool does not solve “talent” in general. It solves a formalized scoring or classification problem based on selected features, historical data, and institutional assumptions.

The danger is that the formalized task can be mistaken for the whole problem. Once a problem is converted into variables and rules, the computational structure can feel precise. But precision is not the same as adequacy. A narrow formalization can produce clean outputs while ignoring the most important parts of the original concern.

Formalization is therefore both technical and interpretive. It is technical because computation requires explicit structure. It is interpretive because that structure is chosen. Responsible computational reasoning keeps that choice visible.

Back to top ↑

From Problem to Procedure

The path from problem to procedure has several stages. First, a real-world concern is described. Second, the concern is narrowed into a computational task. Third, the task is represented through data structures, variables, states, constraints, and objectives. Fourth, a procedure is designed to operate on that representation. Fifth, the output is evaluated and interpreted.

This sequence is easy to rush. In many technical environments, people move quickly from a problem statement to a coding task. But a procedure written too early can freeze weak assumptions into software. A bad formalization becomes harder to challenge once it is embedded in code, data pipelines, dashboards, interfaces, contracts, or institutional routines.

A simple procedure may follow a clean sequence:

1. receive input;
2. validate input;
3. apply rules;
4. update state;
5. produce output;
6. stop when a condition is met.

But computational reasoning asks how each part was chosen. What counts as valid input? What rules are justified? What states matter? What output is meaningful? What stopping condition is appropriate? What happens when the input is incomplete, noisy, adversarial, biased, stale, ambiguous, or outside the expected range?

A procedure is not just a list of steps. It is the executable expression of a formalization. To understand the procedure, we have to understand the formal problem behind it.

Back to top ↑

Real-World Problems vs. Formal Problems

A real-world problem is usually broad, contextual, and partly ambiguous. A formal problem is explicit, bounded, and computable. Moving from one to the other requires simplification. That simplification can be useful, but it must be documented and evaluated.

For example, “improve public transportation access” is a broad real-world goal. It may involve route coverage, affordability, reliability, accessibility, safety, land use, neighborhood history, employment patterns, and political decision-making. A formal computational task might be: given a transit network, travel-time estimates, population data, and budget constraints, choose route changes that reduce average commute time. That task is computable, but it is not the whole public transportation problem.

The formal task can be useful if it is understood as one lens. It becomes risky when the lens is mistaken for the full reality.

The point is not that formalization is bad. Without formalization, computation cannot proceed. The point is that formalization is a choice. Every choice needs scope, evidence, and interpretation.

Back to top ↑

Inputs, Outputs, and Constraints

Inputs, outputs, and constraints define the boundary of a computational task. Inputs are what the procedure receives. Outputs are what it returns. Constraints define what is allowed, forbidden, limited, required, or feasible.

An input can be a number, text, image, graph, table, document, event stream, sensor reading, user profile, policy rule, or model parameter. But input is never neutral. It has a source, format, history, scale, unit, uncertainty, and missingness pattern. Computational reasoning asks whether the input is appropriate for the task.

Outputs also need careful definition. A procedure might return a score, label, ranked list, route, schedule, forecast, recommendation, alert, allocation, cluster, or simulation trace. The output must match the intended use. A score designed for triage should not be treated as a final judgment. A forecast designed for scenario comparison should not be treated as certainty.

Constraints matter because many computational tasks are not simply about producing any answer. They are about producing an answer within limits: budget, time, memory, fairness, safety, latency, legal rules, physical feasibility, or institutional capacity.

Good formalization makes these components explicit. Poor formalization hides them inside code, model parameters, database fields, defaults, dashboards, or user interfaces.

Back to top ↑

States, Operations, and Transitions

Many computational problems involve states. A state is a description of the system at a given moment or step. An operation changes the state. A transition describes how one state becomes another. This way of thinking is central to algorithms, simulations, games, planning systems, workflow automation, dynamic programming, agent-based models, databases, and distributed systems.

A state might be the current location in a search problem, the current arrangement of a puzzle, the current inventory level in a supply chain, the current queue of tasks in a workflow, the current belief distribution in a probabilistic model, or the current configuration of a machine.

Algorithmic thinking asks how to move from state to state. Computational reasoning asks whether the state representation is adequate. What features are included? What history is remembered? What information is lost? Can the state represent uncertainty? Can it handle missing data? Does it treat people, documents, organizations, or environments too simply?

State-based thinking helps clarify procedure because it makes change explicit. It also reveals formalization risk: if the state representation is wrong, every transition built on that state may be misleading.

Back to top ↑

Objectives and Evaluation

Many computational procedures are guided by objectives. An objective defines what the procedure is trying to achieve: minimize cost, maximize relevance, reduce error, improve accuracy, increase throughput, balance load, shorten travel time, allocate resources, or select the best candidate under constraints.

Objectives are powerful because they make evaluation possible. But they are also risky because measurable objectives can replace broader purposes. If a platform optimizes engagement, it may not optimize knowledge, trust, wellbeing, or civic value. If an institution optimizes speed, it may not optimize fairness, care, accuracy, or legitimacy.

Computational reasoning asks whether the objective is valid. Validity is not the same as measurability. A metric can be easy to compute and still be a poor proxy for the real goal.

Evaluation must be broader than the objective. A computational system should be judged by correctness, validity, robustness, interpretability, fairness, resource use, maintainability, and responsible use. The objective may guide procedure, but it should not define the whole meaning of success.

Back to top ↑

Assumptions and Scope

Every formal problem depends on assumptions. Some assumptions are mathematical, such as smoothness, independence, stationarity, or bounded error. Some are technical, such as stable input formats, reliable sensors, valid timestamps, or consistent database schemas. Some are institutional, such as consistent policy rules, meaningful categories, or reliable human review. Some are ethical or interpretive, such as the idea that a chosen metric is an acceptable proxy for a broader human value.

Scope defines where the formalization applies. A model built for one population, time period, environment, platform, or policy regime may not apply elsewhere. A procedure designed for clean inputs may fail under missing data. A ranking rule designed for one type of document may behave poorly for another. A classifier trained on one institutional context may not generalize to another.

Good formalization does not pretend assumptions are absent. It records them. It explains why they are reasonable, where they may fail, and what should happen when they no longer hold.

Back to top ↑

Edge Cases and Stopping Conditions

A computational procedure must handle more than the typical case. Edge cases reveal the boundaries of formalization. What happens when the input is empty? What happens when two scores tie? What happens when no solution exists? What happens when a graph is disconnected, a dataset has missing values, a user enters invalid text, a sensor fails, or a rule conflicts with another rule?

Edge cases matter because they show whether the procedure is robust. They also show whether the formal problem has been specified completely. A procedure that works only for ideal inputs may be useful in a classroom example, but real systems require explicit handling of uncertainty, failure, invalid input, adversarial behavior, and ambiguity.

Stopping conditions are also essential. An algorithm must know when to stop. A search may stop when it finds a target. An optimization routine may stop when improvement becomes small. A simulation may stop after a time horizon. A workflow may stop when a case is closed. But the stopping condition must match the purpose. Stopping too early can produce weak results; stopping too late can waste resources or create false precision.

Edge cases and stopping conditions are not technical afterthoughts. They are part of the definition of the formal problem.

Back to top ↑

Formalization Risk

Formalization risk is the risk introduced when a real-world concern is translated into a computational task. It appears when the formal problem differs from the actual problem in important ways. The risk may come from weak data, poor representation, invalid proxies, narrow objectives, hidden assumptions, missing constraints, ambiguous outputs, or inadequate governance.

A system can fail at the level of formalization even when the algorithm is correct. This is one of the most important lessons in computational reasoning. The procedure may satisfy its specification, but the specification may not be valid.

Formalization risk cannot be eliminated completely. But it can be reduced through documentation, testing, review, stakeholder input, uncertainty communication, sensitivity analysis, audits, and careful limits on use.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Formalization can be described mathematically as the translation of a real-world concern into a structured computational task. Let \(P\) represent the broad problem or concern. Let \(F(P)\) represent the formalization of that concern into a computable problem. Let \(A\) represent the algorithm or procedure.

Once the problem is formalized, the algorithm operates on that formal structure:

Formalization error can be thought of as a gap between the real-world concern and the formal problem:

The quality of a computational procedure can be modeled as more than correctness:

This mathematical framing reinforces the central idea: computation requires formalization, and formalization requires judgment.

Back to top ↑

Python Workflow: Formalization Audit

The Python workflow below creates a simple formalization audit for synthetic computational tasks. It evaluates how well a task defines its inputs, outputs, constraints, states, objectives, assumptions, edge cases, stopping conditions, evaluation criteria, and governance readiness.

# formalization_audit.py
# Dependency-light workflow for auditing how a real-world concern becomes
# a formal computational problem.

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 FormalizationCase:
    case_name: str
    real_world_concern: str
    formal_task: str
    input_clarity: float
    output_clarity: float
    constraint_clarity: float
    state_definition: float
    objective_alignment: float
    assumption_documentation: float
    edge_case_handling: float
    stopping_condition_clarity: float
    evaluation_quality: float
    governance_readiness: float


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


def formalization_score(case: FormalizationCase) -> float:
    return clamp(
        100.0 * (
            0.10 * case.input_clarity
            + 0.10 * case.output_clarity
            + 0.10 * case.constraint_clarity
            + 0.08 * case.state_definition
            + 0.14 * case.objective_alignment
            + 0.12 * case.assumption_documentation
            + 0.10 * case.edge_case_handling
            + 0.08 * case.stopping_condition_clarity
            + 0.10 * case.evaluation_quality
            + 0.08 * case.governance_readiness
        )
    )


def formalization_risk(case: FormalizationCase) -> float:
    weak_points = [
        1.0 - case.input_clarity,
        1.0 - case.output_clarity,
        1.0 - case.constraint_clarity,
        1.0 - case.objective_alignment,
        1.0 - case.assumption_documentation,
        1.0 - case.edge_case_handling,
        1.0 - case.evaluation_quality,
        1.0 - case.governance_readiness,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(score: float, risk: float) -> str:
    if score >= 80 and risk <= 25:
        return "strong formalization with clear procedure boundaries"
    if score >= 65 and risk <= 40:
        return "usable formalization with review needs"
    if risk >= 55:
        return "high formalization risk; problem should be reframed before automation"
    return "partial formalization; assumptions and evaluation need strengthening"


def build_cases() -> list[FormalizationCase]:
    return [
        FormalizationCase(
            case_name="Document search",
            real_world_concern="Help people find useful information.",
            formal_task="Retrieve and rank documents for a query.",
            input_clarity=0.82,
            output_clarity=0.78,
            constraint_clarity=0.62,
            state_definition=0.60,
            objective_alignment=0.70,
            assumption_documentation=0.58,
            edge_case_handling=0.62,
            stopping_condition_clarity=0.74,
            evaluation_quality=0.70,
            governance_readiness=0.56,
        ),
        FormalizationCase(
            case_name="Worker scheduling",
            real_world_concern="Coordinate labor, demand, skill, and wellbeing.",
            formal_task="Assign workers to shifts under coverage and availability constraints.",
            input_clarity=0.72,
            output_clarity=0.76,
            constraint_clarity=0.82,
            state_definition=0.70,
            objective_alignment=0.58,
            assumption_documentation=0.54,
            edge_case_handling=0.56,
            stopping_condition_clarity=0.68,
            evaluation_quality=0.60,
            governance_readiness=0.62,
        ),
        FormalizationCase(
            case_name="Public service triage",
            real_world_concern="Prioritize cases while preserving fairness and accountability.",
            formal_task="Classify cases into priority levels using available administrative data.",
            input_clarity=0.60,
            output_clarity=0.72,
            constraint_clarity=0.68,
            state_definition=0.58,
            objective_alignment=0.52,
            assumption_documentation=0.46,
            edge_case_handling=0.48,
            stopping_condition_clarity=0.60,
            evaluation_quality=0.54,
            governance_readiness=0.66,
        ),
        FormalizationCase(
            case_name="Scientific simulation",
            real_world_concern="Explore how a system changes under scenarios.",
            formal_task="Simulate state transitions under parameterized assumptions.",
            input_clarity=0.86,
            output_clarity=0.80,
            constraint_clarity=0.78,
            state_definition=0.88,
            objective_alignment=0.76,
            assumption_documentation=0.84,
            edge_case_handling=0.72,
            stopping_condition_clarity=0.82,
            evaluation_quality=0.78,
            governance_readiness=0.70,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        score = formalization_score(case)
        risk = formalization_risk(case)
        rows.append({
            **asdict(case),
            "formalization_score": round(score, 3),
            "formalization_risk": round(risk, 3),
            "diagnostic": diagnose(score, 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_formalization_score": round(mean(float(row["formalization_score"]) for row in rows), 3),
        "average_formalization_risk": round(mean(float(row["formalization_risk"]) for row in rows), 3),
        "highest_score_case": max(rows, key=lambda row: float(row["formalization_score"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["formalization_risk"]))["case_name"],
        "interpretation": "Formalization quality depends on clear inputs, outputs, constraints, states, objectives, assumptions, edge cases, stopping conditions, evaluation, and governance."
    }


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

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

    print("Formalization audit complete.")
    print(TABLES / "formalization_audit.csv")


if __name__ == "__main__":
    main()

The workflow treats formalization as an auditable design layer. It does not ask only whether a procedure can be written. It asks whether the computational task has been defined well enough to support responsible procedure design.

Back to top ↑

R Workflow: Formalization Summary and Visualization

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares formalization score and formalization risk across synthetic cases.

# formalization_audit_summary.R
# Base R workflow for summarizing formalization quality and risk.

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, "formalization_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_formalization_score = mean(data$formalization_score),
  average_formalization_risk = mean(data$formalization_risk),
  highest_score_case = data$case_name[which.max(data$formalization_score)],
  highest_risk_case = data$case_name[which.max(data$formalization_risk)]
)

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

comparison_matrix <- rbind(
  data$formalization_score,
  data$formalization_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Formalization score", "Formalization risk")

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

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Formalization Score vs. Formalization Risk"
)

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

grid()
dev.off()

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

barplot(
  data$formalization_risk,
  names.arg = data$case_name,
  las = 2,
  ylim = c(0, 100),
  ylab = "Formalization risk",
  main = "Formalization Risk by Case"
)

grid()
dev.off()

print(summary_table)

This workflow supports the article’s main argument: formalization quality should be evaluated before a procedure is treated as ready for implementation.

Back to top ↑

GitHub Repository

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

articles/problems-procedures-and-formalization/
├── python/
│   ├── formalization_audit.py
│   ├── problem_to_procedure_mapper.py
│   ├── input_output_constraint_audit.py
│   ├── state_transition_model.py
│   ├── stopping_condition_checks.py
│   ├── calculators/
│   │   ├── formalization_score_calculator.py
│   │   └── procedure_scope_calculator.py
│   └── tests/
├── r/
│   ├── formalization_audit_summary.R
│   ├── formalization_risk_visualization.R
│   └── procedure_scope_report.R
├── julia/
│   ├── state_transition_simulation.jl
│   └── formal_problem_model.jl
├── sql/
│   ├── schema_formalization_cases.sql
│   ├── schema_procedure_audit_trails.sql
│   └── formalization_queries.sql
├── haskell/
│   ├── FormalProblemTypes.hs
│   ├── ProcedureModel.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── formalization_audit.c
├── cpp/
│   └── formalization_audit.cpp
├── fortran/
│   └── formalization_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── formalization_rules.pl
├── racket/
│   └── formal_problem_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── problems-procedures-and-formalization.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_formalization_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── problems_procedures_formalization_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 Formalizing Problems

A practical method for formalization begins by separating the original concern from the computational task. This prevents the formal problem from silently replacing the real-world problem.

This method turns formalization into a reviewable artifact. It makes the computational task explicit enough to test, challenge, improve, or reject before the procedure becomes embedded in software or institutional practice.

Back to top ↑

Common Pitfalls

The most common pitfall is assuming that the computational task is the real problem. A task may be necessary and useful, but it is still a formalization. It has boundaries. It has assumptions. It simplifies.

Another common pitfall is treating inputs as raw reality. Inputs are selected, measured, formatted, labeled, cleaned, and interpreted. They may reflect social, technical, institutional, or historical processes. A procedure built on weak inputs may look rigorous while amplifying the limits of the data.

Common pitfalls include:

• task substitution: replacing the real-world problem with a narrow computational task;
• proxy confusion: treating a measurable substitute as the actual goal;
• hidden assumptions: leaving scope, context, or validity conditions undocumented;
• weak input definition: failing to document source, quality, missingness, units, or provenance;
• output overreach: interpreting a score, label, forecast, or ranking too strongly;
• constraint omission: ignoring legal, ethical, physical, or institutional limits;
• edge-case neglect: designing for ideal inputs while ignoring boundary cases;
• unclear stopping conditions: allowing procedures to end too early, too late, or without justification;
• evaluation mismatch: measuring success with a metric that does not match the purpose;
• governance afterthought: building the procedure before defining accountability.

Formalization should make these risks visible early. The earlier they are identified, the easier they are to correct.

Back to top ↑

Why Formalization Is a Reasoning Discipline

Formalization is where computational reasoning becomes concrete. It turns concerns into tasks, tasks into representations, representations into procedures, and procedures into outputs. But it also determines what computation will ignore, simplify, optimize, and treat as evidence.

A well-designed procedure begins with a well-defined formal problem. But a well-defined formal problem does not appear automatically. It must be constructed through careful reasoning about inputs, outputs, constraints, states, objectives, assumptions, edge cases, stopping conditions, evaluation, and responsibility.

This is why formalization belongs near the beginning of any serious study of algorithms. Algorithms are not only steps. They are steps applied to a formalized problem. To understand the algorithm, we must understand the formalization that gives the procedure its shape.

Back to top ↑

Related Articles

• What Is Algorithms & Computational Reasoning?
• Algorithmic Thinking vs. Computational Reasoning
• Decomposition and Stepwise Reasoning
• Abstraction in Computational Reasoning
• Inputs, Outputs, States, and Stopping Conditions
• Algorithmic Literacy for the Modern World
• From Pseudocode to Programs
• Debugging as Computational Reasoning

Further Reading

• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: Princeton University.
• Dasgupta, S., Papadimitriou, C.H. and Vazirani, U.V. (2008) Algorithms. New York: McGraw-Hill. Available at: University of California, Berkeley.
• MIT OpenCourseWare (2020) 6.006 Introduction to Algorithms. Cambridge, MA: Massachusetts Institute of Technology. Available at: MIT OpenCourseWare.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. Available at: ACM Digital Library.
• National Research Council (2010) Report of a Workshop on the Scope and Nature of Computational Thinking. Washington, DC: The National Academies Press. Available at: National Academies Press.
• Jackson, M. (2001) Problem Frames: Analysing and Structuring Software Development Problems. Boston, MA: Addison-Wesley. Bibliographic record available at: Google Books.
• Lamport, L. (2002) Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA: Addison-Wesley. Available at: Leslie Lamport’s TLA+ page.
• ISO/IEC/IEEE (2018) ISO/IEC/IEEE 29148:2018 Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Geneva: International Organization for Standardization. Available at: ISO.
• 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.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. Available at: ACM Digital Library.
• Brooks, F.P. Jr. (1987) ‘No Silver Bullet: Essence and Accidents of Software Engineering’, Computer, 20(4), pp. 10–19. Available at: ACM Digital Library.
• Friedman, B. and Nissenbaum, H. (1996) ‘Bias in computer systems’, ACM Transactions on Information Systems, 14(3), pp. 330–347. Available at: ACM Digital Library.
• Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J.W., Wallach, H., Daumé III, H. and Crawford, K. (2021) ‘Datasheets for datasets’, Communications of the ACM, 64(12), pp. 86–92. Available at: ACM Digital Library.
• Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model Cards for Model Reporting’, in Proceedings of the Conference on Fairness, Accountability, and Transparency. New York: ACM, pp. 220–229. Available at: ACM Digital Library.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: NIST. Available at: NIST.
• Russell, S. and Norvig, P. (2021) Artificial Intelligence: A Modern Approach. 4th edn. Hoboken, NJ: Pearson. Companion materials available at: AIMA official site.

References

• Abelson, H., Sussman, G.J. and Sussman, J. (1996) Structure and Interpretation of Computer Programs. 2nd edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/.
• Brooks, F.P. Jr. (1987) ‘No Silver Bullet: Essence and Accidents of Software Engineering’, Computer, 20(4), pp. 10–19. doi: 10.1109/MC.1987.1663532.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/.
• Dasgupta, S., Papadimitriou, C.H. and Vazirani, U.V. (2008) Algorithms. New York: McGraw-Hill. Available at: https://people.eecs.berkeley.edu/~vazirani/algorithms.html.
• Dijkstra, E.W. (1968) ‘Go To Statement Considered Harmful’, Communications of the ACM, 11(3), pp. 147–148. doi: 10.1145/362929.362947.
• Friedman, B. and Nissenbaum, H. (1996) ‘Bias in computer systems’, ACM Transactions on Information Systems, 14(3), pp. 330–347. doi: 10.1145/230538.230561.
• Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J.W., Wallach, H., Daumé III, H. and Crawford, K. (2021) ‘Datasheets for datasets’, Communications of the ACM, 64(12), pp. 86–92. doi: 10.1145/3458723.
• 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.
• ISO/IEC/IEEE (2018) ISO/IEC/IEEE 29148:2018 Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Geneva: International Organization for Standardization. Available at: https://www.iso.org/standard/72089.html.
• Jackson, M. (2001) Problem Frames: Analysing and Structuring Software Development Problems. Boston, MA: Addison-Wesley. Bibliographic record available at: https://books.google.com/books/about/Problem_Frames.html?id=j6hQAAAAMAAJ.
• Knuth, D.E. (1997) The Art of Computer Programming, Volume 1: Fundamental Algorithms. 3rd edn. Reading, MA: Addison-Wesley. Author information available at: https://www-cs-faculty.stanford.edu/~knuth/taocp.html.
• Lamport, L. (2002) Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA: Addison-Wesley. Available at: https://lamport.azurewebsites.net/tla/book.html.
• MIT OpenCourseWare (2020) 6.006 Introduction to Algorithms. Cambridge, MA: Massachusetts Institute of Technology. Available at: https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-spring-2020/.
• Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I.D. and Gebru, T. (2019) ‘Model Cards for Model Reporting’, in Proceedings of the Conference on Fairness, Accountability, and Transparency. New York: ACM, pp. 220–229. doi: 10.1145/3287560.3287596.
• National Institute of Standards and Technology (2023) Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg, MD: National Institute of Standards and Technology. Available at: https://www.nist.gov/itl/ai-risk-management-framework.
• National Research Council (2010) Report of a Workshop on the Scope and Nature of Computational Thinking. Washington, DC: The National Academies Press. doi: 10.17226/12840.
• Papadimitriou, C.H. (1994) Computational Complexity. Reading, MA: Addison-Wesley. ACM record available at: https://dl.acm.org/doi/abs/10.5555/1074100.1074233.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. doi: 10.1145/361598.361623.
• Russell, S. and Norvig, P. (2021) Artificial Intelligence: A Modern Approach. 4th edn. Hoboken, NJ: Pearson. Companion materials available at: https://aima.cs.berkeley.edu/.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: https://algs4.cs.princeton.edu/home/.
• Sipser, M. (2012) Introduction to the Theory of Computation. 3rd edn. Boston, MA: Cengage Learning.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. doi: 10.1145/1118178.1118215.