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

Version the Future

~12 min · versioning, briefs, history, live-policy

Level 0Cold Vessel
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

Version the Future

Editing a pipeline should improve future work without rewriting the text that an earlier session received. The row version increases, the live catalog shows the edit, and the next brief stamps the new version. Historical briefs keep their materialized template and version so review can reconstruct the author's premises.

That simple sentence hides two lifetimes. Brief text is a snapshot. Operational gates may be live policy if the engine deliberately reads the current row at verification. A workshop must state this distinction; saying “taken work is frozen” without naming which fields freeze creates false confidence.

A fully frozen policy copies required stages and review requirements into the delegation. A live-policy design lets an operator tighten a gate for work already in flight. Neither is universally correct. The crucial requirement is that the choice be explicit, testable, and visible in the landing record.

Crucible today preserves the authored brief snapshot while current required stages can still participate in verification. Teach that as a contract seam, not as an accident to hand-wave. A future change could freeze more policy, but history must continue to identify both the brief version and the gate policy applied at landing.

Stamp Both Lifetimes

Record the row version that materialized the brief and the effective policy checked at landing. If they differ, the trail should make that visible rather than pretending one timestamp explains everything.

An edit test needs an in-flight delegation. Take under version one, edit to version two, then assert what stays frozen and what changes. Without that middle state, tests prove only creation and cannot catch lifecycle ambiguity.

A version change governs future intake, not remembered history. Stamp the row version and rendered brief when work is taken, then preserve them even if the live policy evolves. Verification may still consult explicitly current gates, but that seam must be named instead of pretending every input froze together.

Code

Model snapshot text and live landing policy separately·python
brief = {"pipeline_version": 1, "text": "Run plan gate"}
current_row = {"version": 2, "required_stages": ["plan-gate", "review"]}
logged = {"plan-gate", "review"}

assert brief["pipeline_version"] == 1
assert set(current_row["required_stages"]) <= logged
print({"brief_version": 1, "landing_policy_version": 2})

External links

Exercise

Design the take-edit-verify test for your own row model. Write separate expected values for brief text, stamped version, and effective landing stages.
Hint
If every expected value is version two, you have not tested the snapshot.

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.