Week 4: Programs Are Systems

A program is not just a pile of lines that execute from top to bottom. It is a system that accepts inputs, stores state, makes decisions, changes state, and produces outputs. This week you will learn to read small programs the same way you read a service or network: identify the boundary, trace the state, observe evidence, and test one change at a time.

The defensive connection matters. Many software failures begin when a program receives an input the author did not model, reaches a branch nobody tested, or changes state without leaving useful evidence. You do not need exploit code to study that problem. You need a precise execution trace.

This week

1. Programs Have State — model input, variables, branches, state changes, and output.
2. Branches Create Alternate Futures — trace the same program through different paths and explain why the result changed.
3. Validate Before You Trust — add a narrow input boundary, test valid and invalid cases, and document what the control actually proves.

Evidence artifact

Build an Execution and Input Boundary Record containing:

• the program's input boundary;
• a state table for at least three cases;
• one branch trace;
• one malformed-input case;
• the control you added;
• a positive retest and a negative retest; and
• one limitation that remains.

The goal is not to write clever code. The goal is to make program behavior explainable.