Automation Multiplies Decisions

A manual mistake may happen once. An automated mistake can happen a thousand times before anyone notices.

That does not make automation bad. It means automation deserves a contract.

Model the task before writing the script

Suppose a classroom script organizes fictional log files into an archive folder.

A weak requirement is:

Move the logs.

A stronger task contract says:

Input directory: supplied ./incoming-logs
Accepted files: names ending in .log
Destination: ./archive
Existing destination file: do not overwrite; report conflict
Missing source directory: stop
Unexpected file type: leave unchanged and report
External/network paths: prohibited

Now the automation has a boundary.

Separate preconditions, action, and postconditions

Preconditions

Things that must be true before the action begins.

Examples:

• the source path exists;
• the destination is the expected classroom directory;
• the script is not pointed at /, a home directory, or a network share;
• input files match the exercise contract; and
• required free space exists.

Action

The narrow change the script is allowed to perform.

Postconditions

Evidence that should be true afterward.

Examples:

• expected files exist at destination;
• source files were handled according to policy;
• file count matches expectations;
• no unrelated files changed; and
• an operation log records success/failure outcomes.

This gives you a systems chain:

CHECK
  ↓
CHANGE
  ↓
VERIFY

Dry-run is a useful design pattern

A dry-run reports what would change without changing it.

Pseudocode:

for file in candidate_files:
    if valid(file):
        print(f"WOULD_MOVE {file} -> archive/{file.name}")
    else:
        print(f"SKIP {file} reason=not-allowed")

Dry-run does not prove the real action will succeed, but it exposes scope mistakes before side effects occur.

Side effects are part of the system

A function that calculates 2 + 2 has no external side effect.

A script that:

• moves files;
• changes permissions;
• edits configuration;
• starts/stops services;
• sends network requests; or
• writes database rows

changes the environment around it.

The more significant the side effect, the stronger the preconditions, logging, and rollback expectations should be.

Activity: identify dangerous ambiguity

For each instruction, explain what is underspecified:

1. “Delete old files.”
2. “Restart the service if needed.”
3. “Fix permissions.”
4. “Copy the config everywhere.”
5. “Retry until it works.”

A strong answer should ask questions such as:

• How old?
• Which directory?
• Which service?
• What exact permission state?
• Which destination set?
• What is the retry limit?
• What condition means stop?

Automation turns vague language into concrete actions. If the language is vague, the action may be wrong while still executing perfectly.

Build a bounded task contract

Design a harmless task using only a temporary classroom directory or supplied paper model.

Example:

Rename files matching report-*.txt to add a .reviewed suffix inside ./lab06, without overwriting existing files.

Document:

Allowed root:
Candidate pattern:
Preconditions:
Action:
Expected side effects:
Prohibited side effects:
Stop conditions:
Postconditions:
Rollback/recovery:

Do not use a system directory or real production data.

The defensive connection

Operations and security meet in automation because control quality depends on repeatability.

A hardening step that only works when one person remembers a sequence is fragile. A script can improve repeatability — if the script itself has evidence, scope, and safe failure behavior.

The lesson is not “security people should script everything.” It is:

A defensive change is stronger when its preconditions, side effects, and verification are explicit.

Keep your task contract. Lesson 2 adds machine-readable outcomes to it.