Authorization systems are built from statements. AWS IAM policies are logical expressions over statements like “this principal has this action on this resource.” When a policy evaluates to True, access is granted. The entire access control model is statement evaluation.
Health checks in Kubernetes are statements.
livenessProbe evaluates: “is this container alive?” The
probe returns a binary result. Kubernetes branches on it. The complexity
is in defining what “alive” means precisely enough that the statement
evaluates correctly.
Database constraints are statements about data.
NOT NULL, UNIQUE,
CHECK (age > 0) — each is a statement that must hold
True for every row. The database evaluates these statements at write
time. A constraint violation is a statement that evaluated to False when
it was required to be True. This is FM8: a schema/contract
violation.
Compiler type systems evaluate statements about programs before the programs run. “This variable is always an integer” is a statement. The type checker proves it True or False at compile time. A type error is a statement the type checker cannot prove True — a contract violation caught early.
Concept: Statement (Proposition)
Thread: T7 (State Machines) origin → stateless services (Book 3, Ch 3)
Core Idea: A statement is a declarative sentence with a definite truth value — True or False, never both, never neither. It is the atomic unit of logical reasoning and the foundation of every boolean operation in computing.
Tradeoff: AT3 — Simplicity vs. Flexibility (binary truth values are simple but force explicit mappings from multi-valued real-world states)
Failure Mode: FM8 — Schema/Contract Violation (a statement is a contract; ambiguous or stale statements break the evaluator’s assumptions)
Signal: When an if-condition evaluates unexpectedly, or when authorization logic produces wrong results — re-examine what statement is actually being evaluated and whether it matches what you intend.
Maps to: Book 0, Framework 5 (State)