Upstream vs downstream: one river picture that explains oil, supply chains, software, and decisions

Upstream is where something comes from; downstream is where it goes. In any flow (water, oil, parts, code, data, work, the effects of a decision) upstream means earlier and closer to the source, and downstream means later and closer to the end. The labels are relative. They tell you where you stand, not who matters.

The rest of this page maps that one picture onto six fields, shows why the same team can be both, and tells what a real river taught Europe about who pays downstream.

What is the river picture?

Stand on a bridge and look at the water. Cambridge Dictionary defines upstream as “(moving) on a river or stream towards its origin” and downstream as “in the direction a river or stream is flowing”. Whatever enters the water above you reaches you. Whatever you drop in reaches everyone below you.

Business English borrowed both words. Cambridge gives upstream as “relating to an earlier stage in a process or series of events”, and downstream as “something that happens later in a process or series of events”. Merriam-Webster adds an industrial sense for downstream that includes “the stages (such as marketing) after manufacture”.

Two rules carry over from the river to every field below:

1. Things flow one way. Water, oil, parts, code, data and consequences move from upstream to downstream.
2. Position is relative. “X is downstream of Y” means X receives what Y sends. Cambridge’s example: “Higher concentrations of some chemicals were found in fish downstream of sewage-treatment plants.”

What do upstream and downstream mean in each field?

Field	Upstream	Downstream	Example
Oil and gas	Finding and producing crude oil and gas	Refining, product sales and marketing	A drilling platform is upstream; a refinery and a filling station are downstream
Supply chains	Your suppliers and their raw materials or parts	Your distribution, through to the end customer	Hypothetical bakery: the flour mill is upstream, the shops selling its bread are downstream
Software projects and forks	The original project where changes are made and released	The distributions, products and forks built on it	The Linux kernel is upstream of Fedora; Red Hat Enterprise Linux is downstream of Fedora
Data pipelines	The task that must finish first	The tasks that run after it and use its output	A nightly data import is upstream of the report that reads it
Teams and workflows	The team whose work you depend on	The teams that depend on yours	The team that owns the customer database is upstream of the team that builds invoices
Decisions	The choice, and the assumptions behind it	The later effects on partners, customers, staff and regulators	A pricing change is upstream of the partner margin it squeezes months later

Oil and gas. The US Energy Information Administration (EIA) puts it plainly: “Upstream refers to crude oil exploration, production, and other operations prior to refining. Downstream refers to refinery operations, product sales, and marketing.” EIA also names a middle segment, midstream: companies that transport and store crude oil and natural gas, typically with tanker ships, pipelines or storage facilities.

Supply chains. The Chartered Institute of Procurement & Supply (CIPS) describes a supply chain as looking upstream to your suppliers and their raw materials or components, and downstream from your own activities to delivery to the end consumer.

Software. In open source, Red Hat explains, an upstream is “the source repository and project where contributions happen and releases are made”, and “the contributions flow from upstream to downstream”. A bug fixed upstream can benefit every project built on it, which is why Red Hat describes working “upstream first”. On GitHub, if you copy a project to build your own version (a fork), the documentation has you add a link named upstream that points back to the original.

Data pipelines. In Apache Airflow, open-source software for scheduling workflows such as data pipelines, each step is a task, and the documentation says: “By default, a Task will run when all of its upstream (parent) tasks have succeeded.”

Teams. Eric Evans’s Domain-Driven Design Reference, a summary of definitions and patterns for software design, defines an upstream-downstream relationship between two groups in which the upstream group’s actions affect the downstream group’s success, but not the other way round. His example is the river itself: “If two cities are along the same river, the upstream city’s pollution primarily affects the downstream city.”

Decisions. This is the sense behind “downstream effects” on this site. The decision sits upstream. Its later costs land downstream, on partners, customers and regulators who were not in the meeting. What are downstream effects? gives the full definition.

Why can the same thing be upstream and downstream?

Because the words describe position, not rank. Red Hat’s own example: Red Hat Enterprise Linux (RHEL) is based on Fedora, and Fedora pulls from many original projects. In Red Hat’s words, “Fedora is downstream of these projects and RHEL is downstream of Fedora.” Fedora is downstream and upstream at the same time.

Your team works the same way. You are downstream of whoever supplies your inputs and upstream of whoever uses your output. When someone says “that is an upstream problem”, ask: upstream of whom?

Three confusions to avoid:

• Upstream is not “more important”. It is earlier. Power does often sit upstream, though: Evans warns that a downstream team “can be helpless, at the mercy of upstream priorities”.
• Direction follows the flow, not the org chart. An analyst who owns a data source is upstream of the chief executive’s dashboard.
• The fields stretch the words differently. In oil, downstream reaches all the way to selling fuel. In software, upstream is also a place: the project you send your fixes back to.

What happens when the upstream party does not look downstream?

On 1 November 1986, a fire broke out in a warehouse belonging to Sandoz near Basel, Switzerland. According to the International Commission for the Protection of the Rhine (ICPR), firefighting water mixed with up to thirty tons of pesticides flowed into the Rhine and killed fish and other organisms along hundreds of kilometers of the river. The Swiss water research institute Eawag recalls that the firefighting water was red, and that images of dead fish went around the world.

The cost landed downstream. The ICPR writes that it was the first time citizens “from Switzerland downstream to the Netherlands” showed solidarity with the river. Ministers from the Rhine states then adopted the Rhine Action Programme, coordinated by the ICPR, with two aims: halve the discharges of 40 dangerous chemicals within 10 years, and make the Rhine clean enough for salmon to return.

Two honest footnotes from Eawag: the river’s life recovered relatively quickly, within a few months, and the accident led to major progress in water-quality monitoring, legal rules and risk reduction in the chemical industry. It is Evans’s river example in real life: the upstream party acts, the downstream parties pay, and the lasting fix put downstream needs into upstream rules.

How do you use the river picture for your own decisions?

DOWNSTREAM is an operating protocol for delayed consequences: ten moves for naming who pays later, and where, before you commit. It comes from The Downstream Effects, a book by Len van der Hof that is in production and not for sale yet. It is an operating heuristic, not a validated risk instrument, and you do not need the book to use it. The DOWNSTREAM framework page has the same moves.

1. Detect. Before you commit, list who and what sits downstream of the decision.
2. Observe. After launch, watch what actually happens in the places the decision touches.
3. Weigh. Compare the real later costs with the first win, not with a wish.
4. Navigate. Choose a path that still works when the later effect arrives: accept, reduce or avoid each branch.
5. Stream effects. Look at each effect over several time horizons, so the cost is not dumped on one later quarter.
6. Trace. Keep the chain from decision to effect written down, so a surprise many months later can still be linked to its cause.
7. Review. Reopen the map after the decision ships, on a fixed rhythm, and compare it with what really happened.
8. Effects on stakeholders. Name who actually pays: a partner, a regulator, a network, a user.
9. Assess systemic risk. Find the point where local damage stops being local and spreads.
10. Mitigate. Install the smallest control that changes where the cost lands, with an owner and a test.

A worked example, hypothetical. An online shop wants to rename a product field in its catalog export, because the old name confuses new staff. The product team that owns the export is upstream. Everyone who reads the export is downstream.

• Detect. List every reader of the export: the marketplace feed that lists the products, finance’s margin report, and the customer-service templates that quote product details.
• Effects on stakeholders. Listings could drop off the marketplace until someone remaps the field. Finance’s report could quietly show blanks. Support could send customers wrong details. None of those people sit in the product team’s meeting.
• Mitigate. Keep the old field name alive next to the new one for one release, name an owner who checks each reader, and add a test that fails if a reader still breaks.

The decision survives, reshaped rather than killed. For the longer method, including a twenty-minute audit of recent decisions, read Downstream effects: why the real cost of a decision lands later, and somewhere else. The book page is The Downstream Effects.

Try this today (ten minutes)

Draw your own river.

1. Write your team, or your own job, in the middle of a page.
2. On the left, write two things you depend on: people, systems or suppliers. That is your upstream.
3. On the right, write three people or teams who use what you produce. That is your downstream.
4. Pick one downstream name and ask them one question this week: “If I changed [the thing I produce] next week, what would break for you?”
5. Write the answer next to their name.

That one line is the start of a detection checklist, and it costs you one conversation.

Cite this:Upstream vs downstream: one river picture that explains oil, supply chains, software, and decisions.Len P. van der Hof. https://lenvanderhof.com/en/blog/upstream-vs-downstream/ · Published 13 October 2026.