Plan a change when sources disagree

Write the disagreement before choosing a side.

A ticket asks for a new export field. An accepted design excludes it. The exporter also leaves it out. Asking a coding agent to “use the latest requirements” skips the question that matters: has the team actually changed the export contract, or is the ticket asking for a decision?

Start with a sentence containing both accounts. For example: “The new mockup includes recipient email; the accepted export decision excludes it.” Keep the requested future behavior separate from the behavior already observed. A disagreement can reflect a proposed change, a partial rollout, an implementation defect, or two documents covering different scopes.

The method here is a proposed planning worksheet. It does not establish a universal hierarchy in which code, a ticket, or an older decision always wins. The governing requirement depends on the actual scope and authority behind the sources.

Work through a fictional export change.

This entire example is fictional, including the source labels and statuses. A team is adding a column selector to its scheduled invoice CSV. Accepted decision E12 permits invoice identifiers and totals but excludes recipient email. A newer ticket includes a mockup with an email checkbox. Its discussion calls that field a proposal; no acceptance of the changed data boundary is recorded.

The current exporter uses a fixed list of columns without email. One inspected export sample also lacks the field. Those checks agree with E12 in their inspected scope. They do not prove why every deployed exporter behaves that way, or establish whether the team now wants a different policy.

The engineer has permission to investigate the feature, not to decide a new data boundary on the team’s behalf. The export maintainer owns the implementation evidence; the product and data owners must resolve the proposed boundary change. If a current authorized instruction has already settled it, record that decision and scope rather than asking for the same approval again.

Check status, scope and authority separately.

For each important statement, record where it came from, its date or revision, its status, and the service, caller or data scope it covers. Then ask who can make the decision and what evidence shows it was made. A recent edit may be a proposal. A long-standing accepted decision may remain applicable. Repeated summaries may all derive from the same original source.

AWS’s ADR process preserves accepted decisions and uses an accepted successor to supersede an earlier record. That lifecycle helps distinguish a new idea from an adopted change. This worksheet also asks about observed behavior; an ADR’s acceptance does not by itself prove rollout.

If the sources concern different scopes, narrow the apparent conflict. A manual internal report and a scheduled customer export may have different contracts. Do not use an exception from one to broaden the other. If the scopes really overlap and authority is unclear, preserve that uncertainty in the plan.

Divide the work into actions that can proceed and actions that must wait.

In the fictional case, investigation can continue: trace the scheduled export path, inspect the accepted decision and its review, look for a successor, and list the tests that would protect the existing column boundary. Use permitted samples or fixtures. Do not collect extra production data merely to fill the worksheet.

Hold the email-field implementation and any rollout that changes the export boundary. Ask one focused question: “Does E12 still govern scheduled CSV exports, or has including recipient email been accepted for this feature? Please identify the scope and decision.” The answer may preserve the old policy, adopt a new one through the team’s process, or require further review.

A test plan can be drafted before that answer. It must leave the new field’s expected behavior unresolved. Writing a test that expects email in the output would silently choose the very policy the team has not settled.

Give the agent a bounded plan.

The plan should state what the agent may investigate or change, what it must preserve, and which conclusion remains unavailable. Link the actual sources instead of pasting several contradictory summaries and hoping the model resolves them.

Here is the filled planning card for the fictional case. Its checks are proposed, not executed results.

Goal: plan a column selector for scheduled invoice CSV exports.
Accepted baseline: E12 excludes recipient email in this export scope.
Observed behavior: inspected exporter and one sample omit email.
Conflict: new ticket proposes an email checkbox; adoption is unverified.
Proceed: inspect paths, successor decisions and existing fixture coverage.
Preserve: existing export boundary while the question is unresolved.
Hold: implementing or rolling out the email field.
Question: has the responsible owner accepted that boundary change, for which scope?
Checks after resolution: permitted columns; excluded columns; selector behavior; relevant access paths.
Result status: no implementation, test execution or deployment established by this plan.
Refresh trigger: owner decision, changed scope, new source or implementation evidence.

Close the conflict without rewriting its history.

Once the responsible owner resolves the question, record the answer, scope and source. If the decision changes, retain the earlier rationale and link the successor. Then update the implementation plan and expected checks. A passing local test still establishes only its tested scenario; rollout needs its own evidence.

For a team, try this on one consequential disagreement with the service maintainer. Observe whether the worksheet identifies the actual owner, exposes an assumption, and gives the engineer a useful next action. Include the effort to maintain the record. Stop or narrow it when it merely duplicates a clear ticket without changing the plan.

Ordinary repository search, review history and a focused owner question can be enough. Retrieval can help find scattered reasoning, but cannot accept a proposed policy. Before your next edit, write one disagreement explicitly and separate what can proceed from the decision that must be resolved.