Architectural decisions
Keep the why attached to the code it governs.
Repowise gathers rationale from ADRs, pull requests, history, comments, and other recorded evidence. Each decision carries a status, source evidence, governed files, and its place in the lineage.
Verified, fuzzy, and unverified records stay visibly distinct. Missing ADRs trigger archaeology, not invented certainty.
Read the decision docs- decision sources
- 8
- verification states
- 3
- agent retrieval
- get_why
- LLM calls in PR risk
- 0
ADRs, CHANGELOGs, PRs, markers, git, READMEs, comments, and agent transcripts.
Verified, fuzzy, and unverified remain explicit in the product.
Returns rationale, evidence, lineage, and fallback archaeology in one MCP call.
Governance-risk scoring remains deterministic.
Real generated knowledge
A decision is useful when the source quote and governed code are still visible.
The decision reading surface places status, evidence, governed files, and lineage around the rationale. A developer can inspect the claim, follow the source that supports it, and see whether later work refined or superseded the choice.
Capture: a real Repowise decision record. Verification controls keep extracted rationale reviewable instead of presenting every record as settled fact.

How the index produces it
Mine the record, preserve the lineage, age it with the code.
Decision knowledge is assembled from explicit records and repository history, then connected to the graph so it can appear during reading, retrieval, and review.
- 01 / Mine
Collect recorded rationale
Formal ADRs, pull requests, commit history, comments, READMEs, and inline markers contribute candidate decisions and their source spans. - 02 / Link
Connect decisions to code and each other
Governed files and modules tie each record to the graph, while supersedes, refines, and conflicts_with edges preserve the decision lineage. - 03 / Surface
Bring the why to the change
get_why, file context, documentation, and PR risk reviews expose the relevant decision when a developer or agent needs to understand it.
Honest limitations
Archaeology is evidence, not certainty.
Many repositories never recorded their rationale cleanly. Repowise labels fuzzy and unverified extractions, and get_why may fall back to the most likely explanation from git history when no decision exists. Staleness reports drift in governed code; it does not prove that a decision is invalid.
Questions, answered
The details behind the claim.
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, comment archaeology, and agent transcripts. 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.
Last reviewed: September 2026
Keep the architectural record with the repository.
Index a repository and make its decisions, evidence, governed files, and history available to developers and agents from the same source.