依我的經驗，架構決策的形成往往與其必須滿足的需求相距甚遠。產品、安全性、可靠性、營運和組織技術職能各自透過不同流程表達關切事項；架構師只把部分脈絡轉化為結構性決策；工程師的實作詮釋又可能偏離架構師的原意。AI 輔助交付會放大這種分離。AI 程式開發代理可根據不完整的需求、片面的架構知識和看似合理的推論依據，迅速產出連貫的實作，使需求、架構決策和實作之間的差異在負責人察覺前便持續擴散。
近期的實證研究說明了這項觀察為何日益重要。Zhou 等人從 Stack Overflow 貼文、GitHub issue 和 GitHub discussion 彙整 100 組架構問題與決策，再使用三種提示策略，要求五個大型語言模型產生或還原設計理由。模型找回了許多由人類專家記錄的考量，也補充了評估者認為有幫助的觀點；然而，它們同時產生不確定或誤導性的論述，而且經常欠缺專家理由中所包含的實務經驗與特定脈絡細節。後續訪談中，實務工作者一致認為，模型必須掌握專案脈絡才能獲得信任；多位受訪者也表示，在採用生成的理由前，仍須由人員進行大幅審查。1 這些發現揭示三個相互關聯的交付問題：可靠的產品脈絡從何而來、AI 參與者如何辨認哪些架構知識具有權威，以及一項看似合理的架構陳述如何成為組織決策。單靠更好的生成能力無法回答這些問題。
規格先行交付將架構知識視為知識系統中受治理的一部分。產品需求、組織技術方向、安全性與私隱要求、可靠性目標、營運條件、成本限制、既有實作證據和過往決策，均以具名輸入的形式進入架構討論。負責架構決策的人員審查由此形成的決策與理由。經核准的知識隨後透過發佈，供後續的結構化討論和技術規格工作使用。
本文提出一套整合這些工作的生命週期：
確立適用的輸入與架構問題；
透過結構化架構討論形成決策與理由；
區分架構現況、已核准方向、務實的架構願景與條件式變更；
將撰寫者身分與決策權限分開；
透過受治理的來源發佈已核准知識與架構決策紀錄（Architecture Decision Record，ADR）；
為每一筆受維護的架構紀錄指定負責人和下次審查日期；以及
要求後續交付工作採用適用的架構知識，並將衝突提交給擁有適當決策權的人員。
先前研究已確認架構決策、理由、利害關係人參與、時間順序、擷取、維護、共享與重用都是重要課題。近期研究亦探討 ADR 自動生成、脈絡選取、從會議還原決策，以及 AI 輔助的架構知識系統。規格先行交付把這些課題與受治理的輸入、AI 輔助討論、人員決策權、發佈、適用性語意、下游規格和持續審查連接成同一個交付生命週期。
1. 架構知識及其交付角色
架構知識持續保存產品結構背後的判斷，讓參與者理解產品為何採用目前的結構、哪些架構決策適用、哪些已核准變更應影響新工作、哪些依賴關係至關重要，以及誰有權核准變更。因此，它不能只有圖表或元件清單，還要包含決策、假設、理由、脈絡與關係，以說明可見設計為何存在，以及它可能如何演進。2 以決策為中心的軟件架構觀點，部分正是為了回應「知識蒸發」：若決策只隱含在最終結構中，設計知識便會消失。明確記錄決策，參與者便能查閱形成目前架構的原因，不必單憑程式碼推斷，也更能支援後續開發與演進。3
在規格先行交付中，架構知識是連接產品層級關切事項與增量層級執行的長期交付脈絡，承擔兩項相互關聯的責任：
說明後續工作必須理解或保留的架構；以及
把已核准的架構判斷帶入引導實作的規格。
下列形成與重用流程同時履行這兩項責任。確立輸入並形成決策，會產生受維護的架構說明與判斷；審查和發佈使其取得權威；後續工作把它們帶入規格，再將實作證據送回持續審查。
確立輸入
蒐集適用的需求、組織方向、限制、過往決策、依賴關係和實作證據。
形成決策
透過架構討論比較務實選項，並記錄決策、理由、假設和未決事項。
審查並發佈
決策負責人確認結果，並將其發佈為具有權威的架構知識。
採用並審查
後續討論與技術規格採用相關知識；實作證據和新知則觸發維護與審查。
需求或組織方向提出架構必須滿足的條件，架構則把適用條件轉化為結構性決策。例如，產品負責人可訂定營運成本上限，可靠性職能可定義復原目標，安全性職能可定義獲核准的信任模型，而組織可選定 Kafka 作為支援的事件平台。架構決策負責人再決定哪些責任、部署模型、資料流或整合模式可為產品滿足這些輸入。
產品
產品行為和優先順序界定架構必須支援的能力。
- 輸入：透過目前的介面及未來的對話式介面，持續提供行程規劃功能。
- 架構問題：規劃邏輯應置於何處，才不會由特定介面的程式碼擁有？
組織
組織層級的技術方向指出獲支援的平台與共通工程選擇。
- 輸入：新的非同步整合採用組織支援的 Kafka 平台。
- 架構問題：哪些產品事件應放上該平台，現有消費者又應如何遷移？
安全性與私隱
安全性和私隱要求界定產品架構必須實現的保護措施。
- 輸入：個人資料只可在獲核准的位置儲存和處理。
- 架構問題：哪些儲存和處理責任可滿足位置要求？
可靠性與營運
可靠性目標和營運條件會影響部署、狀態管理與可觀測性。
- 輸入：達成復原目標，並提供議定的營運訊號。
- 架構問題：哪些部署、狀態管理和可觀測性決策可履行這些義務？
成本
成本要求限制可行的運算、儲存與擴展模型。
- 輸入：工作負載須維持在已核准的營運成本範圍內。
- 架構問題：在預期需求下，哪種運算和擴展模型切合實際？
現有實作
實作證據揭示架構決策必須處理的結構事實與缺口。
- 輸入：某項業務規則目前只存在於使用者介面元件。
- 架構問題：該規則應保留原位、移至應用能力，還是透過另一項獲核准設計取代？
提出需求的角色保留該項需求的決策權；架構決策負責人則保留結構性回應的決策權。架構師可以指出某項復原目標無法達成，但是否更改目標由可靠性職能決定。可靠性專家可以揭示架構風險，但這項發現不會把重新設計產品的權限移交給該專家。
2. 先前研究與貢獻界線
架構知識管理已有相當深厚的研究基礎。一項涵蓋 115 篇研究的系統性文獻回顧，找出 56 種與擷取、使用、維護、共享和重用架構知識相關的方法。研究發現，使用已擷取知識所獲得的支援較完善；在高效率擷取、共享、重用，尤其是長期維護方面，支援則較薄弱。4 決策文件研究亦定義了決策細節、關係、時間順序和利害關係人參與等不同視角。5 這些研究確認：架構知識包含決策與理由；不同利害關係人需要不同視角；維護始終是持續存在的難題。
AI 相關研究是在這個基礎上加入新機制，而非取代它。Dhar、Vaidhyanathan 和 Varma 證明，大型語言模型可根據決策脈絡產生相關架構決策，但表現仍未達人類水平。6 Gupta 等人其後評估來自 750 個開放原始碼儲存庫的連續 ADR，發現具脈絡感知能力的提示可大幅改善 ADR 生成。少量近期 ADR 通常能在品質與效率之間取得最佳平衡，因此脈絡選取是實質的設計考量，不能把所有可用紀錄一概交給模型。7
另一些研究則從討論本身著手。GADR 使用多代理工作流程，從雜訊繁多的會議逐字稿擷取決策並草擬 ADR。其可行性研究也指出一項來源忠實度風險：檢索增強雖可改善 ADR，卻可能加入討論中未曾出現的內容。8 研究者亦提出按需提供的架構知識系統，將其定位為整理相關知識並支援架構師決策的對話式夥伴。9 一項 2026 年的自動化架構知識管理願景更進一步，涵蓋持續擷取、可追溯性、不一致偵測、結構化知識庫，以及在重大更新前要求人員明確確認。10
因此，規格先行交付並不宣稱 AI 輔助架構推理、ADR 生成、知識擷取、人員審查、可追溯性或對話式檢索是全新概念。本文的模型圍繞一項交付治理問題整合這些課題：架構知識如何從具權威的產品輸入形成、取得人員授予的權威、清楚說明何時適用，並成為後續規格必須採用的推理脈絡。
其中有兩項組合尤其重要。第一，撰寫者身分與權威是兩項獨立屬性。AI 參與者可以草擬討論紀錄、ADR 或架構更新；只有擁有相關決策權的角色審查內容，並透過受治理的來源發佈後，紀錄才取得權威。第二，架構知識的適用性與 ADR 的生命週期狀態互相獨立。已接受的 ADR 可以描述尚未成為架構現況的已核准方向。
3. 透過架構討論形成知識
架構知識透過討論形成，因為結構性決策必須協調多種專業職責的輸入。討論可以在會議、書面交流或人機協作工作階段進行，採用哪種形式屬於實作選擇。必要成果是一份可供審查的紀錄，把問題、適用輸入、決策、理由、負責人與後續條件連接起來；若參與者確實考量過有意義的替代方案，也應記錄相關選項。
3.1. 確立決策脈絡
負責準備討論的參與者應蒐集可能對決策造成實質影響的知識：
引發問題的產品行為或變更；
適用的組織方向和產品層級需求；
架構現況和實作證據；
相關 ADR 和尚未解決的架構討論；
相關的安全性、私隱、可靠性、營運、資料和成本考量；
限制可用選項的依賴關係與外部決策；以及
擁有決策權的角色。
脈絡集合應經過篩選且可追溯。每項納入的來源都要說明理由，討論紀錄也應保留通往權威需求或證據的路徑。檢索可以協助找出候選脈絡，而討論紀錄則要指出參與者實際採用了哪些來源。
3.2. 區分輸入、選項與決策
以下分類是一套建議的討論紀錄範本。AI 可隨結構化討論進展維護紀錄，再由參與者確認內容；實際使用時，只需採用與該項決策相關的分類：
**輸入：**決策必須考量的需求、限制、組織方向、現況事實或依賴條件。
**選項：**若曾考量有意義的替代方案，記錄可供比較且切合實際的結構性回應。
**決策：**在架構決策負責人權限內選定的回應。
**理由：**解釋決策的原因、取捨、證據和假設。
**未決事項：**尚未解決的問題，並列明負責人和所需解決途徑。
這種區分可避免把吸引人的選項當成既有限制。「使用 Azure Functions」是一個架構選項或決策；「把平均運算成本維持在已核准的營運預算內」則是成本輸入。理由必須說明所選運算模型如何回應成本輸入，以及這項選擇帶來哪些後果。紀錄不必重複組織內人人皆知的決策；例如，若整個組織都在 AWS 上運作，而且該方向已有可供查閱的權威來源，產品只需連結該來源，再記錄對本產品產生的具體影響或決策。
3.3. 審查並發佈結果
AI 可以準備第一份完整紀錄，並隨討論進展更新內容。決策負責人其後必須與相關參與者逐行確認，逐一處理不準確的陳述、缺乏支持的理由、與來源需求的衝突，以及超出目前權限的問題。逐行審查不可省略；若只籠統核准整份文件，看似合理的 AI 句子可能留下任何參與者都無意授予的權威或含義。
負責人有意識地發佈經審查的結果後，該決策才成為組織的架構知識。在以儲存庫為核心的知識系統中，這項權威轉換可在架構師或其他獲授權負責人提交、推送並合併紀錄至受治理分支時發生；在文件或架構平台中，則可透過相應的儲存、核准和發佈控制完成。討論工具中可見的草稿，在完成這項轉換前仍然是草稿。
4. 架構知識的適用性
架構知識必須明確說明適用性，因為現況、已核准變更、願景和由依賴條件觸發的意圖，對交付工作的指引方式各不相同。規格先行交付採用四種適用狀態。
架構現況
已實作或目前以其他方式治理產品的架構。
- 必要資訊
- 範圍、支持證據或來源、負責人、上次審查日期和下次審查日期。
- 對後續規格的影響
- 將其視為目前的交付基準並予以保留，除非該項變更有權修改它。
已核准的架構方向
已取得權威，但只完成部分實作或正等待按計畫採用的決策。
- 必要資訊
- 決策負責人、理由、採用範圍、與現況的關係、進度證據和下次審查日期。
- 對後續規格的影響
- 避免加深即將淘汰的架構；當已核准方向適用時，使範圍內的工作與其一致。
架構願景
可處理目前痛點，或具有記錄在案的理由與決策關聯性，但尚未取得實作核准的務實未來狀態。
- 必要資訊
- 痛點或理由、目前的決策關聯性、提案支持者、核准所需證據和下次審查日期。
- 對後續規格的影響
- 考量其影響，但不可視為已獲核准；任何依賴該願景的實作選擇均須升級處理。
條件式架構方向
只有在具名依賴或條件獲滿足後才適用的預定變更。
- 必要資訊
- 現況、觸發條件、預定變更、觸發條件負責人或證據來源、決策負責人和下次審查日期。
- 對後續規格的影響
- 採用預定變更前先確認觸發條件；條件尚未滿足時，繼續以架構現況為依據。
架構願景必須在產品和組織脈絡中切合實際。若目前採用內部部署的單體式架構，則可提出把特定能力移至雲端原生架構的願景，前提是這項願景回應已知的部署或擴展痛點。若某種未來技術與現況無關且缺乏依據，便不具目前的決策關聯性，也不應納入受維護的架構知識。
條件式方向必須列明可觀察的觸發條件。「最終使用 Kafka」會迫使 AI 參與者猜測變更目前是否已獲授權。可用的紀錄應說明：目前的整合會輪詢系統 B；組織的 Kafka 平台提供可供生產環境使用的合約後，產品將採用系統 B 的事件串流；團隊亦須如何確認觸發條件已經發生。
這四種狀態說明架構知識如何適用。ADR 狀態則描述決策紀錄的生命週期，例如提議、接受、取代或拒絕。兩個維度可以並存：一項已接受的決策可建立已核准的架構方向；完成實作並審查後，相關架構知識成為架構現況，而已接受的 ADR 仍保留在決策歷史中。
4.1. 實例：AI 行程規劃產品
假設某行程規劃產品目前透過網頁應用程式服務使用者。其架構知識體系可包含四項互相關聯的陳述：
**架構現況：**行程能力擁有行程狀態和所有已接受的行程變更。網頁應用程式呈現建議變更，而供應商配接器則擷取外部供應情況與價格。
**已核准的架構方向：**規劃行為將透過穩定的應用能力提供，使網頁介面和未來的對話式介面使用相同業務規則。核准遷移範圍內的新規則應置於該能力之後，不再放入特定介面的元件。
**架構願景：**部分工作負載可從目前內部部署的單體式架構移至雲端原生服務。這項願景回應記錄在案的獨立發佈與擴展痛點，但遷移權限和目標服務拆分尚未獲得核准。取得生產需求與營運成本證據後，將進行審查。
**條件式架構方向：**產品目前會輪詢企業客戶平台以取得個人檔案變更。平台負責人發佈可供生產環境使用的合約，並確認所需事件涵蓋範圍後，產品將採用該平台的 Kafka 事件串流。在此之前，輪詢仍屬架構現況。
新行程規則的技術規格會採用架構現況所訂的所有權和已核准方向。若該增量具備遷移權限，便可把規則置於共用規劃能力之後。雲端原生願景只能在其紀錄所述範圍內影響討論；在指定的觸發條件獲確認前，Kafka 方向不會產生實作效力。
5. 架構決策紀錄與討論紀錄
**架構決策紀錄（Architecture Decision Record，ADR）**是架構討論的長期成果。在討論形成決策的同時，從經審查的討論建立 ADR，可保存其推理過程；只要連結能保留必要脈絡，紀錄本身便可維持簡潔。
建議的 ADR 範本包含：
標題
說明
理由
決策者
決策日期
相關討論
取代／被取代相關討論可保存曾考量的選項、來源輸入、未決問題和審查參與者。架構決策紀錄則陳述具權威的結果及其來源。決策文件研究支持把決策細節、關係、時間順序和利害關係人參與視為互相連結的視角，而非把決策縮減為單一結論。5
架構討論紀錄為提案和未決問題提供受控制的處理途徑。工程師或 AI 程式開發代理可能發現目前的整合模式妨礙必要變更。參與者應記錄觀察、來源交付工作、理由、受影響知識和所要求的決策。這項發現不會默默修改架構，也不會擴大目前的執行權限。
小型產品使用一個 architecture-discussions.md 檔案可能已經足夠；大型產品則可在 docs/architecture/architecture-discussions/ 下保存獨立紀錄。討論紀錄也可以存放在程式碼儲存庫以外的知識庫。儲存方式只是參考實作；真正必要的是提供一條可發現的途徑，把觀察提交給架構決策負責人，繼而形成具權威的決策或結案結果。
6. 組織並發佈架構知識體系
架構知識體系是一組互相連結的內容，包括現況描述、架構方向、依賴關係、ADR、討論紀錄、外部來源、負責人與審查資訊，供交付參與者使用。列表文件可為人員和 AI 提供穩定的進入點。這套知識可以放在程式碼儲存庫，也可以由外部知識庫維護；無論採用哪種方式，知識系統都必須提供受支援的讀取途徑，讓 AI 程式開發代理和其他交付參與者能夠使用。若採用以儲存庫為核心的實作，README.md 可列出各個來源、範圍、適用性、權威和審查狀態。
精簡的產品結構可以是：
product/產品儲存庫或受治理的知識根目錄。README.md列出具權威的架構來源、負責人、適用性和審查狀態的進入點。architecture.md受維護的架構現況和適用的架構方向。architecture-discussions.md未決提案、問題、來源交付工作及其解決狀態。
較大型的產品結構可以是：
docs/受維護的產品文件。architecture/架構知識體系及其進入點。README.md架構來源、範圍、負責人、適用狀態和審查日期的列表。application-architecture.md應用程式責任與結構性決策。data-architecture.md資料所有權、資料流、資料儲存區及相關決策。integration-architecture.md整合責任、依賴關係與介面。deployment-architecture.md部署責任、環境與平台決策。adr.md架構決策紀錄及其取代關係歷史。architecture-discussions/大型產品分開保存的提案與問題紀錄。
資料夾名稱不構成框架要求。只要參與者能找到具權威的材料、判斷何時適用、識別負責人並查看審查狀態，架構儲存庫、服務目錄、文件平台或知識圖譜均可履行相同責任。
每份受維護的架構文件應說明：
範圍與主題；
權威和決策負責人；
內容的適用狀態；
支持現況陳述的實作證據或決策；
與其他架構來源的關係；
上次審查日期和下次審查日期；以及
提出衝突、更正或提案的途徑。
架構知識體系應包含從外部依賴來源中整理、與產品決策相關的資訊。實用的項目應指出產品為何依賴該外部系統、哪一方是相關資料或能力的權威來源、依賴所採用的介面、目前故障或變更對架構造成的影響，以及任何已核准或條件式架構方向。目前仍在使用的外部系統通常應提供受維護的託管文件，或透過模型脈絡協定（Model Context Protocol，MCP）等可存取介面提供知識。較舊的依賴可能只有靜態手冊、封存資料或供應商檔案，而且變更頻率較低。此時應連結可用來源，並只在架構知識體系內保留穩定、與產品相關的事實、來源資訊和審查責任。
7. 供後續規格採用
後續工作主動採用已發佈的架構知識，知識才會產生作用。單靠檢索並不足夠，因為參與者可能找到數份看似合理的紀錄，卻無法判斷其權威或適用性。
進行結構化討論時，負責的參與者及提供支援的 AI 應：
找出架構進入點和與擬議變更相關的來源；
識別架構現況基準和任何適用的已核准方向；
只按其所述決策關聯性評估架構願景；
確認條件式方向的觸發條件是否已發生；
把架構陳述連接至負責人、理由和來源證據；
揭示衝突、知識缺口和擬議偏離；以及
把每項實質架構決策提交給適當的負責人。
編寫技術規格時，作者應把適用的架構轉化為該增量的實作限制、依賴關係、受保護行為和必要決策。若變更具備所需範圍和權限，規格可實作已核准方向；但不能只因某個選項在技術上看來吸引人，就把願景提升為已核准方向、宣告觸發條件已獲滿足，或自行解決衝突。
架構知識因而成為可執行的推理脈絡，但不會成為自主的執行權限。它協助人員或 AI 參與者判斷適當的實作範圍和取捨，同時把實質決策保留在具名人員的責任之下。
8. 維護、審查與知識收斂
架構知識會隨實作、組織決策、營運證據和依賴關係演進而改變。每個受維護的來源都要列明下次審查日期，因為即使紀錄目前準確，也可能隨產品改變而造成誤導。
審查應檢查：
架構現況知識是否仍與實作證據相符；
已核准方向是否仍獲授權，而其採用狀態是否準確；
架構願景是否仍回應真實痛點並影響目前決策；
條件式觸發因素仍未滿足、已經發生，還是已不再切合實際；
所引用的需求、依賴和外部來源是否仍具權威；
ADR 關係和取代連結是否完整；以及
後續規格是否揭示應納入長期知識的新衝突或經驗。
有些事件會在預定日期前觸發審查，例如實質的實作偏差、組織平台決策變更、安全性或可靠性需求更新、依賴合約改變、導致假設失效的事件，或無法調和兩個權威來源的交付討論。
架構來源互相衝突時，便產生知識收斂責任。參與者記錄衝突及其交付後果，識別來源與負責人，並暫停需要單一答案的依賴決策。負責人解決來源的含義、權威或適用性，再發佈結果。AI 檢索排名、文件新舊或實作便利程度，都不能決定哪項架構主張治理產品。
9. 就緒與驗證
若一位不熟悉產品的合資格參與者，能利用架構知識體系履行指定的交付責任，並把未決事項正確提交，該體系便已就緒。驗證應使用受測參與者實際可用的存取途徑，包括 AI 程式開發代理實際可用的檢索路徑。
向參與者提供一項具代表性的擬議變更，要求其確立：
與變更相關的架構現況；
擁有受影響行為或狀態的系統或能力；
適用的組織、產品、安全性、可靠性、營運和成本輸入；
限制變更的依賴關係和介面；
應影響實作的已核准方向；
可供討論參考、但不授權實作的架構願景；
任何條件式方向，以及確認觸發條件所需的證據；
解釋實質決策的架構決策紀錄與理由；
有權核准偏離的人員或角色；以及
記錄衝突或架構提案的途徑。
參與者若能找出有依據的答案、分辨權威與適用性，並在不虛構架構的前提下提交實質缺口，測試便告通過。未能回答的項目會成為就緒缺口，並須指定負責人和解決途徑；只有當欠缺的知識與目前責任無關，或適當的負責人已解決問題，依賴該知識的交付工作才可繼續。至此，架構知識可直接參與交付：受治理的關切事項已轉化為經審查的決策，以明確適用性發佈，透過證據與定期審查維護，並在後續規格把意圖轉化為軟件變更時反覆使用。
參考資料
- Xiyu Zhou et al. “Using LLMs in Generating Design Rationale for Software Architecture Decisions.” ACM Transactions on Software Engineering and Methodology 35, no. 8 (2026): Article 225. https://doi.org/10.1145/3785010.
- Philippe Kruchten, Patricia Lago, and Hans van Vliet. “Building Up and Reasoning About Architectural Knowledge.” In Quality of Software Architectures, LNCS 4214 (2006): 43–58. https://doi.org/10.1007/11921998_8.
- Anton Jansen and Jan Bosch. “Software Architecture as a Set of Architectural Design Decisions.” In Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (2005): 109–120. https://doi.org/10.1109/WICSA.2005.61.
- Rainer Weinreich and Iris Groher. “Software Architecture Knowledge Management Approaches and Their Support for Knowledge Management Activities: A Systematic Literature Review.” Information and Software Technology 80 (2016): 265–286. https://doi.org/10.1016/j.infsof.2016.09.007.
- Uwe van Heesch, Paris Avgeriou, and Rich Hilliard. “A Documentation Framework for Architecture Decisions.” Journal of Systems and Software 85, no. 4 (2012): 795–820. https://doi.org/10.1016/j.jss.2011.10.017.
- Rudra Dhar, Karthik Vaidhyanathan, and Vasudeva Varma. “Can LLMs Generate Architectural Design Decisions? An Exploratory Empirical Study.” In 2024 IEEE 21st International Conference on Software Architecture (2024): 79–89. https://doi.org/10.1109/ICSA59870.2024.00016.
- Aviral Gupta, Rudra Dhar, Daniel Feitosa, and Karthik Vaidhyanathan. “Context Matters: Evaluating Context Strategies for Automated ADR Generation Using LLMs.” arXiv preprint, presented at the 30th International Conference on Evaluation and Assessment in Software Engineering (2026). https://arxiv.org/abs/2604.03826.
- Lucas Daniel Costa da Silva and Kiev Gama. “GADR: Gathering Architecture Decision Records from Meeting Transcriptions.” arXiv preprint (2026). https://arxiv.org/abs/2608.17694.
- Maryam Razavian, Barbara Paech, and Antony Tang. “The Vision of On-Demand Architectural Knowledge Systems as a Decision-Making Companion.” Journal of Systems and Software 198 (2023): 111560. https://doi.org/10.1016/j.jss.2022.111560.
- Jan Keim and Angelika Kaplan. “From Scattered to Structured: A Vision for Automating Architectural Knowledge Management.” arXiv preprint (2026). https://arxiv.org/abs/2601.19548.