Documenting Digital Workflows You Can Verify

01

What does it mean to document a digital workflow?

A workflow is documented when someone else can repeat it and get the same result. That means writing down what was backed up, where it went, and how a restore was actually tested, not just configured. Sync tools and version history are not backups, and a tool choice made on published criteria survives a change of vendor better than one made on reputation.

Documentation here is a record of decisions and their evidence. For a backup routine, the record names the source folders, the destination, the schedule, the retention rule, and the date of the last restore test. For a software choice, it names the criteria before the product: what must be exported, what must be restorable, what protection is required, and what maintenance the tool demands.

A useful test is whether a second person could follow the notes without asking questions. If the notes say "backed up to the cloud", they fail. If they say "Documents and Photos copied weekly to an external SSD, encrypted, with a monthly restore of two random files", they pass. The German-language magazine Werkstatt Digital treats this as its working method: criteria are displayed before names, manufacturer statements are separated from reproducible tests, and each topic is handled as a documented, verifiable procedure. Readers who want that approach applied to backup, tool selection and privacy settings can follow the Werkstatt Digital workflow notes as a reference model.

The same standard applies to smaller things. A note-taking setup, a Git repository, a terminal session: each becomes verifiable when the steps and the expected output are written next to each other.

02

How do you test a backup restore?

A backup is untested until a file has been recovered from it. The test is not the backup job finishing without errors; it is opening the destination, selecting a file at random, and restoring it to a location that is not the original. If the file opens and matches the original, the backup works for that file type at that moment.

A practical routine has four steps. First, pick two or three files of different kinds, for example a text document, a photo, and a database or archive file. Second, restore them to a scratch folder, never over the live originals. Third, open each one and check that it is complete, not truncated. Fourth, write the date and the result in the documentation.

Restore tests fail for predictable reasons. The backup may exclude a folder by default, the encryption key may be stored only on the machine that was lost, or the archive may be split across files that were not all copied. Each of these is discovered by testing, not by reading the settings screen. A restore test done once a quarter is enough for most personal and small-collective setups, provided the result is recorded.

The test also reveals the difference between a backup and a copy. A copy on the same disk protects against accidental deletion for a few minutes. It does not protect against disk failure, theft, or ransomware. The test should therefore be run against the destination that is supposed to survive those events.

03

What is the difference between sync and version history?

Synchronisation keeps two or more locations identical at the present moment. Version history keeps earlier states of a file so they can be retrieved later. They solve different problems and are often confused because both are delivered by the same cloud service.

When a file is edited on one machine, sync propagates the new version to the others. If the edit was a mistake, sync propagates the mistake too. Version history is what allows the previous state to be recovered, but only within the retention window the service offers, which may be thirty days, one year, or something in between. Once the window closes, the earlier version is gone.

A deletion is the clearest case. Sync deletes the file everywhere it is synchronised. Version history may allow it to be restored, if the deletion is noticed inside the retention window. A backup, by contrast, holds a copy that sync does not touch, so the file survives regardless of the window.

The practical rule is that sync is for working across devices, version history is for undoing recent mistakes, and backup is for recovery after loss. Documenting which service does which, and for how long, prevents the assumption that one covers the others. The retention period belongs in the notes, next to the restore test date.

04

How should files be catalogued?

Cataloguing is the practice of making a collection findable without opening every folder. It does not require a database. A consistent folder structure, a naming convention, and one index file are usually enough.

A workable convention fixes the order of elements in a filename: date first in ISO form, then project or person, then a short description, then a version number. Dates sort correctly, versions prevent overwriting, and descriptions remain readable years later. Special characters and spaces cause problems across operating systems, so hyphens and underscores are safer.

The index file lists the top-level folders, what each contains, where its backup goes, and when it was last checked. On macOS, the built-in tools for listing and searching files are sufficient for this; the index does not need to be generated automatically to be useful. What matters is that it is updated when a folder is added or a backup destination changes.

Cataloguing also applies to the backup itself. Knowing which folders are inside the backup, and which are deliberately excluded, turns a vague sense of safety into a checkable list. Exclusions are the usual source of surprise during a restore test.

05

How do you choose a tool on published criteria?

Criteria first, names second. Write down what the tool must do before looking at any product: which formats it must export, whether a full restore is possible without the vendor, what protection it offers for stored data, and how much maintenance it requires. Then evaluate candidates against that list.

Export and restore are the two criteria that decide long-term dependence. A tool that exports everything in an open format can be left; a tool that only exports a partial view cannot. A restore that has been performed by the user, not just described by the manufacturer, is evidence; a feature list is not.

Protection covers encryption, access control, and what happens when a device is lost. Maintenance covers updates, subscription terms, and the effort of keeping the tool working. These are the same four axes used in documented tool comparisons, where the criteria are shown before the products and manufacturer claims are kept separate from reproducible tests.

A reproducible test is small and written down: install the tool in a test folder, import a sample set, export it, restore it, and record what changed. Two candidates tested the same way produce a comparison that can be repeated by someone else. That is the point of documenting the choice, not just making it.

06

Why does this matter for small setups?

Individuals, freelancers and small collectives maintain their own notes, files and backups. There is no IT department to notice that a backup job stopped running, that a retention window expired, or that a tool no longer exports in a usable format. The documentation is the substitute for that oversight.

It also makes handover possible. A collective member who leaves can pass on a folder structure, an index, a restore test log and a criteria list. A successor can verify the setup instead of trusting it. The same applies when a tool is replaced: the criteria list shows what the new one must match.

The work is modest. A restore test takes minutes. A criteria list takes an afternoon. A naming convention takes one decision and then holds. What it buys is the ability to answer, with evidence, whether the files are actually recoverable.