Prefer Reversible Changes

A technical change is safer when you can explain the starting state, predict the intended result, and return to the starting state if the evidence does not match your prediction.

Prefer reversible changes. Inspect first, protect important work, change one thing, verify the result, and keep a clear rollback path. This method does not make every action harmless, but it limits uncertainty and makes mistakes easier to diagnose.

Reversibility is a property of the procedure

A change is not reversible merely because an Undo button exists. A reversible procedure answers six questions:

1. What is the relevant current state?
2. What exact result should change?
3. What important work needs protection?
4. What is the smallest change that can test the idea?
5. How will you verify the result?
6. How will you return to the starting state?

The answers depend on the task. Restoring one configuration file may require a copy. Reversing a code change may require a Git checkpoint. Recovering an entire computer may require a tested backup and recovery information.

Write the answers in your working log before acting. A rollback plan invented after a failure is a recovery attempt, not a prepared rollback.

Inspect before changing

Begin with evidence. Record only the state relevant to the proposed change:

• the file, application, project, or device involved;
• the current setting or behavior;
• the directory and filename;
• the tool or software version when it matters;
• recent errors; and
• the result of an appropriate status or preview operation.

Suppose a program cannot read settings.json. Do not immediately reinstall the program, move several files, and change permissions. First confirm that the file exists, record its path, inspect its contents, and capture the exact error. The cause may be a spelling error or the wrong current directory.

Inspection narrows the problem. It also creates a before-state that you can compare with the result.

Protect the state you cannot replace

Choose protection that matches the artifact.

A checkpoint is useful only if it contains the needed state and you know how to use it. “This folder probably syncs” is not a verified rollback plan. A Git commit does not protect untracked files it never recorded. A backup is not confirmed until you can restore from it.

Do not create uncontrolled copies of private course data, credentials, or institutional records. Follow the applicable storage rules.

Preview when the tool supports it

Some tools can report intended actions without applying them. The feature may be named preview, dry run, check, plan, or diff.

Use it to answer:

• Which files or settings would change?
• Does the scope match the task?
• Are unexpected deletions or replacements included?
• Does the tool report an error before changing anything?

A preview is evidence, not a guarantee. The actual environment can change between preview and execution, and not every preview models every effect. Still, an unexpected preview is a strong reason to stop.

When no preview exists, create your own small test. Work on a disposable copy, one example file, or a low-risk setting before applying the procedure broadly.

Make one small change

If you change a filename, a permission, an application setting, and a software version at the same time, a successful result does not tell you which change helped. A failure does not tell you which change caused it.

Make the smallest change that can test the current hypothesis:

1. State the expected effect.
2. Apply one change.
3. Observe the result.
4. Keep it, reverse it, or revise the hypothesis.

Small changes produce clearer evidence. They also reduce the amount of work that a rollback must undo.

This rule has practical exceptions. A documented update may replace several related files as one operation. Treat that update as one change, but still inspect its scope, protect important state, and verify the completed result.

Use the least privilege required

Administrator access allows changes that a normal user cannot make. That power also increases the possible consequences of an error.

Do not start an entire terminal, editor, or browsing session with elevated access merely in case a later step needs it. Begin as a normal user. Elevate only for a specific, understood operation that requires it.

Stop when an unexpected prompt requests administrator access. Check:

• which program requested it;
• which documented operation requires it;
• what will change;
• whether the source of the instructions is trustworthy; and
• whether a lower-risk alternative exists.

Account recovery, suspected malware, material data loss, unfamiliar disk operations, and institutional security incidents may require an expert or official support channel. Escalating is a responsible decision.

Verify the result and the rollback

Verification should test the outcome, not merely the absence of an error message.

If you change a setting so that an application saves into a course folder, create a harmless test file, confirm its actual location, reopen it, and remove the test. If you change project configuration, run the relevant test or build and inspect the expected output.

When the result is wrong:

1. stop making additional changes;
2. record the observed state;
3. apply the prepared rollback;
4. verify that the starting behavior or content has returned; and
5. preserve the evidence before trying another hypothesis.

Rollback also needs verification. Copying an old file into place is an action; opening the application and confirming the restored behavior is evidence.

Use a reversible-change checklist

Copy this into your working log:

## Reversible change

Objective:

Starting state:

Expected result:

Important work protected by:

Preview or small test:

One change to make:

Verification:

Rollback action:

Rollback verification:

Decision: keep | reverse | investigate

The checklist should remain short. Its purpose is to expose missing safety steps, not to turn a five-minute experiment into paperwork.

Common mistakes

• Changing before observing. Capture the current state and exact error.
• Assuming synchronization is a backup. Confirm what is protected and test a restore.
• Making several speculative changes. Test one hypothesis at a time.
• Trusting a preview without reading it. Check the target and scope.
• Using administrator access by default. Elevate for one justified task.
• Calling a change reversible without testing the path back. Verify the rollback on a safe example when practical.
• Continuing after unexpected behavior. Stop, record, and reassess.

Do this now

First run a stop gate: confirm the target, current state, backup or rollback path, and verification check. Stop if the change could affect protected work and recovery is unresolved.

Choose one low-risk setting or disposable file. Complete the checklist before changing it. Make one change and verify the expected result. Then either keep the change or practice the rollback and verify that the starting state returned.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?

Next, learn what plain text is and why it provides a durable foundation for student work.