Turn a framework roadmap into an application decision record

Framework roadmaps are useful because they show where maintainers expect the design to move. They are not release guarantees and they do not replace an application’s own constraints. Convert roadmap items into explicit questions before changing architecture.

Classify each item

Place a roadmap item in one of four groups:

1. available and documented;
2. available but experimental;
3. announced but not released; or
4. directional only.

Only the first group should normally support a production decision without added risk controls. For experimental work, record the fallback and the boundary that contains it.

Compare the problem, not the feature name

If a roadmap proposes compile-time validation, write the present failure mode: missing definitions found in production, slow startup verification, or annotation drift. Measure whether the available feature solves that problem. If the current tests already give fast, local feedback, migration may have low value.

Use current product documentation as the source for available behavior. For example, Koin’s setup guide describes released setup choices, while its feature-specific references describe current limits. Save the documentation date in the decision record.

Set a review trigger

A good “not now” decision includes a trigger: the feature becomes stable, a blocking issue closes, a supported target is added, or the current approach exceeds a measured cost. This prevents repeated debates without forcing an early migration.

The output should be a short application decision: problem, constraints, evidence, choice, rollback, and next review trigger. A roadmap informs that record; it does not write it for the team.