Constitutional 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 text 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.
Four 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.
Local sovereignty without organizational accountability. Consuming teams operating their own infrastructure to escape platform constraints, accumulating local optimization at the cost of organizational legibility. Not as defiance, but as the legitimate pursuit of local effectiveness in the absence of legitimate organizational claims.
Each failure mode has a legitimate counterpart. Centralized authority is not empire-building; local autonomy is not fragmentation. The failure modes are overreaches of legitimate forms, not the forms themselves.
The four are not of one kind. The first three are concentration failures: a function annexing a role that is not its own. The fourth is their shadow: the failure that arises precisely where separation is absent or illegitimate. Local sovereignty is not a fourth species of overreach; it is what the first three produce downstream when no legitimate organizational claim exists to answer. The GitLab CE instance in the opening is not malice. It is the rational response to the absence of the structure this essay describes.
Each of these is empirically common. The failures have been described for centuries, with answers platform engineers can borrow. The contemporary platform engineering discourse 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?
Three jobs. Two are legitimated by voluntary adoption. The third is not, and that difference is the point.
Job one: cognitive load reduction. The team-centric side 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. This is what 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 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 side. 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 is periodically tested exercisability under constraint: exit drills, vendor failover exercises, dependency inventories, portability proofs.
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 ignoring it is how lock-in accumulates unnoticed.
Job three: organizational legibility. The organization’s ability to answer basic questions about itself. Where its code lives, what depends on what, who owns which system. Asset inventories. Dependency graphs. Control mappings. Blast-radius estimates. Audit evidence. Vendor exposure. These are not administrative artefacts but epistemic infrastructure: the means by which an organization knows itself well enough to act under regulatory scrutiny.
This job is real, but structurally different from the first two. 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 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. This is not democracy inside the firm; it is constrained authority inside a hierarchy.
This essay describes what the architecture is; the costs of building it are real but not its subject here.
A decision is constitutional when it distributes irreversible costs across the organization, creates obligations that survive personnel turnover, constrains autonomy in ways that require legitimation, and must remain auditable under external scrutiny. Platform governance produces such decisions routinely. The question is whether the organization treats them as such.
Any platform organization that produces solutions, sets requirements, and verifies compliance has three functions, even when one team or one person performs all three. The functions are analytically distinct whether or not they are institutionally separated. The fusion is precisely the problem; the separation is the question.
The platform as executive. Produces solutions. Operates services. Has authority over its own operational standards: supported versions, deprecation windows, interface contracts, emergency controls. Has no authority to enact organization-wide mandates whose costs fall outside its own remit, 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? This essay does not answer it. It establishes a necessary condition: governance must be institutionally separated from the platform, and its legitimation must not depend on the platform’s selection. This negative criterion says what legitimation may not be, without yet saying what it is. Mechanisms that satisfy it exist; sortition is one candidate among several, treated in a later text.
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.
The audit function does not only verify conformity to mandates. It verifies whether a mandate ever had the named job it claims, or whether the platform-plus-governance fusion invented the job after the fact. A model that can only detect when the governed overreach, never when the governing apparatus does, is not separated. It is partisan and calls itself neutral.
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 closely analogous; 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.
A structural caveat the model must state itself. Separation of powers as described here protects against horizontal capture: one function annexing another’s role. It cannot, on its own, protect against vertical capture, because all three functions draw budget and appointment from the same apex. In a state, the branches have independent power bases; in a firm, they do not. What is separated here is reporting lines and incentives, not the source of authority. The apex of the hierarchy is the single point at which all three separations collapse simultaneously, and no internal arrangement repairs this, because every internal arrangement is installed by that apex. The model makes platform governance externally auditable. The only actor with a power base independent of the firm’s apex sits outside the firm: the regulator.
Separation has its own costs. Coordination overhead grows. Decisions become slower. Authority becomes more diffuse and harder to exercise unilaterally. The argument here is not that separation is free, but that its costs are different from, and frequently less than, the failure modes its absence produces.
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 one 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 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, job-based mandate justification: none of this is native to platform engineering. It is borrowed from constitutional theory, political philosophy, and public administration, where it has a long empirical track record. The contribution here is not the apparatus. It is noticing that the problem was constitutional all along.
The answers platform engineering needs for its governance problems already exist in adjacent disciplines: disciplines that have spent centuries on how authority is legitimated, constrained, and audited. They have not been carried across.
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.