C-DAD vs. Architecture Decision Records

Of everything on this list, an ADR is the closest relative a contract has. Teams that already write ADRs are usually already doing the hard part: sitting down and writing out why a decision was made, what alternatives got considered, what tradeoff got accepted. That habit is genuinely good practice, and a lot of what makes a contract useful is the same instinct pointed at a slightly different target.

The difference shows up after the decision gets made. An ADR is a point-in-time record. It captures the reasoning as of the day someone wrote it, gets merged, and then in most teams' experience sits untouched even after the decision it describes gets partially reversed or quietly superseded by a later one. Nothing forces anyone to go back and update an old ADR when a newer one changes the underlying assumption, so a reader trying to understand the current state has to read the whole history and guess which parts are still true.

A contract is written to stay current against the system as it actually runs, not just the day it was written. cdad validatechecks it against versioning rules and generated-artifact consistency, so a contract that's fallen out of sync with the capability it describes gets caught rather than quietly trusted. And an ADR is written for a historian, someone trying to understand how the system got to where it is. A contract is written for someone making a change today, an agent or an engineer who needs to know what's true right now, not the full sequence of decisions that got there.

One anti-pattern makes the gap concrete: recording that an incident happened without capturing the constraint it created. An ADR that notes a database choice from years back, and never gets revisited, is exactly the kind of record that looks thorough and turns out to be dead weight. A contract's history section is meant to hold the lesson, the actual constraint that future work has to respect, not just a log of what happened once.