Building with context For engineers
When should you reopen a rejected approach?
Keep a rejected option with its original reason, scope and evidence. When the task changes, check whether that reason still applies. A changed condition can justify investigating again without accepting the option, changing another caller’s contract or proving that a replacement works.
Recover the condition behind the rejection.
“We tried that before” leaves several questions unanswered. Was the approach tested and found wanting, excluded by a requirement, deferred for lack of time, or merely discussed? Each account changes what the next engineer should do. Recover the original reason before treating the sentence as a design constraint.
A rejection is useful work context when its condition survives with it: the caller that needed a response, the workload used in a test, the resource limit at the time, or the unresolved dependency. Without that condition, a scoped choice can turn into an unexplained permanent ban.
AWS’s architectural decision record process distinguishes proposed, accepted, rejected and superseded decisions. The method here adds a reconsideration question: which part of the recorded reason still applies to this task? It is a proposed way to use decision history, not an AWS requirement or an implemented Shifu policy.
Read the original reason precisely.
Locate the permitted decision or review record and identify the alternative, reason, status, scope and supporting evidence. If you find only a later summary, keep that limitation visible. An absent reason is something to inspect or ask about; it is not permission to invent a plausible explanation.
Use the distinctions below only when the source supports them. One discussion can contain several reasons. Preserve every consequential condition rather than choosing the easiest one to dismiss.
| What the source records | What it establishes | What to compare now |
|---|---|---|
| A measured failure on a named workload. | The observed result for that version and workload. | Whether the workload, implementation or requirement changed, and what new check is needed. |
| An accepted requirement excludes the option. | The option did not fit that requirement’s scope. | Whether the same accepted requirement still governs this caller. |
| Investigation deferred because time was unavailable. | The team deferred the work. | Whether investigation is now useful and within the current task’s scope. |
| An alternative was listed but never evaluated. | The option was considered, with no evaluated result supplied. | What evidence would assess it; do not describe it as a failed test. |
Work through a fictional report decision.
This entire case is fictional: the callers, requirements, decisions and statuses are invented. No engineering change, experiment or customer outcome is being reported.
An existing caller requires a completed report in the same operation. Decision R4 rejected a proposed background-generation design that would return a job reference before the report was ready. The recorded reason was that this response would not meet the caller’s accepted contract. The record supplies no performance comparison and does not claim that background generation is unsuitable everywhere.
A later accepted requirement, R9, permits a job reference and later result retrieval for a new caller only. The existing caller’s contract remains unchanged. This is an accepted scope change in the fictional inputs; if all you had were a progress-screen mockup, you would have evidence of a proposal instead.
For the new caller, the original immediate-result condition no longer excludes investigating background generation. That conclusion is narrow. R9 does not accept a particular worker design, establish how a failed job is reported, or prove that a caller can recover its result. Those remain design and verification work.
| Scope or evidence | Does R4’s reason still apply? | Supported disposition |
|---|---|---|
| Existing caller still requires the completed report in the same operation. | Yes, for the described design returning only a job reference. | Retain that rejection for this caller; preserve its contract. |
| New caller has accepted R9 allowing a job reference and later retrieval. | The immediate-result reason no longer excludes this option in that scope. | Reopen design investigation for the new caller; no replacement is selected yet. |
| Only a mockup proposes a progress screen. | A changed accepted contract has not been established. | Inspect the governing requirement; keep adoption unresolved. |
| No completion, failure or recovery checks are supplied. | This is new missing evidence, not proof of the old rejection. | Define and run scoped checks before claiming the proposed behavior works. |
Separate reconsideration from selection.
Investigating again asks whether an option deserves current evaluation. Accepting it chooses a design for a defined scope. Implementing it changes the system. Verifying it supplies observed evidence. Keep those states separate in the task record so a revived discussion cannot become a reported release.
For the fictional new caller, inspect the accepted job/result contract, compare suitable designs and identify the checks each needs. Completion, failure reporting, repeated requests and result recovery are questions to resolve against that contract. Do not invent their policies from the fact that a job reference is allowed.
Preserve R4 and its original reasoning. Record the new investigation with its own scope and links. If a successor is later accepted, explain what it changes and what remains applicable. A result from one new-caller check would not establish that the old caller can adopt the same behavior.
If the current authorized instruction already selects the approach and settles its scope, use that direction. History can reveal a consequence to preserve without forcing the owner to approve the same choice again. A question is useful when a material decision is actually unresolved.
Keep the reason and the reopening evidence together.
Use a short card that another engineer can challenge. Link the original source, identify the changed condition and name the strongest conclusion available. If the rejection depended on several constraints, show which changed and which still hold.
The card below describes investigation for the fictional new caller. It supplies no implementation, test execution or deployment result.
Reconsideration card — wholly fictional report generation
Current task: evaluate background generation for a new caller.
Original option: return a job reference before a report is complete.
Rejection/source: R4 rejected it for the existing caller’s immediate-result contract.
Evidence type: requirement-based exclusion; no measured performance failure supplied.
Original scope: existing caller; completed report required in the same operation.
Changed evidence: accepted R9 permits a job reference and later retrieval for the new caller only.
Unchanged scope: existing caller still requires its completed report.
Conclusion: reopen investigation for the new caller; retain R4 for the existing caller.
Still unresolved: particular design and completion, failure, repeat-request and recovery policies/checks.
Proceed: inspect current requirements and compare designs within the task’s authorization.
Owner: task engineer records evidence; contract owner resolves any unsettled policy.
Status: investigation only; no design acceptance, implementation or executed result.
Refresh when: accepted scope, source evidence, candidate design or actual check result changes.Use one rejection in the next plan.
Choose an alternative relevant to a current change. Recover why it was rejected, identify the condition that mattered and compare it with current scoped evidence. End with one disposition: the reason still holds, the reason needs inspection, or changed evidence justifies investigation. If adoption is already authorized, carry its applicable constraints into the implementation plan.
A team lead can review that disposition with the maintainer who owns the affected contract. The useful question is whether the historical reason changes today’s decision or next check. Counting recovered alternatives or reopening every old discussion does not establish value.
Repository decisions, review history and current requirements may be enough. A context engine can help locate the old reasoning, but a retrieved rejection cannot establish its present applicability. Keep the original reason available, then let current evidence determine what the next task should do.
Sources and further reading
Prepared with AI assistance and reviewed for source fidelity and practical usefulness. Examples marked fictional are illustrations, not customer results.