ADRs are similar, yet the important point is not the format of the design log entry, but it's usage with AI.
with design log, we ask the AI to create the ADR or log entry, but unlike ADR we
1. require the AI to ask question and we answer.
2. require the AI to update the design log after implementation with any drift from the original design.
Both of the above help to make the AI more precise and prevent context drift.
What you seek is actually something a bit different.
It is the observation that all software is built of 3 layers -
Inbound IO, what you call imperative shell
Business logic core, what you call functional core
Outbound IO, what you call again imperative shell.
The problem with the terms in functional programming is that when they say side effects, in most cases they mean IO.
The functional core does not have to be functional for you to get the benefits - easy testing, easy to reason about, easy to develop. In fact, in some cases, functional programing is the wrong tool while having a business logic core that is separated from IO is still a very valid architecture.
with design log, we ask the AI to create the ADR or log entry, but unlike ADR we 1. require the AI to ask question and we answer. 2. require the AI to update the design log after implementation with any drift from the original design.
Both of the above help to make the AI more precise and prevent context drift.