Large code transformations are tricky.
Not because we can’t describe them.
Not because we can’t apply them.
But because, once they run… we’re never entirely sure they did exactly what we intended.
In previous articles, I introduced Dennis and DEX: Dennis generates deterministic transformation plans; DEX turns those plans into portable, inspectable artifacts
That already solves a big part of the problem:
👉 transformations become visible
But something was still missing: "The missing Question":
- Even with a plan…
- Even with an artifact…
- Even with signatures…
How do you know the transformation is actually correct?
Not “looks correct”.
Not “probably correct”.
Correct.
The Problem With Traditional Diffs:
We already have diffs, right?
git diff has been around forever.
But here’s the uncomfortable truth: Diffs are not deterministic.
Two environments can produce slightly different diffs for the same change:
- different line endings
- different grouping
- different context
- different ordering
They are great for humans.
They are not reliable as evidence.
What Dennis Needed:
Dennis needed something stricter:
- a canonical representation of change
- independent of environment
- independent of tooling
- stable across time
In other words: a diff that behaves like an artifact
Enter: Canonical Diff
Dennis now produces a canonical diff format:
- deterministic
- lossless
- normalized (including Unicode)
- order-stable
- hashable
Same input → same diff → same hash
Every time.
No surprises.
From Diff to Identity
Once the diff is canonical, something interesting happens.
You can hash it:
diff_hash = sha256(canonical_diff)
Now the transformation is no longer just visible.
👉 It has an identity.
And That Changes Everything
Because now you can:
- compare transformations across machines
- verify that two systems produced the same result
- detect drift immediately
- attach diffs to lineage
You’re no longer looking at change.
You’re verifying it.
Conformance: The System That Checks Itself
To make this reliable, Dennis now includes a new command:
dennis test-diff
This command runs a set of canonical transformation cases and checks:
- structure matches expected output
- hash matches expected identity
If anything changes—even slightly—the test fails.
This is not a unit test.
It’s a protocol check.
It answers a single question:
“Is Dennis still behaving like Dennis?”
Why This Matters
At this point, something subtle happens.
DEX artifacts describe transformations.
Canonical diffs verify them.
Together, they form something stronger:
- transformations that can be inspected, reproduced… and proven.
This is where Dennis stops being a tool. And starts becoming a system of record.
The Bigger Picture
Software development already treats many things as artifacts:
- builds
- containers
- dependencies
But transformations—the things that actually change systems— are still mostly invisible. DEX made them visible. Canonical diff makes them verifiable.
And Dennis?
Dennis is still the forge.
But now the forge doesn’t just produce artifacts.
👉 It produces evidence.
What’s Next
With deterministic diffs in place, the next step becomes obvious:
- diff lineage
- transformation verification across systems
- UI visualization of state transitions
But that’s a story for another article.
Final Thought
We’ve learned to trust code.
We’ve learned to trust builds.
We’ve learned to trust artifacts.
Maybe it’s time we learned to trust transformations too.
And no…
the chickens are still retired.
They’re now attending coding seminars.
Web site:
https://dennis-forge.com
Repository
https://dennis-forge.com/repo/
Top comments (0)