Skip to content
Technical Wiki · Architecture

Decision ownership

Identification of the function, component, contract, or invariant that actually owns a software decision rather than merely observing its result.

01

Owner versus symptom location

The file where incorrect behavior becomes visible may not own the decision that produced it. Callers, adapters, UI surfaces, tests, and downstream consumers can expose or compensate for behavior whose actual owner is elsewhere. Repairing the observer instead of the owner can distribute compensating logic and enlarge future correction cost.

02

Function-level graph support

Ajenda’s graph includes selected python_function nodes with decision-role metadata and relationships such as calls_function, tests_function, and defined_in. This allows diagnosis to move from a module or failing test toward the represented function that classifies, normalizes, segments, maps, or otherwise owns a decision.

03

Repair implication

Once ownership is established, the intended repair unit can be compared with the surrounding contracts and invariants. Correct ownership does not eliminate the need for blast-radius analysis: changing the owner can affect every caller, test, state transition, or downstream behavior that relies on that decision.

Evidence boundary

What this entry supports

Decision-role metadata exists for selected Ajenda graph functions. It is a targeted representation, not a claim that every behavioral decision in the codebase has function-level ownership metadata.

Related material