Decision trails

Which decision replaced which?

Teams write decisions down, then write new ones. Years later the question is which one still holds. Muninark follows what replaced what and links each decision to its source.

  1. Earlier decisionstatus and source link
  2. Replaced bythe link Muninark follows
  3. Later decisionstatus and source link
The problem

The old decision is still in the repository.

Both records are still in the repository, and nothing in a plain search says which one holds. A new engineer, or an AI assistant, can pick the wrong one.

  1. An exampleA record from 2023 chooses one approach.
  2. LaterA newer record chooses another and says it replaces the first. The code follows the newer one.
  3. TodayA search for the topic can return the 2023 record, with nothing to mark it as replaced.
What a trail shows

The chain, with its status and its sources.

Ask about a decision and Muninark returns it together with the decision that replaced it.

  • The chain · The recorded decisions connected by replacement links, from an earlier decision to the one that replaced it.
  • The status as recorded · Proposed, accepted, superseded: whatever the document says, shown beside the decision. Nothing is smoothed over.
  • A link to the source · Every decision points to the document it was read from, so you can open it and check.
  • Whether an expert has confirmed it · Each decision carries its approval state. Until an expert approves it, it is marked as pending.
  • What is missing · When no chain exists, the answer says so and does not guess.
A real example

Two decisions in a public repository.

From a run on microsoft/semantic-kernel, a public repository under the MIT licence. Muninark is not affiliated with Microsoft.

Which decision replaced ADR-0006 on dynamic payloads for OpenAPI functions?

get_decision_trail · decision_id microsoft/semantic-kernel:0006-open-api-dynamic-payload-and-namespaces

Found 1 decision trail(s) covering 2 decision(s) (deepest chain: 1 hop(s)): microsoft/semantic-kernel:0006-open-api-dynamic-payload-and-namespaces, microsoft/semantic-kernel:0062-open-api-payload.

SUPERSEDED

ADR-0006

Dynamic payload building for PUT and POST RestAPI operations and parameter namespacing. Dated 2023-08-15.

Open on GitHub
replaced by
PROPOSED

ADR-0062

Providing Payload for OpenAPI Functions. Dated 2024-10-25.

Open on GitHub

Captured on 19 October 2026 and shown as returned. The titles, statuses and dates under the answer are the ones the response carries, and each link opens the file at the commit it was read from. ADR-0006 says ADR-0062 superseded it, while ADR-0062 still carries the status proposed in its own file, and the trail reports both as written. In this run neither decision was approved by an expert.

Where decisions come from

Written down, or found.

Both kinds can appear in an answer.

Decisions your team writes down

Architecture decision records and similar documents. A reader built for your format picks up each decision with its title, date and status, and notes which earlier decision it replaces. Muninark ships no reader for your format; the deployment supplies one.

Decisions found by the engine

A model can also pick out decisions described in other records. These are findings that wait for an expert to confirm them, because a model can be wrong.

When approval matters

Ask for confirmed decisions only.

For the decision types a deployment designates, a query can be limited to decisions an expert has approved. Where a pending decision breaks the chain, the approved decision is returned alone, with a note. A pending decision that you name yourself can also come back alone, with a note that it is not approved.

How knowledge stays current
  • A decision an expert rejects is withdrawn from answers.
  • Written decisions start as pending too, until an expert approves them.
Limits

What a trail does not tell you.

  • The trail follows replacement only. It does not connect a decision to the tickets that prompted it or the commits that carried it out; those stay separate evidence you can search for.
  • It does not say who decided. It reports what the document records.
  • It answers from what was written down. A decision made in a meeting or in someone’s head, with no record, is not there.
  • Titles and statuses are only as good as the reader for your format. A document whose title line is template text will show that text.
  • A single decision that never replaced or was replaced by another has no trail, and the answer says only that none was found.

Where are your decisions written down?

Tell us where your team records decisions, such as ADRs, wiki pages or tickets, and which replacement links you need to trace.

Discuss your use case