Самая дорогая проблема архитектурной схемы начинается не тогда, когда на ней не хватает красивых обозначений. А когда один и тот же сервис нарисован на пяти схемах и после изменения приходится вспоминать, какие четыре из них уже устарели.

В этом разборе хорошо сформулирована причина: диаграмма сама по себе не хранит идентичность объекта, тип связи и происхождение данных. Поэтому её трудно автоматически проверить или сравнить с фактическим состоянием системы. https://habr.com/ru/articles/1073116/

Но я бы не начинал решение с попытки построить большой «единый источник истины». Для первого шага достаточно гораздо меньшего контракта.

У каждого архитектурного компонента — устойчивый идентификатор и владелец. У связи — конкретный тип, а не просто стрелка «взаимодействует». Для изменяемых атрибутов заранее указано, откуда берётся авторитетное значение: например, владелец из каталога команд, фактический адрес из среды исполнения, допустимость зависимости из архитектурного решения.

Тогда несколько диаграмм становятся разными представлениями одних объектов.

Переименование компонента перестаёт быть обходом картинок, а архитектурное ревью можно строить вокруг изменений модели: что добавилось, что исчезло и какая зависимость поменялась.

Это уже решает значительную часть проблемы устаревающих схем — ещё до внедрения сложного архитектурного репозитория.