The Capability the Standard Assumes

On what mature guidance quietly presumes an organization has already become

Abstract

The first two papers in this series were built from the inside out — from incentives, and from the traces that undesigned work leaves behind. This one was built from a moment of recognition. For some time we had been circling a claim we could not quite place; reading the FATF's 2026 report on public–private partnerships for information sharing is when it came into focus. So this is not a paper about that report. It is a paper that happened because we read it. The report — thoughtful, balanced, unusually mature — is the catalyst, not the subject. The subject is the operational assumption that mature guidance naturally makes: that when a standard asks an organization to collaborate operationally, measure outcomes, build feedback loops or dedicate resources, it assumes the organization already possesses the internal operational capability to do so. Guidance almost has to assume this; it is close to what makes guidance guidance. Working Paper 0001 asked why some operational capabilities stay undesigned; 0002, how to recognize one from its traces; this paper asks what standards quietly assume about it. Our answer, so far, is that guidance describes the properties of a mature capability far more readily than the moment an organization first recognizes it has one — and that a layer we might call operational capability formation sits, largely undescribed, between policy and governance. And late in the work we met the same layer a second time, one level up — between organizations rather than inside them — where the capability to evolve shared operational practice is assumed just as quietly and, we suspect, is just as often missing. The two layers, we have come to think, hold each other in place — a reinforcing equilibrium that may be the plainest reason a capability this real has stayed undesigned, at both levels, for so long. None of this is criticism. It is an attempt to notice a layer, and to give it a name.

What reading it did

Over the past year we kept meeting the same small moment. An organization could explain, in fine detail, how it answered requests from authorities — who watched the mailbox, who checked the request, who pulled the data. Ask instead who owned the capability, and the room would go quiet. The work had an answer. The capability did not.

We had been following that pattern for two papers, from below: from the shared mailboxes where the work happens, from the one experienced person who holds what was never written down, from the four ordinary questions no one can answer. We had a good description of the thing. What we did not have was a clear view of how it looks from above — from the altitude at which standards and guidance are written.

Then we read the FATF report on public–private partnerships, and the view arrived — and with it the reason that small moment kept recurring.

We should say plainly that the report is very good. It is careful where the subject is delicate and concrete where it can afford to be. It treats trust as an operational variable rather than a pleasantry, and governance, legal basis, interoperability and feedback as the load-bearing structures they are. It maps how partnerships evolve from strategic conversation toward operational exchange, and it is honest about where they stall. If you wanted to understand the state of public–private information sharing across more than fifty jurisdictions, you would be hard pressed to find a better single account.

Which is why we have to be careful: what follows is not a review. We are not going to say the report missed something. It did not — it was the catalyst, not the subject, the document that crystallized something we had been circling, without a name for it, for two papers.

What crystallized was this. A standard, to be a standard, has to address organizations at the level of what they should do. It cannot also narrate the interior condition of every organization it speaks to; if it tried, it would stop being guidance and become ethnography. So it assumes. It assumes, reasonably, that the organization on the receiving end has — or can readily stand up — the operational capability its recommendations require. That assumption is not a weakness in guidance; it is close to the definition of it. A standard that assumed nothing about the organizations it addressed could recommend nothing — it would have to describe each one instead. To be useful to many at once, guidance has to speak to the mature state and take the road toward it as read.

And once we had seen the assumption we could not stop seeing it, because it sits beneath almost every well-formed recommendation — in this report, and far past it.

That sentence is the whole of the paper; what remains is to turn it over and look at it from one side after another. When a standard says an organization should collaborate operationally, it assumes something inside that organization can collaborate — can receive what arrives, verify it, act within a deadline, and account afterwards for what it did. The recommendation is addressed to that capability. It presumes it is there to be addressed.

So the question this paper follows is the one we have not been able to put down since:

What operational capabilities do modern standards and regulatory guidance quietly assume organizations already possess?

A report that begins where we left off

There is a reason this report crystallized it and another might not have.

Read against the first two papers, the report describes — with real fidelity — the mature end of exactly the capability we had been describing in its undesigned state. It says operationally mature partnerships rely on "secure technology, dedicated teams and multisectoral participation." It reports that trust is the most frequently cited success factor, built through structured engagement and balanced flows. It sketches a maturation path: begin with pilots and informal exchange to establish trust, then, as the partnership matures, expand membership, operational scope and resource base. It even notes, with candour, that there is no established way to measure whether a participating institution's own capability is improving — a gap it names rather than hides.

Set that beside where our series had arrived. The first paper argued that responding to authority requests has quietly become a capability that many organizations perform without ever having decided to own it. The second argued that such a capability, precisely because no one designed it, leaves recognizable traces. Both were about the capability before it crossed over: orphaned, illegible, real.

The report describes the same capability after it has crossed — owned, resourced, instrumented, trusted. It begins, in other words, more or less where our two papers ended. That is not a coincidence, and it is certainly not an omission; it is what good guidance is for. It describes the destination clearly so that organizations have something to aim at. What it does not describe — because that is not its altitude, and because almost no standard of the kind does — is the departure: the moment an organization first recognizes it has a capability here at all.

Neither reading is the true one. They are two altitudes. But the lower altitude is where we work, and from down here the assumption is visible in nearly every "organizations should."

The list that assumes a list-maker

Take the recommendations as the genre actually issues them — not this report especially, but the whole family of mature guidance it stands for. An organization should:

• collaborate operationally
• build trust
• measure outcomes
• establish governance
• maintain operational capacity
• develop interoperability
• create feedback loops
• dedicate resources
• participate in partnerships

Every item is correct. We would remove none. But read the list a second time as a set of preconditions rather than actions. To collaborate operationally, there has to be an operational function for the collaboration to land in. To measure outcomes, the organization has to be counting the right unit already. To build a feedback loop, there has to be a process on its end for the feedback to loop into. To dedicate resources, it has to have recognized the work as an object worth resourcing. To interoperate, the internal operation has to be stable enough to expose an interface at all.

In a mature organization these preconditions are simply present, which is exactly why guidance can rest on them and lose nothing. Two papers of fieldwork, though, are largely a record of how often, in this domain, they are not — how often the capability a recommendation addresses is the undesigned, unowned, half-lit thing of the first two papers. When that is so, a sound recommendation lands on an organization that cannot yet act on it, not for want of will or budget but for want of the formed capability the recommendation took for granted.

Three claims sit here, and they do not stand equally. That the assumption exists is a plain observation — you can read it in the grammar of almost any "organizations should." That it is often unmet in this domain is an inference from the fieldwork. That it matters enough to name is, for now, a hypothesis.

Read the list once more and notice that some of its items do not even live inside a single organization. Collaborate operationally. Develop interoperability. Participate in partnerships. Those do not describe something a firm can build alone; they describe something that has to form between organizations. We return to this later, because it turns out the assumption we are tracing has a second storey. But it is worth marking here: the list quietly presumes not one capability but two — an internal one, and a shared one.

Two vocabularies for one word

Some of the difficulty hides inside a single word, and separating its two senses helps.

When the report speaks of "capacity" — as when it observes that large financial institutions are often well-equipped to report while smaller firms "may lack or have lower capacity" — it uses the word the way the whole field does, and uses it well. Capacity, there, is a property an organization is observed to have or to lack: a state, read from the outside, that helps explain why some partnerships scale and others stall.

We keep reaching for the same word to mean something adjacent but different — not the state of having capacity but the process by which an organization comes to have it: capability formation, the untidy internal work of turning scattered, off-mission activity into a function that can be named, owned and improved. The report is not confused between the two senses; it simply has no reason to descend into the second, because its subject is the partnership, not the interior of each participant.

The distinction earns its keep, though, because the two senses invite different responses. "Well-equipped" and "lacking capacity," read as endpoints, invite the obvious move: help the lagging organization acquire capacity — resources, technology, training. Read instead as two points on a path of formation, they raise a prior question, and it is the one the endpoints quietly step over. How does an organization that "lacks capacity" come to know that what it lacks is a capability at all, rather than a nuisance absorbed at the edges? Until it knows that, offered resource has nothing to land on. There is not yet a thing to resource — which is only the assumption again, seen from the funding side.

Put the two senses side by side and the difference is small to state and large in its consequences. Capacity is something an organization has. Capability formation is something an organization does — usually without noticing that it is doing it. The first can be observed and measured from outside, which is why guidance can speak to it. The second happens, if it happens at all, on the inside, and mostly before there is anything an outsider could measure. A standard can see the state. It cannot easily see the becoming.

The missing layer

It helps to draw the thing, even crudely, because the crudeness is what exposes the assumption.

Here is how guidance of this kind is naturally read — not wrongly, just naturally:

Policy → Governance → Success

Policy sets the expectation. Governance — mandate, structure, ownership, oversight — turns the expectation into managed reality, and managed reality produces the outcome. It is a clean and mostly correct picture, and most standards, sensibly, travel along that arrow.

What the two papers force us to insert is a step the arrow skips:

Policy → Operational capability formation → Governance → Success

The claim is narrow, and we will keep it narrow. Governance can only govern a capability that already exists. You cannot assign an owner to a thing no one has yet recognized as a thing; you cannot set a metric for work no one is counting in the right unit; you cannot loop feedback into a process that has never been drawn. Before governance can take hold, the raw material — scattered activity, tacit knowledge, a shared mailbox, one experienced person — has to become a capability that governance can grip.

Most standards, quite reasonably, begin at governance and describe the managed state. The layer beneath it — formation, the crossing from undesigned activity to something worth governing — is the one we keep finding unlit. That unlit layer is what Reqport has become most interested in. Not because the lit layers are wrong, but because the light seems to start one step in from where the work begins.

What we are borrowing, and what we are only pointing at

Almost nothing in that diagram is new, and it would be a poor paper that pretended otherwise. The layer we are pointing at has been described, from several directions, by disciplines that long predate us. Our only move is to notice that they converge on it.

Enterprise architecture and capability mapping already insist that a capability is a designed object — something you can place on a map, give an owner, and hold distinct from the units that happen to perform it. Their method assumes the capability can be named; they say less about the moment before it has a name, when it is not yet on anyone's map to be mapped. Operating-model thinking works in the same register, and is strongest once there is a capability to model. Lean contributes the discipline of making work visible, and is, we think, closest of all to the formation layer, because in practice the first act of formation is almost always an act of seeing. ITIL supplies the distinction between performing a service and owning it, and the idea of continual improvement — both of which presume an owned service to begin with. Deming supplies a correction worth stating for anyone who has not met it: recurring problems usually come from the design of the system, not the effort or competence of the people working inside it — which is why formation is never really a matter of finding better staff. Economics supplies the externality argument of the first paper. And organizational theory has its own literature on capability emergence — on how routines coalesce, over time, into something an organization can be said to have.

We are not proposing to replace any of these, and we are wary of the trade in new management theories. If the paper has a contribution it is smaller and quieter: that a report as mature as the one that prompted us, read against these disciplines, seems to assume the formation layer is already behind the organizations it addresses — and that the assumption is so natural it is nearly invisible, which is exactly why it seems worth saying out loud.

How an organization discovers it has one

If there is a single idea in this paper we would ask a reader to carry off and test, it is this, and we offer it as a working hypothesis rather than a finding:

The properties are well covered everywhere — dedicated teams, secure exchange, measured outcomes, clear ownership, healthy feedback. What is strangely absent from the genre is the event before all of them: the moment an organization stops experiencing a body of recurring work as scattered nuisance and starts seeing it as one thing, a capability it has had all along without knowing. Recognition, in the sense the second paper meant, is not maturity. It is the door maturity has to come through, and standards describe the room, not the door.

There is a plainer way to put it, and it may be the most portable idea here:

By the time a standard addresses a capability, an organization has often had it for years — done daily, absorbed at the edges, never named. That is exactly what lets guidance assume it: the capability is genuinely there to be assumed. What is missing is not the capability. It is the recognition.

We keep meeting that gap in the field — always small, never in a document. Three observations, anonymized and unranked, offered as texture rather than proof.

A standard asks organizations to measure outcomes. In one, the report counted incoming emails. The people doing the work counted identifiers — a single email often carried a spreadsheet of them, each in practice its own request. The report said one. The work was fourteen.

The recommendation assumed a unit of work. The organization had not yet found what its unit was.

A standard asks organizations to maintain operational capacity. During one workshop, a whiteboard slowly filled with request types. Twenty minutes later the room fell quiet. No one had ever seen the capability drawn in one place before.

The whiteboard did not create the capability. It revealed one that had already formed, years earlier, unseen.

A standard asks organizations to dedicate resources. Ask the people who do this work why it is arranged the way it is, and in different organizations, unprompted, they give the same answer: this isn't really our core business.

Resources follow recognition. That sentence marks an organization that has not yet recognized — and a recommendation to dedicate resources passes straight over it.

Read together, the three point the same way. The recommendations of mature guidance are addressed to a capability after it has been recognized. And recognition — not resource, not will, not even governance — is the step we find missing most often.

The assumption, one level up

We have been treating the assumption as though it were about a single organization. But the report that prompted all this is not, in the end, about single organizations. It is about partnerships — many independent bodies sharing information and coordinating action. And that turns the assumption over and shows a second face.

When guidance of this kind says collaborate operationally, develop interoperability, participate in partnerships, it assumes, as before, that each organization has the internal capability to take part. But it assumes something more, and quieter: that there exists, between the organizations, a working capability to converge on shared practice — to hold common semantics, evolve shared workflows, improve together over time, and, where it makes sense, build shared infrastructure. The report does not describe how that between-organizations capability comes to exist, any more than it describes the internal one. It assumes it, in the same natural way, for the same good reason.

Here the fair objection arrives: this already exists. Point to the industry associations, the standards committees, the public–private partnerships the report itself catalogs, the banking-sector bodies and joint task forces. They are real, and we do not dispute them for a moment. But this is the same confusion the first two papers traced inside the organization, now standing one level up. Inside a firm, the presence of recurring work is mistaken for a managed capability. Across an ecosystem, the presence of a forum is mistaken for a capability to continuously improve shared operational practice. The two errors rhyme, and once you hear the rhyme it is hard to un-hear:

This is not a complaint about committees. Governance, standard-setting and representation are real and necessary functions, and the bodies that perform them are mostly doing what they were built to do. What is missing is a different function they were never designed to provide, and the clearest way to name it is by pointing at where it already exists. Modern engineering organizations have gotten very good at one specific thing: continuous integration, code review, retrospectives, pull requests, small increments, rapid feedback. None of these is a superior process in the abstract, and none became standard because someone designed a perfect one. They spread because they shorten the distance between someone noticing something and the practice changing to reflect it. Lean reached the same place from the factory floor and DevOps from the data centre; the lineage is long and it converges on a single idea — operational excellence comes from many short learning loops, not from occasional large redesigns. Cross-organizational work rarely has an equivalent. A practitioner's observation — a field that should exist, two authorities asking for the same thing in different shapes, a step that could vanish — usually has no path from noticing to shared, implemented, measured change. It travels, if it travels at all, through management layers and annual revisions: machinery built for consensus, not for learning.

Lean is the one to handle most carefully, because it does not actually stop at the factory wall — and this is the part usually forgotten. Toyota did not merely publish standards for its suppliers; it invested, continuously, in improving their operational practice alongside its own. Cross-boundary operational learning is not foreign to the tradition; it is one of its landmarks. So the question this paper is really circling is not whether such learning can cross organizational boundaries. It is the corresponding one, and it is a far better question than asking whether committees exist:

Where, that is, is the loop by which an observation made in one organization becomes an improved shared practice across all of them — when the participants are legally independent, when trust boundaries genuinely limit what can be shared, when the information is sensitive, when no one owns the end-to-end process, and when no participant has authority over the others? Toyota had leverage over its suppliers. Here, no one has leverage over anyone. That last condition is the crux, and we do not have its answer.

What only the ecosystem can build

Two smaller observations follow from the same shift.

The first is that we — and the field generally — tend to describe this work as bilateral: a requester on one side, a responder on the other, reaching an arrangement. That picture is rarely accurate. The challenge is consortium-wide. A given request type ought to look materially the same whoever issues it and whoever receives it, and that sameness is a property of an entire ecosystem converging, not of any two parties striking a deal. Bilateral fixes do not add up to a shared practice; convergence is its own capability, and it is the one we suspect is missing.

The second is that some capabilities cannot sensibly belong to either side. Picture a responder that receives a case reference and, rather than simply trusting the requester, can ask an authoritative service whether the case exists, whether it is active, whether this requester is authorized, and whether the legal basis holds. Inside a single organization, a shared service every component can query is an unremarkable piece of architecture. Across organizational boundaries it becomes institutionally hard enough that it is rarely even proposed — not because it is technically difficult but because no one owns the space it would occupy. The category is the point: some things are neither the requester's capability nor the responder's, but the ecosystem's — and the ecosystem is precisely the layer with no owner. (A kind of capability, not a product.)

The Catch-22

If the paper has a finding and not only a lens, it is here — and it took us longest to see, because it lives in the space between the two levels rather than in either one.

The first paper explained the internal capability's persistence as an equilibrium: orphaned and illegible, each condition holding the other in place. The ecosystem capability has a similar stubbornness one level up. But the longer we looked, the less it seemed like two equilibria side by side and the more like one that runs between the levels:

Weak internal capability → Weak contribution to shared practice → Weak ecosystem learning → Weak ecosystem capability → Weak support for internal capability → (back to the top)

An organization struggles to mature its internal capability because doing the work well depends on shared agreements only the ecosystem can realistically produce — a common shape for a request, an agreed semantics, a way to settle the ambiguous case. The ecosystem struggles to evolve shared practice because its member organizations have not made their own practice legible enough to contribute what convergence would require. Each layer is, in effect, waiting for the other to mature first. Weak internal capability starves the shared practice; weak shared practice starves the internal capability. The arrow closes.

This is more than co-evolution. Co-evolution would mean the two improve together. What we think we are looking at is stronger and less hopeful: a reinforcing equilibrium, of exactly the kind the first paper found inside the organization, now operating between organizations. Neither layer can get far ahead of the other; each depends on the other having matured first; and an equilibrium of that shape does not dissolve under effort or goodwill, because no individual party, acting reasonably, has a unilateral move that makes things much better. That, we now suspect, is the real answer to the question the trilogy has been circling from the start. The first paper asked why the capability was undesigned; the second, how to recognize it; and underneath both sat a harder one — why is it so unusually difficult to mature on purpose? Because neither half can mature alone, and each is quietly waiting for the other.

This is not an accusation. No one in the picture is irrational or negligent. An organization declining to race far ahead of its ecosystem is deciding sensibly; a forum operating by consensus rather than rapid iteration is doing the job it was built for. The difficulty is structural rather than moral — the more useful reading, and the more forgiving, and also the more sobering, because structural traps do not yield to trying harder. It may be the plainest explanation we have found for why a capability this real has sat, at both levels, undesigned for so long.

One refinement follows, and it changes the shape of any answer. The internal capability, in the first paper, was ownerless but ownable: the remedy was to name an owner and manage it. The ecosystem capability is not like that. It is not merely ownerless but largely unownable — no single participant can legitimately own the shared operational practice of an ecosystem it does not control, and it would be a category error to try. So the useful question is not the internal one enlarged — not who should own this? — but a genuinely different one: how does a capability mature when no participant can legitimately own it alone? We do not have the answer. We have become fairly sure it is the right question, and that it is not yet the one the field is asking.

A second question

If the paper is right, the consequence is not that standards should change. Guidance that tried to narrate the interior formation of every capability it assumes would be unreadable, and would be reaching below its proper altitude. The report is the right document at the right level. What might change is not the writing of guidance but the reading of it.

Most organizations read a standard by asking a single question:

What is this asking us to do?

It is the right question, and we would not displace it. We only want to propose a second one, held beside it:

What operational capability does this recommendation quietly assume we already have?

It is a small question. But we have found that once it is asked, the assumptions inside otherwise familiar documents become difficult to un-see — and that the distance between the capability the standard assumes and the capability an organization actually has is, in this domain, wider and less examined than the confident surface of most guidance would suggest. That distance is where we suspect the useful work is: not in disputing recommendations, which are sound, but in the layer underneath them, where scattered, off-mission, boundary-crossing work either becomes a capability an organization can own — or stays what it has been for decades, real and done and unseen.

And there is now a second version of that question, one storey up. When guidance asks us to collaborate, to interoperate, to partner, we can ask not only what internal capability it assumes, but also: what shared, cross-organizational capability does it assume already exists between us? The honest answer is often that we have a forum — and a forum, we have come to think, is not yet the thing being assumed.

We did not set out to read standards differently. But since reading the report we have not been able to read them in quite the same way. They increasingly seem to describe not only what organizations should do, but what they quietly assume organizations have already become — and, we now think, what they assume the space between those organizations has already built. Both assumptions deserve closer study than they have had — including from us.

There is a larger question beneath all of this, and we would rather leave it open than pretend to close it. Organizations have become good at improving the work inside their own walls. Far less is understood about the operational capability that lives between them — the sensitive work that crosses organizational trust boundaries, where the parties are independent, the information is guarded, and no one owns the whole. Authority requests are where that became visible to us, and not by accident: they expose the dynamics with unusual sharpness — an outside requester, a reluctant responder, a hard deadline, a shared practice no one ever convened. The same shape recurs wherever sensitive work crosses those boundaries — regulatory interaction, information sharing, fraud coordination, sanctions, incident response — and that recurrence, not some general theory of organizations, is the question we would rather leave open than close. We only want to leave it somewhere a reader can pick it up.

What remains open. This comes from one operational domain — sensitive requests crossing organizational boundaries — and how far it generalizes is untested. "Formation" may be several layers rather than one; recognition, formation and governance may braid together in ways a stack of arrows tidies away. The second storey — that the same capability is assumed, and missing, between organizations as well as inside them, and that the two levels hold each other in place — is the newest claim here and the least tested; it is a shape we keep meeting, not yet a result we can show. And a paper like this carries an obvious risk: a company that builds infrastructure for exactly this layer will be tempted to see it everywhere. We have leaned on borrowed theory and anonymized observation rather than conviction to guard against that; the reader should keep the incentive in view. If you have read guidance of this kind and noticed the same quiet assumption — or looked for it and found none — we would like to hear it.

About Reqport. Reqport studies — and builds infrastructure for — the operational layer where sensitive requests cross organizational boundaries: receiving, verifying, acting on, and accounting for requests from authorities and peer institutions. These Working Papers are part of that inquiry, published on Reqport Insights; they are written to be useful and to be corrected, not to sell. If you have a counterexample, we want it — you'll find us at reqport.com.

Working Paper series · part of an ongoing inquiry into the operational layer between policy and practice. Drafts are revised as the thinking changes; that they change is the point.

Erik Obitz

Solution Architect

Erik works on the technical side of Reqport. He came at it as a solutions architect and found a problem that turned out not to be a technical one at all — how organisations handle the sensitive requests that arrive from police, regulators and each other, and why that work so often lives in a shared mailbox and a few people's heads. He writes here to think it through in the open. Corrections welcome.

LinkedIn