Nation-State Platforms
Somewhere in a large regulated organization, a team is running its own GitLab CE instance. They set it up three years ago because the central instance was slow, or lacked a feature, or had a change process that took weeks. They shipped faster.
The organization, meanwhile, lost something it cannot easily name: the ability to answer basic questions about itself. It no longer knows where all its source code lives. It cannot answer, with confidence, which systems would be affected by a given vulnerability disclosure. When the engineer who set up the instance leaves (and they will leave), the institutional knowledge of what runs against it leaves with them.
The team made a defensible local decision. The organization suffered a real loss. Both sides have a point. No one in the organization has the authority to decide between them, because the authority was never granted in a form that would survive scrutiny.
The question is constitutional: who decides what the platform may do, and who verifies that it does so correctly?
This is one face of the problem. Two more lie behind it.
The framing
Platform governance in regulated organizations is a constitutional question that the discipline treats as an engineering question. The established discourses (Team Topologies, Platform-as-a-Product, Internal Developer Platforms) do not address it, because they treat platform organization as a product and team design problem, not as a governance problem.
Platform-as-a-Product is meant here in the reduced reading widespread in industry discourse, where platform teams treat application teams as customers whose articulated demands set the agenda. The serious reading (platform teams as market actors with their own strategy, market understanding, and responsibility for their offerings) is compatible with the model developed here, and in fact deepened by it.
Team Topologies addresses a different question: how to structure teams and their interactions for flow. The question this paper addresses is orthogonal: who within those structures has authority to decide what, and how is that authority legitimated and audited. The two models are combinable; they operate on different levels.
Technology startups have founder authority. Regulated organizations of sufficient size have constitutional questions whether they acknowledge them or not.
Three failure modes make this visible:
Empire-building. A platform function that sets its own mandates and defines its own success metrics, expanding scope without external constraint. Not through malice, but through combining rule-making with rule-following in the same hands.
Consistency as self-justification. Mandates argued on the basis of standardization alone, without reference to a value that standardization serves. Consistency is sometimes the means. It is never the purpose.
Self-attestation without audit. A platform function that measures its own adoption, reports on its own compliance, and calls the result success. Grading your own exam.
Each of these is empirically common. Constitutional theorists have described each for centuries, with structural answers platform engineers can borrow. The discipline has not borrowed them, largely because it does not recognize its problems as constitutional.
What the platform actually does
The central question any platform organization must answer: what is the job?
Two intrinsic jobs justify voluntary adoption. A third concern does not.
Job one: cognitive load reduction. The team-centric half of the platform’s existence. Application teams have finite attention. Every hour spent on infrastructure routine is an hour not spent on domain work. The platform redirects attention toward the work that differentiates the organization.
What makes this job intrinsic: it has an addressee who experiences the value directly and can signal it. The application team notices whether it gains time. It can adopt or walk away, and both responses are informative. The team that benefits from the platform is the team that signals whether it works, the property that makes voluntary adoption function as a mechanism at all.
What endangers it: the temptation to displace load rather than reduce it. A platform that hides its own complexity behind an abstraction layer, but leaks enough that teams must understand both layers, has increased cognitive load, not reduced it. Whether a platform actually reduces load is not answerable through self-report. It is answerable only through the choices of application teams, and only when those choices are real: uncoerced by budget pressure, legacy lock-in, or political signaling.
Job two: options preservation. The organization-centric half. Platforms produce something that individual application teams cannot economically produce alone: the ability to switch vendors, absorb new regulations, or negotiate from aggregated demand. Options no single team can maintain on its own.
What makes this job intrinsic: it has an addressee, but a different one. The value is experienced not by the application team today, but by the organization in future states that have not yet occurred. Options preservation cannot be measured through adoption. The right metric would be the number of options that can actually be exercised in a crisis, visible only when the crisis arrives.
The two jobs are not always aligned. Deep integration with a single hyperscaler reduces cognitive load: fewer abstractions, better tooling, less friction. It also destroys options. This is a real trade-off, and pretending it does not exist is how organizations wake up locked in.
The third concern: the organization’s ability to answer basic questions about itself. Where its code lives, what depends on what, who owns which system. This concern is real, but structurally different. Its incentives point away from voluntary adoption. The team that would need to invest in it is not the team that benefits from it. This asymmetry marks the boundary where voluntary adoption stops working, and where that boundary must be explicitly drawn rather than silently ignored.
What is not the job: consistency for its own sake. When a platform proposal argues consistency, the correct follow-up question is: which of the intrinsic jobs does this consistency serve? If the answer names one of the two jobs, good. If the answer is consistency is good, the proposal fails. A sharper test than it appears; many existing platform mandates would not pass it.
The architecture in outline
The constitutional analogy is structural, not literal. Corporate organizations are not states: they have owners, fiduciary duty, employment relationships, regulatory frameworks. What carries over is the structural logic of separation of powers, not the legitimation theory of democratic government.
Three functions exist in every platform organization of sufficient size. They always exist. The question is whether they are separated.
The platform as executive. Produces solutions. Operates services. Has no authority to enact mandates of its own, though it may propose them. Its job is to build what is needed, not to decide what is required.
Governance as legislative. Sets technology-open requirements. Formulates outcome mandates, not implementation mandates. Decides what the organization requires, not which product fulfills the requirement.
Governance faces a hard legitimacy question: who sits in this function, and why should anyone accept their authority? One answer is sortition: random selection from the engineering population above a defined seniority threshold, with limited terms and mandatory cooldown periods. This is the most radical element of the model, and it warrants its own treatment. Here, the claim is only structural: governance must be institutionally separated from the platform, and its legitimation must not depend on the platform’s selection.
Audit as judiciary. An independent function with its own reporting line to the executive board or supervisory board, not to the platform organization. Career auditors with their own career paths. Sanction authority within existing rules. No rule-making authority of its own. Audits the platform, the governance function, and the consuming teams, all three under the same scrutiny.
Readers from banking, insurance, and other heavily regulated industries will recognize structural parallels to Three Lines of Defense. Both models draw on the same constitutional tradition: separation of powers as protection against concentrated authority, applied to different domains. Three Lines of Defense separates operational management, risk oversight, and independent assurance. The model here separates production, rule-setting, and verification. The structural logic is identical; the application domain is platform governance rather than enterprise risk.
The central structural argument: when these functions share personnel, reporting lines, or incentive structures, the system collapses predictably.
Platform plus governance produces empire. The function that builds solutions also decides what is mandatory, and discovers, reliably, that what it has built should be mandatory.
Governance plus audit produces self-attestation. The function that sets rules also verifies compliance, and discovers, reliably, that its rules are being followed.
Platform plus audit produces self-examination. The function that operates services also reports on their quality, and discovers, reliably, that quality is high.
None of these collapses require bad actors. They require only the absence of structural separation.
What this means in practice
Three consequences, briefly stated.
Mandates require honest justification. Every mandate must reference one of the intrinsic jobs or an external governance requirement. A mandate without a named job is illegitimate, not because mandates are bad, but because unjustified mandates are indistinguishable from empire-building. The ADR that documents the mandate is the mechanism by which it becomes auditable.
Exceptions are the best signal of functioning. A mandate that produces zero exceptions over years is suspicious. Either its justification has never been tested, or its exception process is broken. Both require repair. Organizations that treat exceptions as failure have confused compliance with governance. A functioning exception process forces the mandate’s justification to be re-examined against a concrete case. It surfaces where assumptions do not hold. And it signals to the governed that the system is responsive, not merely coercive. Zero exceptions is not self-evidently good. It may indicate a well-calibrated rule, a well-bounded scope, or a process no one believes is worth invoking. The investigation is the point, not the conclusion.
Documentation is constitutional, not administrative. Architecture Decision Records in platform governance are the form in which decisions become revisable, auditable, and dissolvable. The executive board retains the authority to dissolve any decision. But it does so through a documented process that must address the original justification. Protection lies not in formal irrevocability, but in enforced visibility.
These structural separations address a deeper incentive logic (who benefits from a mandate, who bears its cost, and how the asymmetry between the two is made visible) that warrants its own treatment elsewhere in this series.
Scope
The model described here is an ideal type for regulated organizations with sufficient engineering depth, established governance traditions, and functioning documentation culture. Critical infrastructure operators, banks above a certain size, insurers, large industrial and infrastructure corporations, government agencies.
The scope is restricted, but covers a substantial portion of the German and European engineering market: organizations where platforms serve millions of users and face regulatory audit.
Where it does not apply: technology startups where founder authority resolves governance questions by fiat. Small software companies without regulatory pressure. Outsourcing-driven organizations without in-house engineering depth. The model would be overdimensioned in all three; constitutional machinery for problems that do not yet exist at that scale.
The model describes a target state, not a migration path. How an organization moves from its current platform governance toward this structure is a separate question, beyond the scope of this text.
The majority of platform engineering literature suffers from an undeclared scope problem. Models that do not centrally address governance separation are exported into regulated organizations where that separation is non-negotiable. The export is rarely accompanied by a translation manual. The resulting failures are attributed to implementation rather than to category error.
Separation of powers. Sortition for governance legitimation. Job-based mandate justification. None of these come from the platform engineering world; they come from constitutional theory, political philosophy, public administration science.
The answers platform engineering needs for its governance problems exist in adjacent disciplines - disciplines that have spent centuries on the question of how authority is legitimated, constrained, and audited. The bridge is buildable. This series attempts to build it.
Further reading: Camille Fournier’s work on platform-as-product provides the foundation this model builds on. Mark Schwartz’s War and Peace and IT bridges the gap between technology strategy and regulated enterprise governance. The model developed here takes the next step: from product thinking and organizational strategy into constitutional structure.