For teams

Preparing a software change

The requirement stayed. Did the behavior?

Your customer wants single sign-on for an existing portal. The old sign-in path must remain available for existing customers. Before you estimate, then review the change, you need to know whether the implementation preserves that exception.

Illustrative user story. Not a client case study or a measured result.

People discussing notes and designs at a shared table.
Illustrative photograph of collaboration. Headway / Unsplash

Preparing a software change

The code shows what happens. Why is another question.

The developer finds the old path. A design note describes a customer constraint, but it is unclear whether the note still applies. The technical lead needs that answer before agreeing the scope and estimate.

The work is not simply to find a document. It is to connect the relevant decision to its source and version, then check it against the proposed change. Anything not covered by the sources still needs investigation.

AKDB: a search for Anmeldung (sign-in) finds a documented decision for a fictitious customer portal.
Original interface with fictitious example data. Historical Product Host 0.6.0-alpha.1 search, not a view of later inspection features. Engineering preview, not a client result. Search retrieves a manually documented decision; this does not demonstrate autonomous impact analysis. View at full size ↗

Preparing a software change

Compare the requirement with the inspected behavior.

For this example, a proposed evaluation would use an agreed repository snapshot and selected documents. Your team would define the questions: why was the exception introduced, what supports it today, and who can resolve the remaining uncertainty?

AKDB’s implemented comparison examines reviewed mappings between intended and inspected behavior, including conditions, computed values and effects. A mismatch can be distinguished from an unknown result when coverage or mapping is incomplete. A reviewer checks the comparison. There is no production write access and no promise of a complete impact map.

Preparing a software change

Judge it by the work needed to prepare the change.

Compare the preparation and review effort with your current process. Count unanswered questions, incorrect answers and the cost of setting up and maintaining the project knowledge—not just how quickly a search returns.

Before starting, agree when the case should stop: for example, if the necessary sources are unavailable or the product cannot support the questions. A positive result would support a separately scoped next step.

The goal is to find the difference that matters before it becomes avoidable rework.

Start with your next estimate.

Bring the change request and the questions behind it. We can discuss permitted sources, technical suitability and what would count as a useful result.

Discuss a change estimate