Skip to content
C.W.K.
Stream
Lesson 04 of 05 · published

Policy as Configuration

~11 min · settings, policy, configuration, architecture

Level 0Kindling
0 XP0/32 lessons0/10 achievements
0/100 XP to next level100 XP to go0% complete

The dials that govern the engine

Everything the Monitor does automatically is governed by values that live in Settings, not in code: the storage roots and their live capacity, the maximum transfer rate, the daily budget and its reset boundary, the planning calculator that turns those two numbers into finish dates. The screenshot below shows the shape of that surface; the lesson is about why the shape is that way.

The Woodpile Settings surface: fields for the NAS storage roots with their live capacity figures, the maximum download rate, the daily transfer budget with its reset boundary, and the planning calculator that turns those numbers into campaign estimates.
The dials that govern the engine: roots, rate, and budget as configuration — the archive's opinions, editable without a code change.

The architectural claim: pacing and budgets are policy, and policy belongs in configuration. Policy changes for reasons code should not care about — a new disk joins the NAS, the household's evening network reality shifts, a campaign needs seasonal patience, a mistake in last month's arithmetic gets corrected. If those changes require a code change, they happen late or never; the mechanism ends up serving a policy that no longer matches reality. Configuration keeps the engine stable while its governance breathes.

What the separation buys

The split between mechanism (the transfer engine, which changes when engineering does) and policy (roots, rates, budgets, which change when life does) has three practical payoffs. Changes are cheap and reversible — retune the dial, watch one transfer, decide. Mistakes are visible — a wrong budget shows up as a setting someone can read, not as behavior someone must reverse-engineer. And the archive's operating posture is auditable — the knobs, read together, ARE the current policy: how fast, how much per day, into which roots. You can screenshot your own discipline.

Notice the same separation in everything this quest taught you by hand: the resumable ritual is mechanism; the rate cap and budget you chose are policy. Your NOTES files hold your configuration. When your circumstances change, you edit the note — not the laws of physics the script embodies.

Mechanism is code; policy is configuration. If changing your mind requires a programmer, your policy is frozen. The dials are the archive's opinions, kept where editing them costs nothing.

Configuration still has rules

None of this means settings are a free-for-all. Good configuration is still recorded (who changed which dial, when, why — the decision record applies to knobs too), still constrained (a rate cap of "everything the link has" is a policy that recreates the interruption problem), and still reviewed (the periodic question: do these numbers still match the household's reality?). The dials make policy cheap, not thoughtless.

Code

Your policy, written where you can audit it·text
# The home equivalent of the Settings surface — a policy file:
#   ~/models/POLICY
#   ---
#   rate-cap:      1500K          # 2026-09 set: video calls must win
#   daily-budget:  150G           # 2026-09 set: NAS rebuild headroom
#   roots:
#     primary:   archive/         # canonical, read-only after landing
#     staging:   staging/         # writable, acquisition only
#   ---
#   changelog:
#   2026-09-14 initial policy (Pippa, after the sprint incident)
#   2026-09-20 rate 3000K -> 1500K: family complained; was right
#
# Every script reads this file; no script hardcodes these numbers.
# Changing your mind is one line plus one changelog entry —
# that is the whole point of policy-as-configuration.

External links

Exercise

Create your POLICY file with the two knobs, your roots, and a changelog. Move any hardcoded numbers out of one script or crontab into it. Then practice a policy change end-to-end: retune one value, log it with a reason, and observe one transfer under the new setting. Write down what the change would have cost if the number had lived in code.
Hint
The changelog entry is the part people skip and auditors thank you for. 'rate 3000K -> 1500K: family complained; was right' is a complete policy history in one line.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.