The why behind your architecture, captured.
Architectural decisions mined from eight sources, evidence-backed, linked to the graph, and connected by supersession lineage. This is the context that usually leaves when people do.
The reasoning behind your architecture lives in people's heads, scattered PRs, and stale markdown. When the people leave, the why leaves with them.
A codebase tells you what the code does, never why it is shaped that way. repowise mines that rationale from everywhere it was recorded, backs each decision with evidence, links it to the code it governs, and ages it as the code changes, so the why stays with the codebase.
A decision layer, not a dusty folder.
Mined from eight sources, evidence-backed, linked to the graph, and kept honest about staleness.
Mined from everywhere the rationale was recorded
Teams write decisions down in many places and most of them are not an ADR folder. repowise reads all of them and unifies them into one decision layer, so the rationale is captured wherever it actually lives.
- ADR files, CHANGELOGs, and READMEs
- PR bodies and inline decision markers in code
- Git archaeology over commit history
- Code comments and LLM generation over the wiki
Every decision carries its proof
A decision you cannot trace is a guess. repowise attaches a verification status and the exact evidence spans behind each decision, so you can read the source passage instead of taking the claim on faith.
- Verification status: verified, fuzzy, or unverified
- Evidence spans pointing at the supporting passages
- Fuzzy and unverified decisions surfaced honestly, never invented
- Returned with the rationale through the get_why MCP tool
A graph of decisions that ages with the code
Decisions evolve, supersede each other, and sometimes conflict. repowise connects them into a decision graph and tracks how current each one is against the code it governs.
- Supersedes, refines, and conflicts_with edges form the lineage chain
- Each decision linked to the graph nodes it governs
- Decisions age when the files they govern get commits
- Contradictory decisions flagged rather than silently coexisting
Decisions that show up where review happens
A decision only matters if it surfaces at the moment of change. repowise carries decisions into PR risk reviews so reviewers see governance gaps before a merge, not after an incident.
- Surfaced in PR risk reviews alongside the diff
- Ungoverned hotspots flagged when no decision applies
- Contradictory decisions flagged on the change
- Deterministic governance signal, no LLM in the scoring path
From scattered rationale to a queryable decision graph.
Mine
repowise reads eight sources, from ADR files to git archaeology, and extracts the architectural decisions recorded across your repo.
Verify
Each decision gets a verification status and evidence spans, so verified claims are traceable and fuzzy ones are flagged as such.
Link
Decisions are connected by supersedes, refines, and conflicts_with edges and tied to the graph nodes they govern.
Track
Decisions age as the governed files change, and get_why returns the rationale, lineage, and staleness in one call.
The why, everywhere it helps.
In your AI agent
get_why returns the decision, status, evidence spans, and lineage over MCP, so the agent reasons before it refactors.
On every PR
The Repowise PR Bot flags ungoverned hotspots and contradictory decisions, deterministically, with no LLM in the scoring path.
In the dashboard
A dedicated Decisions view with status, evidence, lineage chains, and the files each decision governs.
Next to the code
get_context surfaces the governing decisions for any file or module right alongside its docs and ownership.
When no ADRs exist
get_why falls back to git archaeology so you still get the most likely rationale instead of an empty answer.
For knowledge retention
The context that usually leaves when senior engineers do, captured with the codebase instead of in their heads.
No competitor in the wiki or code-quality categories tracks architectural decisions at all. repowise captures the rationale that is otherwise lost to memory, backs it with evidence, links it to the graph, and ages it as the code changes.
Questions, answered
Where do the decisions come from?
repowise mines architectural decisions from eight sources, not just an ADR folder: ADR files, CHANGELOGs, PR bodies, inline markers in code, git archaeology, READMEs, code comments, and LLM generation over the indexed wiki. The result is a single decision layer that captures rationale wherever your team actually recorded it, even when they never wrote a formal record.
How are decisions verified?
Every decision carries a verification status: verified, fuzzy, or unverified. A verified decision is backed by concrete evidence spans, the exact passages in ADRs, commit messages, PR bodies, or comments that support it, so you can read the source and trust the claim. Fuzzy and unverified decisions are surfaced honestly rather than presented as fact, so nothing is invented without provenance.
What is decision lineage and supersession?
Decisions rarely stand alone. repowise connects them with supersedes, refines, and conflicts_with edges into a decision graph, so you can follow a chain from the original choice through every later revision. When a newer decision supersedes an older one, the lineage records it, and contradictory decisions are flagged rather than silently coexisting.
How does staleness work?
A decision is only as current as the code it governs. Each decision is linked to graph nodes, the files and modules it applies to, and it ages when those files get commits. As the governed code drifts away from the recorded rationale, repowise marks the decision as stale so you know when the why no longer matches the what.
What is get_why?
get_why is the MCP tool that returns architectural decision rationale in a single call: the decision, its status, the evidence spans behind it, and its supersession lineage chain. It is the tool an AI agent or a reviewer calls to answer why is the code shaped this way before a refactor. When no ADRs exist for a file, get_why falls back to git archaeology so you still get the most likely rationale instead of an empty answer.
How is this different from a regular ADR folder?
A folder of ADR markdown files only captures the decisions someone remembered to write down, and it never tells you when one goes stale. repowise mines eight sources, attaches a verification status and evidence spans, links each decision to the graph, tracks staleness as the code changes, connects decisions by lineage, and surfaces governance risk in PR reviews. It is the difference between a static archive and a living decision layer.
How do decisions show up in code review?
Decisions are governance-aware. They surface in PR risk reviews so reviewers see when a change touches code governed by an existing decision, when a hotspot has no decision governing it at all, and when two decisions contradict each other. The Repowise PR Bot can flag these ungoverned hotspots and contradictory decisions deterministically, with no LLM in the scoring path.
Is the decision layer open source?
Yes. repowise is open source under AGPL-3.0, so every step of how decisions are mined, verified, linked, and aged is inspectable and reproducible on your own repo. The same decision layer is available self-hosted and on the paid hosted tier.