Architecture decision records are great, and you should write them. But ADR\ntooling shares one assumption: that a decision lives in one file and stays there.\nIf your real decisions live across Slack, GitHub, Jira and Confluence and keep\nchanging, you'll eventually want something that fits that reality. Here are the\nalternatives and how they compare.
\nIf you haven't picked an ADR tool yet, start with ADR tools\ncompared; this piece is about what comes after.
\n| Approach | Examples | Strength | Limit |
|---|---|---|---|
| Plain ADR files | adr-tools, Markdown | Simple, in-repo | One file, doesn't track change across tools |
| Static ADR site | Log4Brains | Browsable archive | Still file-centric, manual updates |
| Wiki / docs | Confluence, Notion | Familiar, durable | Goes stale, no conflict detection |
| Decision bots | Slack decision trackers | Low-friction capture | Isolated list, no cross-tool links |
| Decision graph | Align | Captures + links + catches conflicts across tools | Not a plain-text-only tool |
Every option lands somewhere on two axes: how low-friction is capture, and\nhow well does it stay connected and current after capture.
\nAlign is the alternative when:
\nIt doesn't replace ADRs. Keep writing ADRs for the big architectural calls and let\nAlign keep them connected to what's actually happening across your tools.
\nIf you're small and your ADR files are still accurate, you don't need an\nalternative yet, and adopting heavier tooling would be premature. The alternatives\nabove earn their place once \"the decision is in the file\" stops being true,\nwhich for most teams happens somewhere past 50 engineers and a few squads.
\nRelated reading: ADR tools compared (2026) and\nDecision log software.
", "url": "https://docs.align.tech/blog/alternatives-to-adr-tools", "title": "Alternatives to ADR tools when decisions live across many tools", "summary": "ADR tools assume decisions live in one file. When yours live across Slack, GitHub, Jira and Confluence, here are the alternatives and how they compare.", "date_modified": "2026-05-27T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "comparison", "adr", "alternatives", "decision-log" ] }, { "id": "https://docs.align.tech/blog/align-vs-confluence-decisions", "content_html": "If you're an Atlassian shop, Confluence is probably already your system of record,\nand you've likely got a decision-log or ADR space in there. This compares how\nConfluence holds up for engineering decisions versus a decision graph like\nAlign, and why the two work well together.
\nFor big, deliberate decisions that warrant a written page, Confluence is a fine\nhome. You should keep using it for those.
\n| Confluence | Align | |
|---|---|---|
| Capture | Manual page authoring | Explicit flag where the decision happens |
| Stays current | Only if someone edits the page | Yes, tracks supersession across tools |
| Cross-tool links | Jira-centric | Slack/GitHub/Jira/Teams/Confluence |
| Catches conflicts | No | Yes, before code ships |
| Agent-queryable | Prose only | Structured graph via MCP |
| Best at | Durable reviewed docs | Live decision layer at scale |
This isn't rip-and-replace. Align connects to Confluence as\none of its sources, so the decisions captured in Confluence pages become part of\nthe graph alongside the ones from Slack, GitHub and Jira. Keep Confluence for the\nbig written records; let Align keep the whole decision layer connected and current,\nand flag conflicts before they cost you rework.
\nRelated reading: Decision log software and\nArchitecture Decision Records: the complete\nguide.
", "url": "https://docs.align.tech/blog/align-vs-confluence-decisions", "title": "Align vs Confluence for engineering decisions", "summary": "Confluence is the system of record many teams already have. Why it struggles to keep decisions current, and how a decision graph complements it.", "date_modified": "2026-05-26T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "comparison", "confluence", "decision-log", "engineering-decisions" ] }, { "id": "https://docs.align.tech/blog/align-vs-notion-decision-log", "content_html": "Plenty of teams start their decision log as a Notion database. It's a reasonable\nfirst move, and for a small team it can be enough. This is an honest look at where\na Notion decision log works, where it breaks, and when a decision graph like\nAlign is the better fit.
\nIf you're a handful of engineers and decisions are infrequent, a Notion table is\na perfectly good decision log. Don't over-engineer it.
\n| Notion decision log | Align | |
|---|---|---|
| Capture | Manual, in Notion | Explicit flag where the decision happens |
| Lives where work happens | No, separate page | Yes, linked across Slack/GitHub/Jira/Teams/Confluence |
| Tracks change over time | Only if someone edits it | Yes, supersession chain |
| Catches cross-team conflicts | No | Yes, before code ships |
| Built for AI agents to query | Prose only | Structured graph via MCP |
| Best at | Docs, wikis, light logs | Decision tracking at scale |
Stay on Notion if you're small and your log is still accurate. Switch when:
\nNotion and Align aren't mutually exclusive. Keep Notion for docs and specs; use\nAlign for the live decision layer that has to stay current\nacross tools.
\nRelated reading: Decision log software: how teams track\ndecisions and Why decisions get lost in\nSlack.
", "url": "https://docs.align.tech/blog/align-vs-notion-decision-log", "title": "Align vs Notion for tracking engineering decisions", "summary": "Notion is great for docs and terrible for keeping engineering decisions current. How a Notion decision log compares to a decision graph, and when to switch.", "date_modified": "2026-05-25T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "comparison", "notion", "decision-log", "engineering-decisions" ] }, { "id": "https://docs.align.tech/blog/decision-log-software", "content_html": "A decision log is a record of the significant choices your team makes: what was\ndecided, why, who was involved, and what changed later. The idea is old and\nsound. The hard part has always been keeping the log current without it becoming\na chore nobody does.
\nThis is a look at how teams track decisions today, where each approach falls\ndown, and what to look for if you're evaluating decision tracking software.
\nMost teams move through these in order as they grow:
\nEach step lowers the friction of capturing. The real differentiator at the top\nof the spectrum is what happens after capture.
\nSpreadsheets, ADR files, and bots all share one failure mode: the decision gets\ncaptured once and then drifts out of date, because decisions don't stop changing\nafter you log them.
\nYou log \"we'll use Postgres for the event store.\" Two months later the load\nprofile changes, someone reopens it in a meeting, and the new direction never\nmakes it back to the log. Now the log is actively misleading: it tells new\nengineers and AI agents something that's no longer true.
\nThe other failure mode is isolation. A decision logged in a spreadsheet has no\nlink to the PR that implemented it, the ticket that tracks it, or the\ncontradicting decision another team just made. It's a record, not a connected\nsource of truth.
\nIf you're evaluating tools, the questions that matter at scale:
\nAlign is decision tracking software built for the top of\nthat spectrum. Engineers flag decisions with an explicit action where they happen,\nAlign links them into a graph across your tools, tracks how they change, and\nsurfaces cross-team conflicts before they ship. Humans and AI agents query the\nsame source of truth.
\nIt's worth being clear about scale: if you're a small, tightly-knit team that can\n\"just ask,\" a spreadsheet or a few ADRs may be all you need. The pain Align\nsolves shows up at 50+ engineers, multiple squads, and cross-team dependencies,\nwhere informal communication has hit its ceiling and decisions are slipping\nthrough the cracks.
\nAudit your current log honestly: open it and check how many entries are still\naccurate. If it's drifted, that's the signal that capture-and-forget isn't enough\nand you need something that keeps decisions connected to reality. See how Align\nworks.
\nAlign captures engineering decisions across Slack, GitHub, Jira, Teams and\nConfluence, links them into a queryable graph, and catches cross-team conflicts\nbefore they ship. Related reading: Why decisions get lost in\nSlack.
", "url": "https://docs.align.tech/blog/decision-log-software", "title": "Decision log software: how engineering teams actually track decisions", "summary": "What a decision log is, why spreadsheets and bots don't scale, and what to look for in decision tracking software for engineering teams in 2026.", "date_modified": "2026-05-24T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "decision-log", "decision-tracking", "engineering-decisions", "tools" ] }, { "id": "https://docs.align.tech/blog/adr-tools-compared", "content_html": "There's no dominant tool for architecture decision records, which is a useful\nsignal in itself: the field is young and most teams are still figuring out what\nthey actually need. This is an honest comparison of the real options, what each\nis good at, and the problem none of them solve.
\nIf you're new to ADRs, start with the complete\nguide and come back here\nwhen you're picking tooling.
\n| Tool | Type | Stores | Best for | Watch out for |
|---|---|---|---|---|
Plain Markdown in /docs/adr | Convention | Repo | Almost everyone, to start | No tooling means no nudges |
| adr-tools | Bash CLI | Repo | Solo / small repos, zero deps | Bash only, unmaintained-ish |
| dotnet-adr | .NET global tool | Repo | .NET shops, templating | Tied to the .NET toolchain |
| Log4Brains | CLI + static site | Repo + site | Teams wanting a browsable archive | Another site to host |
| adr-manager | Web UI over GitHub | Repo (via UI) | Non-CLI contributors | Web app dependency |
| Align | Decision graph | Across all tools | Teams past the \"ADRs go stale\" wall | Not a plain-text-only tool |
For most teams, a docs/adr/ folder with numbered Markdown files and the Nygard\ntemplate is enough to start, and you shouldn't let anyone talk you out of it. Zero\ndependencies, lives with the code, reviewable in PRs, readable by humans and\nagents. The downside is purely that there's no tooling to prompt you, so it\nrelies on discipline.
Start here. Adopt a tool only when you feel a specific pain Markdown can't solve.
\nThe original. Bash scripts that scaffold and number ADRs in the Nygard format.\nGreat if you're in a Unix shell all day and want the numbering and superseding\nlinks handled for you. It's lightweight to the point of being barely a tool,\nwhich is the appeal. Maintenance has been quiet, so don't expect new features.
\nA .NET global tool with templating support. If your shop is .NET-first, this fits\nyour existing toolchain and gives you more structure than the bash scripts. Less\nrelevant outside that ecosystem.
\nLogs ADRs from your editor and publishes them as a static knowledge-base site.\nThis is the pick if you want a browsable, searchable archive your whole org can\nread without cloning the repo. The trade-off is you're now hosting and\nmaintaining that site.
\nA web UI for creating and managing ADRs stored as Markdown in GitHub. Good for\nbringing in non-CLI contributors (PMs, architects who don't live in a terminal).\nYou're depending on the web app, but the underlying files stay in your repo.
\nEvery tool above is a better way to write and store ADRs. None of them solve the\nreason ADRs fail in practice: decisions don't stay in the file.
\nYou write ADR 0007. Six weeks later the decision changes in a Slack thread, a\ndifferent squad ships against the old assumption, and a Jira ticket quietly\ncontradicts the ADR. Nobody updates the file, because the decision happened\nsomewhere the ADR tool can't see. Now you have two sources of truth and two teams\nwho each think they're right.
The ADR tools all assume the decision lives in one place (the file) and stays\nthere. Real decisions live across Slack, GitHub, Jira and Confluence, and they\nmove. That's the gap.
\nAlign is the next step when you hit that wall. Instead of\nstoring decisions in one file format, it captures them where they actually happen,\nlinks them into a graph across all your tools, and flags when a new decision\ncontradicts an existing one before it ships. It complements ADRs rather than\nreplacing them: keep writing ADRs for the big architectural calls, and let Align\nkeep them connected to reality.
\nThe signal that you're ready: you're already feeling the \"wait, didn't we decide\nthis differently in Slack last month?\" pain, and your ADRs are drifting out of\nsync with what the org actually does.
\nAlign captures engineering decisions across the tools your team already uses and\ncatches cross-team conflicts before they ship. Related reading: Architecture\nDecision Records: the complete\nguide.
", "url": "https://docs.align.tech/blog/adr-tools-compared", "title": "ADR tools compared (2026): from CLI scripts to decision graphs", "summary": "A practical comparison of architecture decision record tools in 2026: adr-tools, dotnet-adr, Log4Brains, adr-manager, plain Markdown, and when you outgrow all of them.", "date_modified": "2026-05-23T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "adr", "architecture-decision-records", "tools", "comparison" ] }, { "id": "https://docs.align.tech/blog/shared-context-for-ai-coding-agents", "content_html": "Your AI agents have most of the inputs they need. They can read the codebase,\nthe tests, the types, the git history, the open PRs. All of that is\ndeterministic and right there.
\nWhat they can't see is why. Why the retry count is three and not five. Why this\nservice owns that table. Why the team walked back the obvious approach six weeks\nago. That reasoning lives in a Slack thread, a meeting nobody recorded, a Jira\ncomment, or someone's head. The agent never sees it, so it ships code against\ndecisions it doesn't know exist.
\nThe capability of frontier models stopped being the limiting factor a while ago.\nAs swyx puts it, context engineering is the new prompt engineering: what matters\nnow is the quality of context the agent operates on, not how clever the model is.\nSimon Maple frames the same shift as \"CI/CD for context\", the focus moving from\nmanaging code to managing the context around it.
\nBoth are pointing at the same gap. We've gotten good at giving agents the\ndeterministic inputs. We've done almost nothing about the one input that's\nhardest to capture and most expensive to miss: the decisions.
\nA CLAUDE.md or a rules file is a great start. But it's a static snapshot, hand-\nmaintained, and it captures conventions, not the live stream of decisions your\norg makes every day. It tells the agent your house style. It doesn't tell the\nagent that yesterday a different squad decided to deprecate the endpoint this\nagent is about to build against.
Decisions aren't static config. They happen continuously, across tools, and they\nchange. A useful context layer for agents has to track that, not freeze it.
\nHere's the thing well-run teams discover. Small teams handle missing context by\nasking each other, and it works fine. But an agent can't tap a colleague on the\nshoulder. Even a team with great human communication has to give its agents\nstructured context explicitly, because the agent has no informal channel to fall\nback on.
\nSo the moment you put agents into a real org, you need the decision context\nwritten down and queryable, whether or not your humans needed it before. The graph\nis the organizational memory agents are missing.
\nThe tempting shortcut is to point the agent at your tools over MCP and let it\nread everything. The problem is volume and noise. An agent querying raw Slack is\nsifting 50,000 unstructured messages to maybe reconstruct one decision, burning\ntokens and still missing the contradictions.
\nAn agent querying a decision graph gets the opposite: structured decisions, with\nconflicts and relationships already resolved. One query returns \"here's the\ndecision, here's what superseded it, here's the conflict with the payments\nteam\", instead of thousands of raw messages it has to interpret.
\nThat's the difference between giving an agent a firehose and giving it an answer.
\nAlign sits in the context pipeline as the decision source\nof truth:
\nThe payoff is agents that build with your org's decisions instead of around\nthem, and humans who stop discovering the contradiction in code review.
\nIf you're already running coding agents, the fastest way to feel this gap is to\nask one to explain a non-obvious design choice in your codebase. It'll guess,\nbecause the reasoning was never anywhere it could read. Closing that gap is what\nAlign is for.
\nAlign gives engineering teams and their AI agents one shared, authoritative\nsource of truth for the decisions behind the code. Related reading: Why\ndecisions get lost in Slack and\nArchitecture Decision Records: the complete\nguide.
", "url": "https://docs.align.tech/blog/shared-context-for-ai-coding-agents", "title": "Shared context for AI coding agents: the part your agents can't see", "summary": "AI coding agents ship code from decisions they can't see. Why context engineering is the real bottleneck, and how a decision graph gives agents the organizational memory they're missing.", "date_modified": "2026-05-22T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "ai-agents", "context-engineering", "engineering-decisions", "llm" ] }, { "id": "https://docs.align.tech/blog/why-decisions-get-lost-in-slack", "content_html": "Most of your team's real decisions don't happen in a doc. They happen in Slack.\nTwo engineers are debating a bug, a third jumps in, someone says \"ok let's go\nwith option 1,\" and that's it. The decision is made. Then the thread scrolls\naway and the reasoning goes with it.
\nA few weeks later someone asks \"wait, why does this work this way?\" and nobody\ncan find the answer. It's in Slack somewhere. Good luck.
\nIf you've got eight engineers in one room, you don't feel this. Someone forgets\nwhy a thing was built a certain way, they ask, somebody remembers. Small,\nwell-run teams genuinely do \"just ask\" and it works.
\nIt breaks at scale. Past 50 engineers, multiple squads, and cross-team\ndependencies, \"just ask\" stops working because:
\nSo the failure isn't that your team is sloppy. It's that informal communication\nhas a ceiling, and you've grown past it. The tools that work at ten people quietly\nstop working at a hundred, and nobody notices until the rework starts.
\nSlack is brilliant for conversation and terrible for memory, by design:
\nThe result is a workspace full of decisions with zero traceability. Hundreds of\ndecisions, no trail back to any of them.
\n\"Just write an ADR / Confluence page.\" Right instinct, and you should. But\nthe decision happened in Slack, and asking everyone to stop, switch tools, and\nwrite it up is friction. Most of the time it doesn't happen, and when the\ndecision later changes in another Slack thread, the doc goes stale and now you\nhave two contradictory sources of truth.
\n\"Pin important messages.\" Pins don't scale past a handful and nobody curates\nthem.
\n\"Use a /decision bot.\" Closer. It captures the moment, but it's still manual,\nit lives in a separate list, and it doesn't connect to the decision when it\nchanges in GitHub or Jira later.
\nThe pattern: every fix asks a human to do extra work at exactly the moment they're\ntrying to move on. That's why decisions keep slipping through.
\nThe decision needs to be captured where it happens, linked to everywhere it's\nrelevant, and flagged when something later contradicts it. Three properties:
\nThat last one is the part no doc or bot gives you, and it's the part that saves\nthe weeks of rework.
\nThis is what we built Align to do. You connect Slack (and\nGitHub, Jira, Teams, Confluence), engineers flag decisions with a quick explicit\naction (no passive surveillance, you stay in control of what's captured), and\nAlign links them into a graph your team and your AI agents can both query. When\ntwo teams head in contradictory directions, it surfaces the conflict early.
\nYou don't have to boil the ocean. Start by noticing how often someone on your\nteam asks \"didn't we already decide this?\" or \"why does this work this way?\" Those\nquestions are the cost of lost decisions, and once you start counting them you'll\nsee how much they add up to.
\nWhen you're ready to stop paying that cost, see how Align works.
\nAlign captures engineering decisions across Slack, GitHub, Jira, Teams and\nConfluence, links them into a queryable graph, and catches cross-team conflicts\nbefore they ship. Related reading: Architecture Decision Records: the complete\nguide.
", "url": "https://docs.align.tech/blog/why-decisions-get-lost-in-slack", "title": "Why decisions get lost in Slack (and how to fix it)", "summary": "Slack is where engineering decisions happen and where they disappear. Why threads, search and channel speed bury the decisions that matter, and what to do about it as your team scales.", "date_modified": "2026-05-21T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "slack", "engineering-decisions", "tribal-knowledge", "documentation" ] }, { "id": "https://docs.align.tech/blog/architecture-decision-records-complete-guide", "content_html": "An architecture decision record (ADR) is a short document that captures one\nsignificant decision: what you decided, why, what you considered, and what it\ncosts you later. One decision per file. Plain text, in the repo, next to the\ncode it governs.
\nThat's the whole idea. The reason ADRs are having a comeback in 2026 isn't\nnostalgia. It's that AI coding agents now write a lot of your code, and an agent\nthat can't see why something was built a certain way will happily refactor the\nreason away.
\nFor years ADRs were a nice-to-have that most teams skipped. Then two things\nhappened.
\nFirst, teams got bigger and more distributed. Past 50 engineers and a few\nsquads, you can't \"just ask\" anymore. The person who knows why the payment\nservice retries exactly three times has left, or is on holiday, or is in a\ndifferent timezone. The decision lives in someone's head, or in a Slack thread\nthat scrolled off three months ago.
\nSecond, agents arrived. An AI agent refactoring \"verbose\" retry logic doesn't\nknow that code was written that way after a Black Friday incident double-charged\nthousands of customers. The verbosity was the decision. Strip it and you\nreintroduce the bug. The agent had no way to see the reasoning, because the\nreasoning was never written down anywhere it could read.
\nADRs fix the upstream problem: they put the reasoning somewhere durable, in\nplain text, where both a new hire and an agent can find it.
\nKeep it short. If it takes more than ten minutes to write, the format is\nfighting you. The classic Michael Nygard structure is still the best starting\npoint:
\n# ADR 0007: Use Postgres for the event store
- Status: Accepted
- Date: 2026-05-20
- Deciders: platform team
## Context
We need durable, ordered, queryable storage for domain events. We already run
Postgres in production and the team knows it well. Kafka was considered but adds
operational surface we don't have the headcount to own yet.
## Decision
Use a single Postgres table as the event store, with a monotonic sequence
column for ordering. Revisit if event volume exceeds ~10k/sec sustained.
## Consequences
- Easier: one less system to operate, transactional writes alongside state.
- Harder: we own partitioning/retention ourselves; no built-in fan-out.
- Committed: consumers read by sequence, so that column is now load-bearing.
Number them sequentially (0001, 0002...). Never delete one. When a decision\nchanges, write a new ADR that supersedes the old one and link them. The chain\nof decisions is the value, not any single record.
There's no dominant tool, which tells you the field is young. What exists:
\n| Tool | What it is | Good for |
|---|---|---|
adr-tools (Nygard) | Bash CLI, Nygard format | Solo / small repos, zero deps |
dotnet-adr | .NET global tool, templates | .NET shops |
| Log4Brains | Logs ADRs, publishes a static site | Teams that want a browsable archive |
| adr-manager | Web UI over Markdown in GitHub | Non-CLI contributors |
Just Markdown in /docs/adr | No tool at all | Most teams, honestly |
For a lot of teams, a folder of Markdown files and a numbering convention is\nenough to start. The tooling question only matters once you hit the real\nproblem, which isn't writing ADRs.
\nHere's what nobody tells you when they recommend ADRs. The hard part isn't the\ntemplate. It's that decisions don't stay in the ADR file.
\nYou write ADR 0007: use Postgres for the event store. Six weeks later someone\nproposes Kafka again in a Slack thread, a different squad ships against the old\nassumption, and a ticket in Jira quietly contradicts the ADR. Nobody updated\nthe file, because updating the file is friction and the decision happened\nsomewhere else.
So you end up with two sources of truth: the ADR that says one thing, and the\nactual current state of the org that says another. Both teams think they're\nright. Neither sees the conflict until it shows up as rework.
\nThis is the gap we built Align to close. ADRs are the\nright instinct: write decisions down. The missing piece is keeping them\nconnected to where decisions actually get made and changed (Slack, GitHub,\nJira, Confluence, calls) and flagging when a new decision contradicts an\nexisting one before it ships, not after.
\nYou don't need a tool to start. Today:
\ndocs/adr/ folder to your main repo.0001-record-architecture-decisions.md\n(the first ADR is always \"we're going to use ADRs\").0002.Then, once you've got a handful and you're already feeling the \"wait, didn't we\ndecide this differently in Slack last month?\" pain, that's the moment a\ndecision graph earns its place. That's the problem Align\nexists for.
\nWhat is an architecture decision record?\nA short document that captures one significant architecture decision: the context,\nthe decision itself, and its consequences. One decision per file, in plain text,\nstored next to the code it governs.
\nWhat should an ADR contain?\nTitle, status (proposed/accepted/superseded), context (the forces in play),\nthe decision stated plainly, and the consequences (what gets easier, harder, and\nwhat you're now committed to).
\nAre ADRs still worth it in 2026?\nYes, and more than before. AI coding agents will refactor away reasoning they\ncan't see. ADRs put that reasoning somewhere durable that both new hires and\nagents can read.
\nWhat is the best ADR tool?\nFor most teams, plain Markdown files in docs/adr/ are enough to start. Adopt a\ntool (adr-tools, Log4Brains, dotnet-adr) only when you feel a specific pain\nMarkdown can't solve. See ADR tools compared.
Why do ADRs go stale?\nBecause decisions don't stay in the file. They change in Slack, GitHub and Jira,\nand nobody updates the ADR. Keeping ADRs connected to where decisions actually\nchange is the problem Align solves.
\n\n\nAlign captures engineering decisions across the tools your team already uses,\nlinks them into a queryable graph, and catches cross-team conflicts before they\nship. See how it works.
", "url": "https://docs.align.tech/blog/architecture-decision-records-complete-guide", "title": "Architecture Decision Records: the complete guide (2026)", "summary": "What architecture decision records are, why teams are bringing them back, a copy-paste ADR template, and how to keep them from going stale across Slack, GitHub, Jira and Confluence.", "date_modified": "2026-05-20T00:00:00.000Z", "author": { "name": "The Align Team", "url": "https://align.tech" }, "tags": [ "adr", "architecture-decision-records", "engineering-decisions", "documentation" ] } ] }