Review: Connect Evidence to a Technical Decision

By the end of this lesson, you will be able to...

• separate observed evidence from an inference, a recommendation, and a guarantee;

• review whether a short technical recommendation preserves contrast, cost, condition, and fallback;

• revise a decision note so its next action is proportional to the evidence and its owner can verify the boundary.

Idea in one sentence: A connector can make reasoning visible, but only evidence and explicit limits can make the reasoning trustworthy.

Core Insight

The track has taught the language needed to connect an engineering decision:

evidence ── because/so ──> reason or consequence
competing fact ── but/although ──> preserved risk
condition ── if/unless ──> permission or block
sequence ── first/then/after ──> ordered action
fallback ── otherwise/instead/in case ──> alternative path
operational action ── roll out/roll back/look into/follow up ──> owned change

The difficult question is not “Which connector do I remember?” It is:

Does the recommendation actually follow from what the team knows?

Consider this note:

Replay tests reduced backend reads by 22%, so we can roll the new cache key out to everyone. The change is safe because the canary is green. We will figure out any old-client problems later.

The connectors are grammatical, but the reasoning is too strong. Replay tests are not full production evidence. “Green” is incomplete without metrics and duration. “Figure out later” hides an owner and a boundary. A good review repairs the inference, not just the punctuation.

The Small Situation

The team is deciding whether to expand a new cache key. The available evidence is:

replay tests: backend reads down 22%
canary duration: 20 minutes
canary error rate: 0.2%
canary p95: 230 ms
old-client compatibility check: incomplete
rollback configuration: ready
cost: dual-read path adds storage and monitoring work

There are two candidate recommendations:

A. Roll the cache key out to 100% now.
B. Keep the canary at 10%, complete the compatibility check, then phase the key in by client group.

The recommendation should not be selected by optimism alone. Build an evidence matrix first.

The matrix keeps evidence, inference, and missing knowledge separate.

The Naive Recommendation

Here is the overconfident version:

The replay tests reduced reads by 22%, so the new cache key is safe. Therefore, we will roll it out to 100% today. The canary is green, although the old-client check is incomplete. If anything goes wrong, we can roll it back.

Find the reasoning problems:

• so moves from a replay result to a production guarantee;
• therefore recommends 100% without using the limited canary evidence;
• although mentions the compatibility risk but does not let it change the decision;
• “green” lacks the error rate, p95, duration, and owner;
• “anything” is not an observable rollback trigger;
• can roll it back does not say who acts or what happens to old-client data.

The note is not fixed by deleting every connector. It is fixed by making each relation proportional to the evidence.

A Better Reasoning Path

Step 1: State the supported benefit

Replay tests reduced backend reads by 22%, so we will continue testing the new cache key.

The consequence is deliberately smaller than a full rollout. The evidence supports more testing, not yet universal safety.

Step 2: State the current canary evidence

The 10% canary has stayed at 0.2% errors and 230 ms p95 for 20 minutes.

This is an observation. Do not call it “safe” without defining what safe means.

Step 3: Preserve the missing compatibility check

Although the canary metrics are within budget, the old-client check is incomplete.

The contrast keeps the positive signal from erasing the unresolved risk.

Step 4: State the condition and the next action

We will not widen the canary unless the compatibility check is complete. Once it passes, we can phase the key in by client group.

The condition controls permission. Once marks the completed prerequisite. Neither sentence guarantees that the next stage will succeed.

Step 5: Name the fallback and its trigger

If p95 exceeds 250 ms, errors reach 0.5%, or stale results appear, we will pause and serve reads from the old key instead. If the problem persists, we will roll the release back.

The fallback has signals and two levels of response. “Something goes wrong” has been replaced by evidence another engineer can observe.

Step 6: Name the cost and owner

The staged path adds dual-read storage and monitoring work, but it limits the blast radius while we validate old clients. Luis will monitor the canary, and Priya will follow up with the API team after the compatibility check.

The recommendation now includes a trade-off instead of pretending that the safer path is free.

The Revised Decision Note

Replay tests reduced backend reads by 22%, so we will continue testing the new cache key. The 10% canary has stayed at 0.2% errors and 230 ms p95 for 20 minutes. Although those metrics are within budget, the old-client compatibility check is incomplete. We will not widen the canary unless the check is complete; once it passes, we can phase the key in by client group. If p95 exceeds 250 ms, errors reach 0.5%, or stale results appear, we will pause and serve reads from the old key instead. If the problem persists, we will roll the release back. The staged path adds dual-read storage and monitoring work, but it limits the blast radius. Luis will monitor the canary, and Priya will follow up with the API team after the compatibility check.

This is not the only valid answer. It is strong because every connector points to a relation supported by the matrix. The next action is limited, the unresolved risk changes the permission, the fallback is observable, and ownership is explicit.

Retrieval: Inspect the Inference

Use a four-part test for every recommendation:

What do we know?
What does that evidence support?
What remains uncertain?
What action and boundary follow?

Apply it to this sentence:

The canary is green, so we will roll the feature out to everyone.

“Green” may support continuing the canary, but it does not identify the metrics, duration, client coverage, or fallback. Repair the scope:

The canary has stayed within the error and latency budgets for 20 minutes, so we will continue at 10% while the compatibility check runs.

The recommendation now matches the known state.

Common Confusions

Confusion: a causal connector validates the conclusion

Why it is tempting:

So and therefore make a sentence sound logical.

Better model:

They expose the direction of reasoning; they do not make weak evidence strong:

Replay tests were positive, so we will test the canary further.

Confusion: contrast is only a style choice

Why it is tempting:

Although and but can sound like transitions.

Better model:

They preserve a fact that should constrain the decision:

Although latency is within budget, client compatibility is incomplete.

Confusion: a condition is a prediction

Why it is tempting:

We can widen if the check passes sounds optimistic.

Better model:

It states permission under a condition, not a forecast that the check will pass.

Confusion: a fallback removes the cost of caution

Why it is tempting:

Rollback makes a staged plan feel reversible.

Better model:

Staging and rollback reduce blast radius but add storage, monitoring, and coordination cost. State the trade-off.

Check Your Understanding

Check: Which recommendation is proportional to the evidence?

1. Replay tests reduced reads by 22%, so we will roll the key out to everyone.
2. Replay tests reduced reads by 22%, so we will continue testing the key in a 10% canary.

Think first, then reveal.

Answer: Sentence 2. The replay result supports more controlled testing, not a full production guarantee.

Check: Which sentence lets an unresolved risk change the decision?

1. Although the compatibility check is incomplete, we will widen now.
2. We will not widen unless the compatibility check is complete.

Think first, then reveal.

Answer: Sentence 2. It turns the missing check into an explicit permission boundary.

Check: Which fallback has an observable trigger?

1. If anything goes wrong, we will use the old path.
2. If p95 exceeds 250 ms or stale results appear, we will serve reads from the old key instead.

Think first, then reveal.

Answer: Sentence 2. It names measurable or inspectable signals and the replacement action.

Transfer Challenge: Review a Recommendation

Review this note:

The new cache key lowers reads in replay tests, therefore it is safe. We will phase it in everywhere tomorrow because the canary is green. Although old clients are not checked, we can roll back if needed. Luis will look into any issue.

Rewrite it in six or seven sentences. Keep these facts:

• replay tests show a 22% reduction in backend reads;
• the canary is at 10% with 0.2% errors and 230 ms p95 for 20 minutes;
• old-client compatibility is incomplete;
• the staged path costs dual-read storage and monitoring;
• p95 above 250 ms, errors at 0.5%, or stale results trigger a pause;
• Luis monitors the canary and Priya owns the compatibility follow-up.

Your revision should:

• downgrade unsupported certainty;
• preserve the positive result and the compatibility risk;
• make widening conditional;
• name the fallback and its trigger;
• state the cost and assign follow-up ownership.

One model answer:

Replay tests reduced backend reads by 22%, so we will continue the 10% canary rather than widen immediately. The canary has stayed at 0.2% errors and 230 ms p95 for 20 minutes. Although those metrics are within budget, old-client compatibility is incomplete. We will not phase the key in by client group unless the compatibility check passes. If p95 exceeds 250 ms, errors reach 0.5%, or stale results appear, Luis will pause the rollout and serve reads from the old key instead. The staged path costs dual-read storage and monitoring, but it limits the blast radius. Priya will follow up with the API team after the compatibility check.

The exact wording may differ. Check whether the decision remains bounded and whether another engineer can identify the next signal and owner.

Daily Practice Lines

• Replay evidence supports a canary, but it does not prove full production safety.
• We will not widen unless the compatibility check is complete; otherwise, we will keep the old path.
• Priya will follow up with the API team after the next verification.

The second line combines a condition and fallback; the third reuses the investigation ownership pattern from lesson 012. Replace compatibility check with load test or migration check, but keep the reasoning boundary visible.

What Comes Next

This review is the final reasoning check before the capstone. The capstone will ask for an independent operational decision update. It will not reward the largest number of connectors; it will reward a valid relation between evidence, action, condition, fallback, and owner.

Trade-offs and Limits

The trade-off is between recommendation strength and evidence coverage. A strong recommendation can move work quickly, but if it outruns the data it turns an inference into a hidden promise. A staged recommendation costs time and coordination, yet it creates more observation points and limits the blast radius.

Connectors can expose a weak argument but cannot repair missing monitoring or incomplete experiments. Therefore cannot create causation, although cannot remove a risk, and unless cannot make a prerequisite true. The boundary signal is a reader asking, “What would change this recommendation?” State the metric, check, or event that would change it.

Finally, a fallback is part of the decision, not evidence that the decision is safe. Rollback, an old path, or a pause may have its own costs and limits. Name those limits briefly so the recommendation remains useful without pretending to be a guarantee.

Resources

• [ARTICLE] Cambridge Dictionary Grammar - Review causal, contrast, conditional, and result connectors while checking the direction of each inference.
• [ARTICLE] Microsoft Writing Style Guide - Review evidence-bounded recommendations, explicit actors, measurable conditions, and concise decision notes.

Key Takeaways

• Separate evidence, inference, recommendation, and guarantee before editing the prose.
• Let contrast preserve unresolved risk and let conditions control permission.
• State the cost of caution and the observable trigger for the fallback.
• Use phrasal verbs to name the action, but keep object, owner, signal, and scope explicit.
• A trustworthy technical decision note says what would change the recommendation.