Even though EU defense spending reached €418 billion in 2025, a 47% rise since 2022, and is projected to climb to €454 billion in 2026, the European Defence Agency (EDA) warns that, under current national plans, Europe's shortfalls in naval forces are unlikely to be closed by 2030.

For naval shipbuilding, the pressure to deliver more vessels, faster, has never been higher, and the constraint isn't simply dry docks, steel or skilled welders. It's fragmentation, both between countries and inside organizations. Ask how a yard keeps thousands of parts, drawings and revisions in sync across a naval program, and the answer varies widely: modern shipbuilding software in one yard, a legacy PDM system and a stack of spreadsheets in the next. Even within a single yard, engineering data is often split across systems, with an ERP that doesn't talk to either.

With a stronger push for European sovereignty and growing attention to sustainability, that fragmentation is becoming harder to ignore, and digital shipbuilding is fast becoming a necessity rather than an option.

6 data challenges holding back naval shipbuilding

Steel decides how much a yard can build. Data decides how much of it is built right the first time. In naval shipbuilding, programs run for years, requirements shift mid-build and every decision has to be traceable from day 1. In that environment, fragmented data doesn't stay contained. It cascades through every stage of a program, adding rework, delays, and stretching lead times.

1. Outdated designs on the production floor

Naval programs rarely have the luxury of a finished design. To meet delivery dates, yards cut steel for early blocks while later sections are still being engineered, and the pressure to deliver faster pushes that overlap even further.

When engineering data is split between a legacy PDM tool and spreadsheets, nobody can say with certainty which revision production is working from. In practice, that might mean a block being outfitted with a pipe route that engineering changed two weeks earlier.

2. Design changes discovered too late

A naval vessel is a tightly coupled system, and its requirements often evolve during the build as systems and mission profiles change. Swap one piece of equipment and the change can ripple into structure, weight, cabling, ventilation and the bill of materials. When that information sits in disconnected files, the ripples surface late, on the production floor, where they cost the most to fix.

3. Mismatched bills of materials

Engineering defines what the ship is made of. ERP buys, plans and schedules it. When the two aren't connected, people bridge the gap by hand: re-typing part data, reconciling lists, chasing discrepancies. With long-lead naval equipment, an order placed against an outdated revision can mean months of delay, not days.

4. Person-dependent approvals

In many yards, releasing a drawing or approving a part depends on a few experienced people who know how it works. With a generation of engineers retiring, that is a continuity risk. And defense customers expect every decision to be traceable, which an approval trail spread across email and spreadsheets cannot reliably provide.

5. Hidden costs and carbon footprint

Most of a vessel's cost is locked in during design, yet it is often only calculated later. When one supplier delivers late, the impact ripples through the build sequence: outfitting stalls, blocks wait in the yard, and work is resequenced or done out of order at a higher cost. On the shop floor, rework, extra labor hours and expedited parts add up without ever being traced back to the change that caused them.

By the time the real number surfaces, there is little room left to steer.

6. No transparency on program status

Defense customers expect regular, accurate progress reporting. When data is scattered, simple questions become hard: What has been released? What is waiting for approval? Which changes are still open?

And reports compiled by hand from contradictory sources rarely offer the traceable, accurate picture engineers can stand behind.

The digital thread: how digital shipbuilding connects design, production and cost

A digital thread is a continuous flow of information that connects every stage of a vessel's lifecycle, from the first design decision to the delivered ship. Where a digital twin is the virtual model of the vessel, the digital thread is what keeps that model, and every team working on it, supplied with accurate, traceable data.

By connecting design, engineering, production, cost and performance data this way, shipbuilders can create a living digital twin of each vessel, automate the handovers that slow yards down, and take control of every stage of the build.

1. Design and engineering in one model

Every change made at the drawing board reaches the parts list and the production drawings automatically. Integrated CAD software makes it possible for designers and engineers to work on the same model, and design data flows into engineering without exporting, redrawing or re-entering it. The result is fewer drawing errors and faster design iterations.

2. One source of truth for every part and revision

Every part, drawing and revision has a single home, with a clear status and history. Shipbuilding PLM software, built on product lifecycle management, assesses each change against the full product structure before release, and routes approvals through standardized workflows instead of email chains. Know-how stays in the system when experienced engineers leave, and defense customers get a complete record of who approved what, and when.

3. Engineering and business in sync

Purchasing, planning and production work from the same bill of materials, so long-lead equipment is ordered against the right revision. By connecting PLM to ERP and other business systems with tailored low code applications, released engineering data flows automatically into purchasing and planning, and nobody re-types part lists by hand. That means less reconciliation work and fewer costly ordering mistakes.

4. A shop floor that sees what engineering sees

The shop floor always builds from the latest released design, and what happens there flows back to engineering. A manufacturing execution system (MES) connected to the digital thread captures progress, rework and extra hours as they happen, and provides digital work instructions and a complete as-built record of every vessel. When a supplier is late, plans can be adjusted with a clear view of what that means for the rest of the build.

5. Cost and carbon decided while the design is still open

Teams see what a design change or supplier delay will cost before it reaches the budget. Product cost management software (PCM) calculates cost and carbon footprint while the design is still open, including complex, non-linear pricing models from suppliers. It also gives buyers a fact-based position in supplier negotiations and a reliable basis for quotes and tenders.

6. Live insight instead of manual reports

Program managers, engineers and customers see real progress as it happens, backed by data they can trace and trust. An industrial IoT and analytics layer brings data from engineering, the shop floor and the business together in tailored dashboards, with live insight into equipment performance and early warning when production drifts off plan.

7. Intelligence that moves the program forward

Intelligent process orchestration flags risks early, anticipates bottlenecks and coordinates the next step across teams and systems, so issues are resolved before they turn into delays. And because it is built on the same structured, traceable data, AI stays governed. Every action is logged, access follows the same roles and permissions as the rest of the thread, and the orchestration is tailored to each yard's own processes. That makes it compliant by design and able to scale from a single workflow to an entire program.

From spreadsheets to a digital shipyard: a CLEVR digital transformation example

With more than 30 years of experience in digital transformation, CLEVR supports PLM, manufacturing operations and application programs for multiple aerospace, defense and naval manufacturers across Europe. One of them, a leading European shipyard building naval and government vessels, faced exactly the problems described in this article.

The problem: No digital thread, no traceability

Keeping parts, drawings and specifications in sync took constant manual effort, releases and approvals depended on the know-how of individual engineers, and reporting was limited. With engineering data spread across a legacy PDM system and disconnected spreadsheets, and no link to ERP, our client needed a system that understood how a shipyard actually works.

The process: Implementing shipbuilding product lifecycle management software

Rather than treating shipyard digital transformation as a big-bang replacement, the CLEVR consultants introduced Siemens Teamcenter, an industry-leading PLM platform, in clearly defined phases. First, they implemented Teamcenter on the yard's own servers, allowing for full control over its engineering data from day one, and then, they configured it around real engineering practice. This meant mapping out how custom types and properties should describe parts, drawings and documents the way the yard's engineers actually work with them, establishing roles and access rights that define who can create, change and release what, and standardizing release workflows so every drawing and part follows a defined route from draft to approval.

The result: Value that is built to scale

That foundation is now live: every part, drawing and revision has one home and a traceable history, and approvals no longer depend on who happens to know the process. More importantly, it gives the shipyard a base to build on. Advanced workflows, reporting, CAD integration and the connection to ERP are already being rolled out, each one adding automation on top of data that is structured and trusted. Once the thread is connected end to end, intelligence can be added to anticipate issues, orchestrate work across teams and help the yard grow faster as its programs scale.

CLEVR: Your go-to partner for shipyard digital transformation

This is the true power of the CLEVR methodology.

Rather than forcing a standard template, our consultants take the time to understand how each shipyard engineers its vessels, and configure the system around that. We work in phases, so every step delivers something usable before the next one begins, and we stay alongside our customers' teams from day one. We are not rebuilding old integrations as they were, we design for fewer manual steps from the start. That is what turns a software implementation into a change engineers feel in their day-to-day work.

Want to see how a connected digital thread can help your shipyard turn growing demand into vessels delivered on time? Contact CLEVR for a consultation.

The EU battery passport: How PLM and MES get you ready for February 2027

Four months. That is all that is left before the EU's first mandatory digital product passport goes live. From 18 February 2027, every EV battery, light means of transport (LMT) battery and industrial battery above 2 kWh placed on the EU market needs a digital battery passport. No passport, no market access.

This is not just an automotive problem. Grid-scale, C&I and most home storage systems count as industrial batteries, and that market is booming. SolarPower Europe's European Battery Market Outlook 2026–2030 reports 36 GWh of new storage installed in Europe in 2025, up 48%, taking total capacity past 100 GWh. Annual installations are expected to exceed 50 GWh in 2026 and reach 138 GWh by 2030.

The question for manufacturers, pack assemblers and storage integrators is no longer whether to prepare, but whether your product and production data can deliver what the passport demands. That is where PLM and MES come in.
‍

What the EU battery passport actually requires

The passport is created by Article 77 of the EU Batteries Regulation (EU) 2023/1542, with its content defined in Annex XIII. It is an electronic record per individual battery, reached through a QR code on the product and linked to a unique identifier.

Three categories are in scope from 18 February 2027:

• Electric vehicle batteries, regardless of capacity.
• Light means of transport (LMT) batteries, such as e-bike batteries.
• Industrial batteries above 2 kWh, including stationary storage for the grid, C&I sites and most homes.

The Battery Pass consortium translated the regulation into a data attribute longlist of roughly 90 mandatory data points, now formalized in DIN DKE SPEC 99100. They span product information, material composition, carbon footprint, recycled content, due diligence, performance and durability, circularity and dynamic state-of-health data. Access is tiered between the public, parties with a legitimate interest such as recyclers, and authorities.
‍

What the Commission clarified in 2026

• The registry is live. The EU Digital Product Passport Registry opened on 20 July 2026. Operators verify themselves with a qualified electronic seal and register each passport's identifier.
• Whoever finishes the battery owns the passport.The Commission's battery passport FAQ (September 2026) places responsibility with the operator that completes the working battery, usually where the BMS is fitted. Suppliers can enter data on its behalf, but legal responsibility stays with the operator.
• Second life means a new passport. A repurposed battery, such as an EV battery turned into stationary storage, needs a new passport linked to the old one.
• The date is not moving. The Environmental Omnibus (Omnibus VIII) amends parts of the regulation, but not the passport deadline. EUROBAT and RECHARGE are lobbying for a phased rollout; that is a position, not law.
  ‍

What is still open

The implementing act on who may access restricted data missed its 18 August 2026 deadline; Taylor Wessing expects adoption in Q4 2026. Carbon footprint and recycled content follow their own timelines, and due diligence reporting starts in August 2027. In short: the deadline is fixed, the rulebook is not, so your data architecture must absorb changes without a rebuild.
‍

A data problem, not a QR-code problem

It is tempting to treat the passport as a labelling exercise: generate a QR code, host a page, done. But the QR code is the easy part. The hard part is the data behind it, which lives in many places:

The pattern is clear: the designed product lives in PLM, the produced product lives in MES. The passport needs both, per battery, consistent and up to date across a life that can span a decade or more.

The companies that will struggle in February are not those without a passport platform. They are those with product data in spreadsheets, as-built records that cannot be traced to a design revision, and no clear view of which cell lot went into which pack.
‍

PLM: The product backbone of the passport

A battery passport is a structured description of a product, and your Product Lifecycle Management (PLM) platform already owns that description. With PLM for manufacturing on Siemens Teamcenter or Teamcenter X, PLM delivers four things the passport needs.

1. One trusted source for the as-designed battery
   Chemistry, capacity, weight, cell format and pack structure are all defined in the engineering BOM. Pulling passport data from PLM instead of spreadsheets gives every field an owner, a release status and a revision: data you can defend to a market surveillance authority.
2. Material compliance built into design
   Capturing supplier material declarations against parts in PLM means hazardous substances and critical raw materials are checked while the design is still changeable, not after the first production run. The same structure supports recycled content reporting later.
3. Carbon footprint as a design parameter
   The carbon footprint is declared per model and plant, and future rules foresee performance classes and maximum thresholds. That makes CO₂e a design constraint, just like cost and weight. Teamcenter Product Cost Management lets engineers compare the cost and carbon footprint of alternatives early, as we explored in AI in product cost management and sustainability.
4. Change management that keeps the passport up to date
   A new cell supplier, a firmware update or a different cathode blend can all change passport data. Formal change management in PLM ensures every relevant change triggers a passport update, with a full history of who changed what and why, including the dismantling and spare part information recyclers need.
   ‍

MES: The production evidence behind every passport

PLM describes the battery you designed. But a passport is issued for each individual battery, and only the shopfloor knows what went into it. That is the job of your MES, part of a Manufacturing Operations Management (MOM) landscape built on solutions such as Siemens Opcenter.

1. A unique identity per battery
   Every passport needs an ISO/IEC 15459-compliant identifier linked to the QR code. MES assigns it when the battery is completed and ties it to the work order and the date and place of manufacture.
2. Full genealogy from cell to pack
   Because the passport sits with whoever finishes the battery, pack assemblers and storage integrators inherit the data work for components they did not make. A complete as-built genealogy connects supplier data on incoming cells to the finished product, and answers a recall or an authority's question in hours, not weeks.
3. Test results as performance data
   Capacity, internal resistance, power and round-trip efficiency are measured at end-of-line testing. Captured in MES, they become passport performance data and the baseline for later state-of-health reporting.
4. Plant-level data for the carbon footprint
   The footprint is declared per manufacturing plant. Energy use, scrap and yield from MES, combined with IoT data from Siemens Insights Hub, turn estimates into measured figures.
   ‍

The real value: Closing the loop

Released designs flow from PLM to the shop floor; as-built data, deviations and test results flow back. When a battery deviates from its released design, its passport reflects it. That digital thread from as-designed to as-built is exactly what the regulation asks you to prove.
‍

From compliance to the agentic enterprise

PLM and MES give you the data, but a passport is a living record: created at production, updated on change, extended on repurposing, closed at recycling. Across thousands of batteries, dozens of suppliers and an evolving rulebook, manual processes will not keep up.

This cross-system, rule-heavy, auditable work is what the agentic enterprise is built for: humans and AI agents working side by side on trusted data, inside governed processes. Enter Siemens Intelligence Center X (ICX), announced at Realize LIVE 2026 and built on Mendix. As our colleague Gerrit Kiefer explained in Make processes intelligent, ICX combines four capabilities on one governed foundation. Here is how they map onto the passport.
‍

Knowledge graph: One connected view of every battery

Graph Studio connects the design revision in Teamcenter, the genealogy in Opcenter, supplier declarations in ERP and BMS field data through one ontology, instead of copying them into yet another database. The passport becomes a governed view on that graph, with lineage for every field.
‍

Machine learning: From records to predictions

AI Studio runs models on that contextualised data: predicting state of health from test and field data, flagging production anomalies that may affect durability claims, or identifying the best second-life candidates in a storage fleet.
‍

Agentic applications: Let agents do the legwork

With the Mendix AI platform, teams build agentic applications such as:

• A passport readiness agent that checks each model against Annex XIII and flags missing or inconsistent fields before release.
• A supplier data agent that requests, validates and chases material and carbon footprint declarations.
• A change impact agent that detects when an engineering change affects passport data and proposes updates.
• A regulatory watch agent that maps new implementing and delegated acts to your data model.
  ‍

Orchestration and trust: Humans stay accountable

Legal responsibility stays with the company placing the battery on the market, whoever enters the data. Mendix Workflows orchestrate agents and people in one traceable process: an agent prepares, a human approves, the system publishes. The ICX trust layer adds guardrails, logging and access control, so every update has an owner, a timestamp and a data lineage. That is how AI becomes a compliance asset instead of a risk, and what we call intelligent enterprise orchestration.
‍

A practical roadmap to 18 February 2027

Four months is tight but workable. We recommend this sequence:

1. Confirm scope and role (now). Which products are EV, LMT or industrial batteries above 2 kWh? For modular storage, check whether units share a BMS, since their combined capacity then counts. If you finish the battery, the passport is yours.
2. Assess data gaps (November). Map the roughly 90 attributes against PLM, MES, ERP and supplier data, with a source, owner and quality level per field.
3. Secure supplier data (November–December). Agree written authorisations, data clauses, formats and update triggers with cell, module and material suppliers.
4. Connect the digital thread (December–January). Link released PLM data with serialisation, genealogy and test data in MES. Start your EU registry verification early.
5. Pilot one product family (January). Create, publish and update a passport end to end, including an engineering change and a repurposing scenario.
6. Go live and scale with agents (February onwards). Roll out across product families and automate with governed agents, ready for due diligence reporting from August 2027 and the obligations that follow.

Meanwhile, watch the access rights act: its draft, expected around year-end, decides who can read the restricted parts of your passport.
‍

How CLEVR helps you get passport-ready

The battery passport is the EU's first mandatory digital product passport, not its last: the Ecodesign for Sustainable Products Regulation extends the same logic to many more products. A quick QR-code fix means starting over for every next regulation. Connected PLM and MES data, orchestrated by governed agents, builds a foundation for better traceability, faster recalls, smarter design and new second-life business models.

As the largest dedicated Siemens and Mendix partner in Europe, with more than 30 years of industry experience, CLEVR helps manufacturers and energy and utilities companies connect Teamcenter, Opcenter and existing systems into one digital thread, extended with agents through Intelligence Center X. We start where you are: A scope and data gap assessment, a pilot, and a roadmap to scale.

February 2027 is closer than it looks. Let's make sure your data is ready before your batteries are.

‍Part 4 of 4, Straight from the Mendix Community Round Table Meetup in Amersfoort on June 2nd, 2026. Parts 1 to 3 questioned what is left for the consultants to do, whether we can trust an AI agent to do it, and whether the platform still earns the choice. This article asks the commercial question underneath all three: who actually needs such a platform?

A seller at one of the tables had called the Dutch IT director of a top-tier investment bank to invite him to an event. Friendly guy, so he got a few minutes, and the director used them to explain why the answer was no. "No issue with low code," he said. "We're just not doing that anymore. We do everything with AI now, the full application lifecycle." And how do you govern all that? "We have four thousand engineers, and the resources to have full teams checking it." The seller told us afterwards that he could not counter it and did not pretend otherwise.

That answer stayed with me for the rest of the evening, and it has been hanging over this series ever since. I have written three times about June 2nd: what is left for the consultant to do, whether we can trust an agent to do it, and whether Mendix is still a defensible platform to do it on. Each of them ends up in roughly the same place: the value holds if you build it right. So the commercial question remains. If all of that is true, who actually needs it?

‍

The upper end of the market answered honestly

The bank was being accurate rather than dismissive. A company with four thousand engineers can do everything with AI and put full teams on checking the output, because it can afford to. Those enterprises have their AI in place and their budgets spent, so the question they ask is fair: why would we add a platform for this when we already build one ourselves?

The instinct many of us were trained on, chase the biggest logos and land the enterprise, deserves a second look. The companies with the most resources need a platform that takes the hassle away the least, because they are used to carrying the hassle themselves. At least when they are a software-focussed enterprise already. If they are not, a platform like Mendix still gives an incredible head start without the years it takes to build a platform approach yourself. Because yes, that's what it needs to reach a situation that is only getting close to what platforms like those of Siemens can offer.

‍

A nuance I want to add myself

Read that answer back and it sounds like AI mostly closed the door. I do not think it did. Was that bank ever going to buy a low code platform? In 2019, with the same four thousand engineers, before any of this? Almost certainly not to replace its entire tech stack.

A few things keep a company that size building its own, and most of them have little to do with AI.

• Habit and history. An organization that has built software its own way for twenty years has an estate, standards, a review process and existing resources and components. Nobody rips that out because a vendor turned up with a better story.
• Talent, which is more local than we usually admit. If you can hire four thousand engineers, and hire them where the labor cost works out, building in-house is a defensible choice. For a company in the Netherlands hiring in the Netherlands that calculation can look completely different, and so can the values and beliefs behind it.
• The cost they already paid, which the bank did not mention. Years of procedures, internal standards, a platform team, an internal developer platform that somebody has to keep alive. They did not skip the hassle. They bought it in-house and spread the cost over a decade, which is an expensive position that only a company with the scale, strategy and time could get into.

So the four thousand engineers do not prove the platform case is dead. They show that a company big enough, with the right strategy, can build a similar platform experience for itself. This one did, and it took years and real money. It says little about low code, and a lot about who can afford to do without it.

‍

A moving market

I do not even feel it changed too much, with one important addition that I will come back to later. The opening sits with the company that says something close to "I am a construction firm, I am not an IT company," and wants a single supplier to have covered the security, the governance and the integrations already. They cannot put internal teams on checking high-code AI output, and they do not want to either. They want to buy off the hassle, which, as I argued last time, is the real low code pitch once you stop thinking it is only about first-delivery speed.

A useful dividing line through the middle of that market is roughly the number of apps you run. A one-app company drifts toward the pure-prompting tools as a head start, because for one app, why not just prompt it and see how it holds? But once you have a dozen apps, integrations, and things that have to talk to each other and be governed together, you need something that holds the whole estate together. An orchestration platform that can manage them all starts to make sense there in a way it never did for a single app. That is the enterprise profile where all of this still fits. It is too small to have outgrown the platform for domain-specific reasons, and too big to prompt its one app into existence before caring about the full picture. I call it the orchestrating middle, and it is where most companies will find themselves.

‍

The objections

Some objections come up every time, and I would rather answer them than wish them away.

The first is perception. There is a feeling in some rooms that choosing low code in 2026 is the unadventurous option, the sensible and slightly dull choice while everyone else does something shiny with AI. That perception is only partly real, given the huge AI investments from Siemens as well. The platform might not be on par with the possibilities of the big frontier models the day after they release a new version. That said, even since the Meetup in June (this article was published in September), AI assisted development with Mendix matured enormously. I am quite sure the discussion would be more nuanced if we hosted this session again.

The second is lock-in, and it is a fair concern. "It's half the price, and then I own the IP" is something buyers genuinely say when they weigh a managed platform against high code. High code feels like freedom, a managed platform can feel like a cage, and AI has, if anything, made the high-code side look less locked-in than it used to. Denying the lock does not help. Being clear about what it buys you does, and so does being clear about what migrating away would cost. With a reasonably open platform like Mendix that cost is lower than people expect, and with Maia Transform it is now fairly doable to migrate code bases to and from Mendix. Having that option can be a good peace of mind while you enjoy the benefits of the platform.

The third one is quieter. A customer who already has a mature AI strategy elsewhere does not want to bolt new AI onto yet another platform's resource pool. They want to use what they have already invested in. Pitch only greenfield, "add AI here," and you will keep meeting buyers who came at AI from a different direction and got there first. Respecting that allows for a much deeper conversation about what is needed, especially as Mendix lets you use "their" AI, bring your own, or blend them into a mix you like.

‍

The actual pitch

It is sharper than what came before, even if it sounds like a downgrade at first.

You sell having already done it: the supplier who has solved the governance, the security and the integration, so the construction firm does not have to. For the right customer, "we have done the hard part already" is a stronger line than "we are faster," which stopped being true the moment a prompt could ship faster than any of us. Even though these are mostly prototypes and not enterprise grade apps from the first delivery. When shipping your Mendix app on day one, you get ISO 27001, 27017, 27018, 9001, and SOC 2 Type II reports, plus support for GDPR, HIPAA and PCI-DSS without even knowing what they entail. This is and always will be one of the huge drivers of owning Mendix as your enterprise app platform.

There is also one wedge the four-thousand-engineer crowd cannot take, because it has nothing to do with resources and everything to do with trust. Data. A consultant at another table, talking about a government client, put it plainly: they are "very scared, what's going to happen to the data." So you do not lead with the AI. You build the trust first, keep the data in their hands on infrastructure they control, and let the AI come second. For a whole class of customers, in government, in healthcare, anywhere the data cannot leave the building, that is the entire reason they can say yes at all. Local LLMs rapidly land here, and Mendix and Maia can use them just as well.

For those who reached this part of the series and think: but what about Siemens? Most of the Dutch Mendix Community has experience in other domains than manufacturing, so it does not come as a surprise that this angle did not reach a table. It should not be ignored either. With Mendix in its portfolio, including the broad (AI) capabilities discussed above, I can only be happy for the customers that are already well invested in the Siemens ecosystem.

‍

Closing the series

The bank with four thousand engineers was never going to be the main growth, and chasing it is how you end up feeling replaceable. The growth is with everyone below that line who cannot do it themselves and does not want to: the orchestrating middle, the regulated, the ones who want one trusted supplier to have covered the hard parts and to keep their data where it belongs.

Those were four questions from one evening: what is left for us to do, whether we can trust the agent to do it, whether the platform still earns the choice, and who actually needs it. Now that I have written them down, I notice that none of the answers are really about the technology. They come down to judgment, trust, and knowing who you are for. Which is a reassuring thing for a room full of consultants worried about AI to have talked their way into.

Thank you for reading, if you made it through the full series. These articles reflect the discussions in the room, completed with my own opinion, so I am very much looking forward to your thoughts. Does it resonate with what you are seeing? Are you happy, or worried about the possible new perspectives? Either way, I am eager to host another Round Table later this year, or early next year, to go through some statements in person again.

‍

Originally published here.