---
mpf: '0.7'
title: The sequence — ESFI Docs
url: https://docs.esfi.eu/our-approach/the-sequence/
mpf-url: https://docs.esfi.eu/our-approach/the-sequence/index.mpf
organization: European Strategy & Future Infrastructure
domain: docs.esfi.eu
lang: en
updated: '2026-11-03'
author: ESFI
provenance: human
source-hash: 6b935ffe5868b981d363042cec6426d4cdc9b478ae8c254571edf756c3fc661f
toc:
  - level: 1
    text: The sequence
    id: the-sequence
  - level: 2
    text: 'Intelligence: understanding the structure'
    id: intelligence-understanding-the-structure
  - level: 2
    text: 'Architecture: designing for real constraints'
    id: architecture-designing-for-real-constraints
  - level: 2
    text: 'Operations: building until it runs without us'
    id: operations-building-until-it-runs-without-us
  - level: 2
    text: Gates between the phases
    id: gates-between-the-phases
  - level: 2
    text: Why partners are in every phase
    id: why-partners-are-in-every-phase
  - level: 2
    text: On this page
    id: on-this-page
spec-origin: esfi.eu
content-origin: docs.esfi.eu
content-id: esfi:page:our-approach-the-sequence
content-parity:
  html: true
  human-visible-source: true
  hidden-sections: false
summary: Understand. Design. Build. In that order, every time.
index: true
confidence: probable
content-type: narrative
companion-footer: ESFI — civilization infrastructure · https://esfi.eu
companion-contact: mailto:hermes@esfi.eu
preferred-representation: mpf
companion-scope:
  cite: true
  summarize: true
  train: true
  index: true
  relay: true
language-variants:
  en: https://docs.esfi.eu/our-approach/the-sequence/index.mpf
  fr: https://docs.esfi.eu/fr/our-approach/the-sequence/index.mpf
  nl: https://docs.esfi.eu/nl/our-approach/the-sequence/index.mpf
  de: https://docs.esfi.eu/de/our-approach/the-sequence/index.mpf
  hr: https://docs.esfi.eu/hr/our-approach/the-sequence/index.mpf
mpf-id: 9e10defe4b1b9ffb2c3a3549bf69d1331da247a1540ad89e525b623736c40f83
---

Language

✕

/our-approach/the-sequence/index.mpf[open file ↗](/our-approach/the-sequence/index.mpf)[spec ↗](/standards/mpf/0.7)✕

loading…

# The sequence {#the-sequence}

**Understand. Design. Build. In that order, every time.**

Every ESFI initiative moves through three disciplines in sequence: **Intelligence, Architecture, Operations.** This is not an organisation chart. It is a way of making sure that what gets built is the right thing, that it works under real conditions, and that it continues to work after the people who built it have gone.

The order matters. Architecture without Intelligence produces well-designed solutions to the wrong problem. Intelligence without Architecture produces reports. Operations without either produces pilots that end when their funding does.

The sequence is the product.

## Intelligence: understanding the structure {#intelligence-understanding-the-structure}

Intelligence, for us, is not information gathering. It is structural understanding: seeing why a system behaves the way it does, where it is becoming fragile, and where the gap between what was intended and what actually happens is widening.

In an engagement, this is where we map the function, its dependencies and the people and institutions it relies on. It is also where we test the diagnosis from [Where the work begins](/our-approach/where-the-work-begins) against evidence rather than assumption.

**What it produces:** a shared understanding of the gap, written down in terms both sides accept, with the evidence it rests on and the unknowns that remain.

**When it is done:** when the partner and ESFI agree on what the problem is, why it persists, and what would show that it has been solved. If that agreement cannot be reached, the work does not move on. Designing for a disputed problem is the most expensive mistake available.

## Architecture: designing for real constraints {#architecture-designing-for-real-constraints}

Architecture turns understanding into an operational design: the model, the standards, the institutional arrangements and the technical systems that would close the gap.

The emphasis is on _operational_. A design that works in a workshop and fails in a procurement process, a legal review or a budget cycle is not a design. We build for actual partners, actual legal boundaries and actual institutional constraints, including the ones nobody likes to mention.

**What it produces:** a design that the people who will operate it have helped shape, with its assumptions visible, its dependencies mapped and its failure conditions named.

**When it is done:** when the design has been tested against the constraints it will meet, the people responsible for running it can explain why it is built the way it is, and the partner can judge whether it is ready to be built.

## Operations: building until it runs without us {#operations-building-until-it-runs-without-us}

Operations is where the design is implemented, tested under real conditions and turned into something stable. It is also the phase most often cut short.

Many initiatives stop at a pilot. The pilot works, the report is written, the funding ends and the capability disappears. We treat a pilot as a step, not an outcome. The aim is a function that runs independently, durably and at scale, long after the initiative that created it has ended.

**What it produces:** a working function, operated by the institution, with the evidence that it works under the conditions that matter.

**When it is done:** when the function no longer needs us. That is described in [What stays with you](/our-approach/what-stays-with-you).

## Gates between the phases {#gates-between-the-phases}

Each move from one discipline to the next is a decision, not a date on a plan. It is taken jointly, and it rests on evidence rather than momentum.

| Moving from | To | Only when |
| --- | --- | --- |
| Intelligence | Architecture | The problem, its causes and the measure of success are agreed and evidenced. |
| Architecture | Operations | The design has met its real constraints and the partner can judge it ready. |
| Operations | Exit | The function runs, changes and recovers without us. |

Sometimes a gate shows that an earlier phase needs to be revisited. A design meets a constraint that changes the understanding of the problem; a test reveals a dependency nobody had mapped. Going back at that point is not failure. Carrying on regardless is.

## Why partners are in every phase {#why-partners-are-in-every-phase}

The sequence is not something ESFI performs on behalf of an institution and then delivers. The partner’s people are part of each phase: they help build the understanding, shape the design and run the operation.

This is slower at the beginning. It is also the only way we know to make sure that, at every gate, the partner is able to judge the work for itself rather than take our word for it. By the time the work reaches Operations, the people who will run the function already understand why it was built the way it was.

**Related:** [Where the work begins](/our-approach/where-the-work-begins) · [What stays with you](/our-approach/what-stays-with-you) · [Six questions we ask](/our-approach/six-questions-we-ask)

## On this page {#on-this-page}

ESFI — civilization infrastructure · https://esfi.eu