Допустим, один документ требует OAuth 2.0, старый прототип использует API key, а письмо поставщика вводит дополнительное ограничение по сроку жизни токена. Если сразу писать спецификацию, агенту придётся выбрать одну связную версию. Но у него нет полномочия решать, какой источник задаёт норму.
В Source Map каждый материал получает отдельную запись. Минимально в ней нужны:
• устойчивый идентификатор и ссылка;
• тип источника;
• владелец содержания;
• дата и версия;
• статус согласования;
• область покрытия;
• связанные противоречия и пробелы.
Полезно отделять качество самого документа от его авторитетности. Подробная страница может быть устаревшей. Короткий approved decision может иметь больший нормативный вес, хотя объясняет меньше. Новый файл не всегда главнее старого: дата ничего не говорит о владельце, области действия и праве отменять предыдущее решение.
Конфликт в Source Map стоит хранить как отдельный объект, а не как комментарий внутри одной строки:
text
Conflict: AUTH-03
Source A: API contract v3; OAuth 2.0 required
Source B: prototype README; API key
Scope: production authentication
Owner needed: integration owner
Status: unresolved
Такая запись не разрешает конфликт. Она не даёт агенту выбрать OAuth только потому, что контракт новее, или API key только потому, что прототип уже работает. Она показывает, какое решение отсутствует и кто должен его принять.
После решения Source Map тоже не исчезает. В неё добавляют ссылку на decision record, дату вступления решения в силу и перечень источников, которые оно заменило. Это позволяет позже объяснить, почему спецификация опиралась именно на эту версию.
Для агента карта задаёт дисциплину чтения. Он может найти расхождение, сгруппировать свидетельства и подготовить вопрос владельцу. Он не должен превращать статистическую правдоподобность в организационное полномочие.
Source Map полезна не потому, что создаёт единую истину. Она делает видимым, где истина подтверждена, где ограничена областью действия, а где команда пока живёт с несколькими несовместимыми версиями.