Versioned Extensibility

Controlling specification change: stable product logic while external drafts evolve

External specifications evolve independently from product releases. A versioned boundary separates volatile protocol or profile revisions from more stable internal product contracts and makes additive, breaking and evidence-only changes distinguishable.

Topics:Specification Change ControlAnti-Corruption LayerVersioned ProfilesDraftsAdapters

Why drafts should not become domain logic

If external DTOs and revision numbers penetrate deep product state, every profile change becomes a broad internal change. MEMM instead treats external revisions at adapter and profile boundaries before stable product logic consumes them.

A practical change classification

  • Additive: the existing product boundary remains stable and can be extended.
  • Breaking: API, runtime or boundary effects require a new architecture decision.
  • Evidence-only: documentation or proof changes while the runtime boundary remains the same.
  • Out of scope: the requested change would expand the product boundary without controlled review.
What this page explicitly does not claim: Change-control and adapter principles do not mean that future drafts are automatically supported or that external revisions can be adopted without revalidation.