Because, Since, and As for Cause

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

• distinguish a decision reason from a claimed technical cause;

• choose because, since, or as from what the reader already knows and what you want to emphasize;

• revise a causal sentence that is stronger or more ambiguous than the evidence.

Idea in one sentence: A causal connector draws an arrow between two claims, so choose one that shows both the relation and how certain that relation really is.

Core Insight

A team is releasing version 3.4 of a payment API through a canary. Ten percent of requests reach the new version.

Four minutes later, the error rate rises from 0.3% to 4.8%. The agreed rollback threshold is 2%, so the on-call engineer rolls back. Three minutes after the rollback, the error rate returns to 0.4%.

The team needs a short update. This version looks reasonable:

Errors increased because we deployed version 3.4, so we rolled back.

But it joins two different ideas as if both were equally certain:

• The error rate exceeded the threshold. That explains why the team decided to roll back.
• Version 3.4 caused the errors. That is a technical cause claim and still needs investigation.

The update has enough evidence for the first relation, but not yet for the second.

A safer update is:

We rolled back because the error rate exceeded the 2% threshold.
Errors began after the canary started, but the technical cause is still unconfirmed.

The grammar is doing real engineering work here. It tells the reader which arrow the evidence supports and which arrow remains a hypothesis.

Two Kinds of "Why"

When engineers use a causal connector, they often answer one of two questions.

Why did a person or system make this decision?

We rolled back because the error rate exceeded the threshold.

The threshold breach is the reason for the decision. The sentence does not claim that the threshold breach created the underlying bug.

Why did the technical event happen?

Requests failed because the serializer rejected empty region values.

This sentence claims a mechanism: empty values reached the serializer, the serializer rejected them, and requests failed. That claim needs supporting evidence such as logs, traces, a reproduction, or a code path.

The same word, because, can introduce either kind of reason. The reader discovers which kind from the two claims around it.

Plain meaning:

because, causal since, and causal as all tell the reader that one claim explains another claim.

In this scenario:

The threshold breach explains the rollback decision. It does not automatically explain the software failure.

Technical name:

These words introduce a reason clause. The clause gives a cause, justification, or background reason for the main clause.

The Claim-and-Reason Model

Treat a causal sentence as a small graph:

reason claim  ───────▶  main claim
error rate > 2%      ▶  team rolls back

The connector labels the arrow. It does not create the evidence behind the arrow.

Before writing the connector, inspect four pieces:

If you cannot fill in the evidence row, you may have a hypothesis rather than a cause.

The canary started before errors increased.

This proves an order in time.

Errors increased because the canary started.

This claims a causal relation. Time order alone does not prove that relation.

Choosing the Connector

The three connectors overlap, but they do not give the reason the same weight.

Use because when the reason is important or new

because is the clearest default in short technical communication. It points directly at the reason.

We rolled back because the error rate exceeded the threshold.

The reader is likely asking, "Why did you roll back?" The because clause answers that question.

You can also place the reason first:

Because the error rate exceeded the threshold, we rolled back.

This order makes the reason the context for the decision. Use a comma after the opening reason clause. When the reason comes after the main clause, a comma is usually unnecessary.

Use causal since when the reason is already accepted

Since everyone already accepts the rollback rule, the on-call engineer can act immediately.

Here the writer treats the accepted rule as shared context. The new information is the immediate action.

This can sound slightly less direct than because. It also has a dangerous neighbor: temporal since.

Since the rollback, the error rate has remained below 0.5%.

In this sentence, since means "from that time until now." It does not introduce a cause.

If a reader could reasonably read since as time, prefer because for the cause or rewrite the time relation explicitly.

Use causal as for a background reason only when the meaning is clear

As the runbook already requires a rollback, the on-call engineer can act immediately.

The reason behaves like background context. The action remains the focus.

But as can also describe time or manner:

As the canary expanded, errors increased.

This most naturally means "while the canary was expanding." It does not clearly say that expansion caused the errors.

In incident updates, pull request comments, and operational decisions, because is often safer when the causal relation matters. As is useful, but clarity matters more than variety.

A Worked Revision

The on-call engineer has this evidence:

10:00  canary starts at 10%
10:04  error rate reaches 4.8%
10:06  team rolls back because the agreed threshold is 2%
10:09  error rate returns to 0.4%
10:12  logs show serializer failures; root cause is not yet confirmed

Now revise the update one step at a time.

Draft 1: disconnected facts

The error rate reached 4.8%. We rolled back. The service recovered.

The facts may be correct, but the reader must reconstruct the reason for the rollback.

Draft 2: one supported reason

We rolled back because the error rate exceeded the 2% threshold. The service recovered three minutes later.

Now the decision path is visible:

observed signal -> agreed boundary -> rollback decision

Draft 3: an unsupported technical cause

The error rate increased because version 3.4 contains a serializer bug.

The logs make this plausible, but the team has not yet reproduced or traced the failure. The sentence turns a hypothesis into a conclusion.

Draft 4: evidence and uncertainty separated

We rolled back because the error rate exceeded the 2% threshold. Errors began after the canary started, and serializer failures appear in the logs. The technical cause is still unconfirmed.

This version is longer because it carries more jobs, not because longer English is automatically better. It shows the decision reason, the timeline, the current evidence, and the remaining uncertainty.

So far, we have seen that a connector should expose a supported relation. Because makes the reason explicit. Since and as can move an accepted reason into the background, but both can be confused with time.

Common Confusions

Confusion: because proves the cause

Why it is tempting:

The sentence sounds complete, so the relation can feel proven.

Better model:

Because states the writer's causal or justificatory claim. Logs, traces, tests, and reproduced behavior provide the evidence.

Confusion: since always means cause

Why it is tempting:

Many grammar examples use since as a softer synonym for because.

Better model:

Since can mark either cause or time. Inspect what follows it and ask whether the sentence means "because" or "from that time."

Confusion: changing the connector fixes weak reasoning

Why it is tempting:

As or since may make a claim sound more careful.

Better model:

A softer connector does not repair missing evidence. Change the claim: describe the observed sequence, label the cause as unconfirmed, or state only the decision reason.

Check Your Understanding

Check: The canary started at 10:00, and latency rose at 10:04. No trace identifies the mechanism yet. Which sentence is supported?

1. Latency rose because the canary changed the cache key.
2. Latency rose after the canary started, but the cause is still unconfirmed.

Think first, then reveal.

Answer: Sentence 2. The evidence gives an order in time, not yet a technical cause. Sentence 1 names a mechanism that has not been observed.

Check: The rollback threshold and the current error rate are already visible in the incident channel. You want to emphasize the immediate action. Which sentence fits?

1. Since the runbook already requires a rollback above 2%, the on-call engineer acted immediately.
2. The runbook requires a rollback since the on-call engineer acted immediately.

Think first, then reveal.

Answer: Sentence 1. The accepted rule comes first as context, and the main claim carries the new action. Sentence 2 incorrectly makes the engineer's action sound like the reason the runbook contains its rule.

Practice: Separate Evidence From Cause

A queue worker deployment starts at 14:00. At 14:03, retry volume doubles. The runbook says to pause a deployment when retries exceed 1,000 per minute. The team pauses at 14:05. A retry-policy change is a possible cause, but nobody has traced it yet.

Write two sentences:

1. Explain why the team paused the deployment.
2. Describe the possible technical cause without presenting it as confirmed.

A strong answer should:

• use a causal connector only for the supported decision reason;
• keep time order separate from technical causation;
• label the retry-policy explanation as a possibility or an open investigation.

One model answer is:

We paused the deployment because retries exceeded 1,000 per minute. Retries increased after the new policy reached the canary, but we are still checking whether that policy caused the increase.

Daily Practice Lines

• We rolled back because errors exceeded the threshold.
• Since the cause is unconfirmed, we are collecting traces.
• As the runbook requires a rollback, the on-call engineer acted.

Connections

The earlier preposition track taught temporal relations such as after the deploy and since the rollback. This lesson adds complete reason clauses. The next lesson turns the same arrow around: instead of giving the cause with because, it will state the consequence with so, therefore, and as a result.

Trade-offs and Limits

Clear causal language makes a decision easier to audit and reduces the chance that a hypothesis becomes team folklore.

It costs a few extra words when evidence, correlation, and uncertainty must be separated. That cost is useful in incident channels, rollout notes, and design discussions where later readers may treat one sentence as a durable conclusion.

The trade-off is between brevity and evidence visibility. One causal sentence is quick to read, but it can compress an observation, a hypothesis, and a decision into one arrow. Two or three short sentences cost more space, yet preserve which facts are observed and which explanation is still being tested. The boundary becomes visible when teammates start asking, "Do we know that caused it, or did it only happen first?"

This lesson does not prove root cause, choose the correct tense, or teach a full incident-analysis method. The boundary is visible when you can write a grammatical causal sentence but cannot name the evidence for its arrow. At that point, weaken the claim or gather more evidence.

Resources

• [ARTICLE] Cambridge Dictionary Grammar - Focus on conjunctions and clauses of reason, especially how position changes emphasis.
• [ARTICLE] Microsoft Writing Style Guide - Focus on concise sentences, explicit actors, and wording that does not make the reader infer the main relation.

Key Takeaways

• A reason for a decision is not automatically the technical cause of a failure.
• Because is the clearest default when the reason is important or new.
• Causal since and as usually treat the reason as shared or background information, but both can be confused with time.
• A connector states a relation; evidence must support that relation.
• When causation is uncertain, describe the observed sequence and label the cause as unconfirmed.