Reusability and the Compounding Factory

1. Introduction

The subject of this paper is a regulated financial institution — a bank, an insurer or an asset manager — in the EU, the UK or Switzerland that is building an AI factory: the organisational and technical capability that delivers AI applications repeatedly from shared, governed parts. A production line is one product team’s delivery stream inside that factory. The reader I have in mind runs technology for such a firm.

The thesis is this. Shared assets do not compound because they are shared. They compound when three loops run on them. The amortisation loop spreads the asset’s fixed cost across consumers. The quality loop makes the asset better each time it is used. The evidence loop, which matters only in a regulated firm, turns each governed use into a record that makes the asset cheaper to trust. The loops run when five conditions hold together: the asset is discoverable at the moment of need, trusted by evidence, versioned with a governed upgrade path, owned and funded as a product, and fed back by its consumers.

AI coding agents change the economics on both sides. They reduce the cost of producing an asset that is fit for reuse, and they reduce the cost of copying to nothing. The same factory can therefore compound assets or compound liabilities, and what decides between the two is the governance of what goes into an agent’s context.

What is evidence and what is argument. Section 2 reports published sources and says who produced them. Section 3 is my argument. The evidence loop, the ranking of asset classes, the five-condition test and evidence-computed certification are design proposals and have not been tested in a controlled way. Section 4 turns the argument into actions. Section 5 states what the paper does not establish.

A note on two names. “DORA” in this paper means Regulation (EU) 2022/2554, the Digital Operational Resilience Act. The Google-owned DevOps Research and Assessment body of work, which shares the acronym, is called “the DORA research programme” throughout.

Terms. A catalogue is the firm’s inventory of shared assets, with their owners and versions. A bill of materials is the machine-readable list of the components a product is made of, with their versions. A recipe is the versioned, executable definition from which a component is built and configured. Foundation components are the building blocks nearly every application needs, such as identity integration, logging and document handling. A policy-as-code pack is a versioned set of machine-enforced rules applied by the platform to everything in its scope. The evidence schema is the single record format in which every governed action, by a person or an agent, is logged so that it can be queried across the estate. Standing context is a file kept in a repository or workspace that an agent reads at the start of every session, such as CLAUDE.md or AGENTS.md. A golden path is the sanctioned, pre-built way of building and running a class of application on the firm’s platform.

Scope. The paper begins after the sourcing decision. Whether a capability should be built, configured or consumed from a supplier is the subject of Working Paper 07 in this series, Build, Configure or Consume [17]. Nothing here re-opens that decision: a commodity capability that the firm should buy stays bought, however well an internal version might compound. The five-condition test applies to assets the firm has already decided to build or configure.

2. Background and evidence

2.1 Reuse economics before agents

Systematic software reuse was a measured discipline in the 1990s. Jeffrey Poulin’s Measuring Software Reuse devotes a chapter to “The Relative Costs of Developing with and for Reuse”, built on two coefficients: the relative cost of reuse, which is the cost of consuming a reusable component as a fraction of writing it fresh, and the relative cost of writing for reuse, which is the cost of producing a component for many consumers as a multiple of producing it for one [1]. The structure is what this paper relies on: the first coefficient is below one and the second is above one. I do not quote his default values, because nothing here depends on them. Whatever the exact values, they are measurements from the early 1990s and belong in a planning model only as history.

My reading of what followed, which is interpretation and not a finding of that literature, is that the two coefficients explain most reuse programmes that failed. The consumer’s saving lands on a different budget line from the producer’s premium. Nobody funds the premium, the component is never hardened, consumers stop trusting it, and reuse stops. It is a funding problem that is repeatedly diagnosed as a technology problem.

2.2 Platform engineering and discoverability

The platform-engineering movement addressed discoverability. Spotify described the golden path in August 2020 as “the ‘opinionated and supported’ path to ‘build something’”, with the supported tools surfaced in its internal developer portal, Backstage [2]. Backstage entered the CNCF Sandbox in September 2020 and was accepted as an incubating project on 15 March 2022, when the CNCF reported it “used by 100 publicly listed adopting companies” across industries that included financial services [3]. Skelton and Pais gave the organisational form its common vocabulary, in which a platform team serves the delivery teams that consume it [12]. Before agents, then, the state of the art was a platform team, a service catalogue, golden-path templates and product management applied to internal assets.

The DORA research programme’s 2025 announcement reports that “90% of organizations have adopted at least one platform” [7]. That is a survey figure about platforms of any kind. It does not say how many of those platforms carry a catalogue that anyone consumes.

2.3 Inner source and the feedback channel

The InnerSource Commons community documented how shared assets accept contributions from their consumers. Its pattern library includes the Trusted Committer pattern, which gives maintainers a way to recognise contributors from other teams and to scale their own ability to support a project; the pattern leaves the scope of the role to each project [4]. The community’s learning path is more specific about the role: “it is usually only the Trusted Committer who can ultimately accept and merge or reject a contribution”, and trusted committers “should prioritize onboarding and mentoring during pull requests” [5]. Inner source is the standing answer to the consumer who needs a change and would otherwise copy the asset and diverge from it.

2.4 Evidence from the agent era

The evidence is thin, and Working Paper 04 in this series, Technology Management and Agent Readiness [16], reviews it at more length than I do here. Three sources matter for reuse.

The DORA research programme’s 2025 report states that “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses” [6]. The accompanying announcement reports “a direct correlation between a high quality internal platform and an organization’s ability to unlock the value of AI” and puts the consequence in one sentence: “The greatest return comes not from the AI tools themselves, but from a strategic focus on the quality of internal platforms, the clarity of workflows, and the alignment of teams” [7]. These are survey associations from nearly 5,000 respondents, not controlled effects.

GitClear’s analysis of 211 million changed lines written between January 2020 and December 2024 reports lines classified as copy/pasted rising from 8.3% to 12.3% of changed lines between 2021 and 2024, and changed lines associated with refactoring falling from 25% to under 10% over the same period [8]. This is one vendor’s data set. It shows the two movements coinciding with the adoption of AI assistants; it does not show that one caused the other.

METR’s randomised trial of 16 experienced open-source developers on 246 issues found that, with the AI tools of early 2025, they took 19% longer while believing afterwards that they had been 20% faster [9]. METR now marks that result as out of date, and describes the data from its February 2026 follow-up as “an unreliable signal” of the current effect [10]. I use it for one purpose only: it is a warning against inferring a productivity gain from the shape of a task.

2.5 The gap

As of November 2026 I have found no published measurement of reuse in agent-driven estates: which shared assets agents consume, at what rate and with what drift. I also looked for a platform-engineering survey that reports catalogue consumption, as opposed to platform adoption, and did not find one I could cite. An absence of this kind cannot be proven by search; the statement is a report of what a targeted search found. Everything in section 3 about how assets compound is therefore mechanism, not measurement.

3. Analysis

Everything in this section is argument unless a source is cited.

3.1 What compounding means

“Reuse compounds” is usually a slogan. It can be stated as a mechanism, and the mechanism can be checked asset by asset. An asset compounds when three loops run on it at once.

1. The amortisation loop. Each new consumer spreads the asset’s fixed cost thinner. This is the weak loop. It is the one classical reuse economics describes, it is linear, and it saturates.
2. The quality loop. Each use makes the asset better. Usage telemetry shows defects and gaps, incidents become regression tests, and consumers contribute fixes through an inner-source channel. This loop separates a living asset from a published one.
3. The evidence loop. In a regulated factory, each use of a governed asset emits a record in the firm’s evidence schema. The proposal is that these records accumulate into demonstrated trust: an asset with a long, queryable history of clean scans, passing contract tests and attributed incidents should cost less to certify at its next version, and a product that consumes it should cost less to assure. Cheaper certification and assurance would in turn raise adoption.

The third loop is the part of this paper I regard as new, and it is a hypothesis. I have not found it described in the platform-engineering sources cited here, which were written for firms that do not carry a regulated firm’s assurance cost. I have no measurement that certification cost falls as evidence accumulates, and whether a risk function would accept computed evidence in place of attestation is an open question that section 5 returns to.

An asset with only the first loop is useful. An asset with the first two improves. An asset with all three is the one whose value per consumer rises while its cost per consumer falls. For the portfolio this means that production lines sharing such assets are no longer independent cost centres: the twelfth line inherits the incident-derived tests of the first eleven before it ships anything.

3.2 Asset classes, ranked by how strongly they compound

Not everything the factory builds compounds equally. The ranking below is my judgement, derived from asking how strongly each of the three loops runs on each class. It is not measured. In my observation it is close to the reverse of the order in which firms usually spend.

Tier 1 — schema and policy. The evidence schema and telemetry conventions compound through network effect. Every production line that emits in the one format makes every estate-wide query cheaper, and the stock of queries — answers to a supervisor’s questions, incident correlations, management dashboards — is inherited whole by each new line. Policy-as-code packs behave the same way, with one further property: a control implemented once at organisation-wide scope is enforced on every present and future workload in that scope, including workloads that do not exist yet. A policy pack is the only asset class whose consumer count grows without any consumer doing anything. When a regulatory interpretation changes, the change is made once and the estate inherits it. Schemas and policies also carry no runtime availability obligation of their own, because the platform enforces them.

Tier 2 — running shared services. A document-handling service, a calculation service, the identity integration: one implementation, many callers. Reuse comes in two forms. In code reuse the source is shared and each consumer runs its own copy. In capability reuse one running service is called by all its consumers, so the copies cannot drift apart. Capability reuse runs the first two loops strongly and carries real costs: an availability commitment, contract versioning and an obligation to operate the service. Its compounding is bounded by contract discipline. Hyrum’s Law states that “with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody” [11]. A heavily reused service therefore becomes harder to change as it compounds, and the price is paid in versioning rigour.

Tier 3 — recipes, foundation components and templates. These compound through composition. Improve the identity recipe once and every product that is built from it inherits the improvement at its next build. That last clause is the tier’s weakness. Template-class assets propagate when consumers are rebuilt, not continuously, so their rate of compounding is set by the factory’s ability to upgrade: to raise every consumer to the current version of what it was built from. A factory that can create from a template but cannot upgrade what it created holds recipes that compound for a while and then start producing the next legacy estate.

Tier 4 — assets of the agent era. Evaluation harnesses, prompt libraries, agent definitions, tool servers (for example servers that expose tools to agents over the Model Context Protocol) and standing-context files are usually treated as scattered configuration. They should be catalogue entries with bills of materials, recipes, versions and owners like any other component. An agent definition that is on no bill of materials is a component nobody governs.

The shared evaluation harness deserves separate mention. When each production line’s incidents, near-misses and review findings are distilled into evaluation cases that every agent workspace runs before a change is merged, the factory has an asset whose quality loop is fed by failure, which is the one input an estate produces reliably and without being asked. One line’s failure protects the others. I present this as a mechanism the factory should own. It does not make verification the factory’s purpose.

Standing-context files are the odd member of the tier. They are the means by which every other asset reaches an agent (section 3.3), and they are assets themselves, with the staleness problem described in section 3.8.

Tier 5 — shared code libraries. The classical unit of reuse is, in my judgement, the weakest compounder in the agent era. Every consumer holds its own copy, copies drift, and an agent can regenerate a small utility faster than it can evaluate whether the shared one fits. Shared libraries should be a deliberate exception, chosen where a running service would be the wrong shape, and not the material the catalogue is built from.

3.3 The five conditions

Many shared-services programmes produced well-built assets that nobody used. What separates the asset that compounded from the one that decayed is rarely the code. It is whether five conditions held. Each has a form that predates agents and a stricter form now.

Discoverable at the moment of need. Before agents, this meant the asset was one query away in a catalogue that developers opened. That is what developer portals are for. The catalogue is still necessary and it is no longer sufficient, because the marginal consumer is an agent, and an agent does not browse. An asset is discoverable to an agent only if it is present in the standing context the agent reads before it acts, or reachable through a tool the workspace exposes. An agent whose context says “the firm has a document service; use it” extends the foundation. An agent whose context is silent writes a plausible rival. For agents, discoverability is an injection problem, not a search problem. The factory has to compile the catalogue into context, per workspace and per product type, when the workspace is provisioned. A catalogue that people can search and agents never see will produce a fifth implementation of file upload next to the four the firm already has, and it will do so quickly.

Trusted by evidence. Before agents, trust meant certification by committee: a central body approved components slowly, and the approval decayed without anyone noticing. Because every governed asset already emits records in the evidence schema, a certification tier can be computed instead of granted. I propose four tiers — sanctioned, certified, contributed and quarantined — derived from facts such as whether scans are current, contract tests pass, the asset has consumers in production, incidents have been attributed to it and its owner responds. People decide the criteria. They do not work the queue.

The corollary is the point I would most like a reader to take away. An agent consumes what its context offers with none of the scepticism a senior engineer brings to an old wiki page. An asset whose certification cannot be evidenced should therefore not be in the sanctioned context at all. Putting an asset into agent context is a supply-chain decision, of the same kind as admitting a third-party dependency, and it should be controlled the same way: only evidence-certified assets are admitted, the pipeline that compiles catalogue into context has a named owner, and every change to what it injects leaves an audit trail.

Versioned, with a governed upgrade path. Semantic versioning and a deprecation policy were the earlier form. Two things sharpen. First, the consumer of a version change is often an agent, so upgrade can be industrialised: the factory dispatches agents to raise the pinned versions across the estate, run each product’s tests and open pull requests for review by each agent’s named human owner. This turns upgrade from the most neglected factory function into what I expect to be one of its cheapest, and section 3.2 explains why it sets the compounding rate of tier 3. Second, Hyrum’s Law bites harder, because agents generate consumers of an interface faster than people did, so undocumented behaviour acquires dependants faster. Contract tests, which are the machine-checkable form of the interface’s promise, become the version boundary that holds.

Owned and funded as a product. This condition is unchanged in form: a named owner, a roadmap and a budget line that belongs to the asset. An asset funded as a levy on passing feature projects has no owner on the day the project closes. What changes is the arithmetic of the funding conversation, which section 3.4 takes up.

Fed back by its consumers. The earlier form is inner source: visible code, contribution guidelines and trusted committers who hold the merge decision [4][5]. Two things are added. Consumers’ agents can propose changes to shared assets, so that a fix found in one production line’s workspace becomes a pull request against the shared component, reviewed by its human trusted committer, tested by its contract suite and inherited by every other line. And the channel carries a second kind of contribution: the evaluation case. The most valuable thing a consuming line can send upstream is often not code but the failure it has just had, expressed as a test. A factory that routes incident findings into the shared evaluation harness has a feedback channel that works even when nobody contributes code. Mandated reuse without such a channel produces resentment: teams consume the asset under protest, copy it quietly at the first gap, and the catalogue’s consumption figures stop meaning anything.

3.4 The economics: agents move both ends of the reuse trade

The classical trade is the one in section 2.1. Consuming a reusable asset costs a fraction of building it fresh, and producing an asset for reuse costs more than producing it for one consumer, because it has to be generalised, hardened, documented, versioned and supported [1]. The premium was paid by the team with the least incentive to pay it, for beneficiaries it never met.

Agents change both coefficients.

The production premium should fall. The content of the premium — extracting the general case, writing documentation, building contract tests, keeping backwards compatibility, triaging consumer issues — is largely bounded, well-specified work of the kind agents do under review. If that holds, a platform team of unchanged size can own more catalogue than before, and the funding argument that reuse programmes usually lost becomes winnable with smaller numbers. This is my expectation. It is not a measurement, and it is the weakest link in the paper. It infers from the shape of a task to an agent’s suitability for it, which is the inference METR’s trial warns against [9][10]. I know of no published measurement that isolates agent productivity on hardening work.

The discipline of consumption falls too. Copying was always cheaper than integrating in the short run. Agents make it free and immediate. GitClear’s figures on copy/pasted lines are consistent with that at the level of code [8]. The general point is that every asset class now has a counterfeit that costs nothing to make: the improvised policy check, the private prompt library, the fifth file upload.

The two movements do not cancel, because they are captured in different places. The lower premium is captured by whoever runs a platform team with agents. The free copying is suffered by whoever fails to govern agent context. Both are settled by the same investment: the pipeline that compiles the catalogue into context, together with the policy gates that make the sanctioned asset the default and the counterfeit the exception. In my own words, and not those of the DORA research programme, the internal platform is the distribution layer: it decides whether AI amplifies the firm’s strengths or its sprawl. That reading rests on the programme’s amplifier finding and on its reported association between platform quality and the value obtained from AI [6][7].

3.5 Duplication: measure it, and keep extraction a judgement

The rule of three says to tolerate a duplication once and to abstract when the same thing appears a third time. It is usually cited from Martin Fowler’s Refactoring [13]. The rule was calibrated to human speed, when the third occurrence took months to arrive and premature abstraction was the larger risk.

At agent speed the third occurrence can arrive in the same week as the second, and each copy is cheaper to make than to find. The tempting conclusion is a rule of two: extract at the second occurrence. I do not adopt it. A wrong abstraction now propagates at agent speed as well, through every line that composes it, and section 3.7 explains why a shared asset is hard to change once it has consumers. The cost of extracting too early has risen along with the cost of extracting too late.

What has changed is which resource is scarce. Generation is cheap and detection is not. The factory should therefore run duplication detection across the estate as standing telemetry, with candidates for extraction reported to the platform team’s backlog automatically, in place of the occasional manual count in a spreadsheet. The decision to extract stays with a person who can see the telemetry and judge whether the occurrences are the same thing or merely look alike.

3.6 Network effects between production lines

A firm with one production line gets no reuse value, by construction. With several lines sharing a catalogue of compounding assets, each new line inherits the accumulated assets at low marginal cost, contributes its usage, failures and fixes to the quality and evidence loops of the others, and enlarges the base over which the next asset’s production premium is spread. The benefit to each line grows with the number of other lines, which is what a network effect is.

I put no exponent on this and claim no particular curve, because nothing has been measured. The claim I will defend is narrower. Compounding operates on the region where the lines’ bills of materials overlap, and stops where they do not. Two workflow applications built on the same foundation share a large part of their composition by reference. A data-science pipeline shares less. The effect is strong where the composition overlaps and absent elsewhere, and a factory serving a single product is for that reason a poor investment.

This bears on where a firm should start. One position holds that the data platform must come first, on the ground that applications which cannot use each other’s data share less than their infrastructure suggests. The observation about overlap is correct, and it is a useful check on any business case that counts shared infrastructure as if it were shared substance. My position is nevertheless factory first. The assets that compound hardest, the evidence schema and the policy packs, are needed by every line whatever data it uses, and by a data platform as much as by an application. A firm that waits for its data estate to be unified before building them forgoes the tier that costs least and pays back soonest.

3.7 Concentration: the price of compounding

Compounding assets concentrate risk in proportion to their leverage. One document service is one place where a vulnerability reaches the whole estate. One evaluation harness is one place where a blind spot is copied into every review. One evidence schema is one migration that touches everything; the asset that compounds hardest is the one the firm will be able to change least, and it should be versioned on that assumption from the start. A compounding catalogue also concentrates resistance to change: by Hyrum’s Law, the platform team’s freedom shrinks as its consumer count grows [11].

The factory’s answer is the discipline it applies elsewhere: contracts, versions, upgrade automation and evidence. But the trade should be stated plainly. A compounding asset is a critical dependency the firm has chosen to create. The benefit is real and so is the price, and a business case that shows only the first is not credible.

The regulatory position under DORA, as of November 2026. I state this narrowly. DORA has applied since 17 January 2025. Article 8(1) requires financial entities to “identify, classify and adequately document” their ICT-supported business functions, the information assets and ICT assets supporting them, and their dependencies [14]. That provision draws no distinction between an asset bought from a supplier and one built in-house. A shared internal service that supports a critical or important function, as Article 3(22) defines the term, therefore belongs in that identification and dependency mapping like anything else the function relies on.

The register of information is a different instrument. It concerns, in the words of the implementing regulation that sets its templates, “all contractual arrangements on the use of ICT services provided by information and communication technology (ICT) third-party service providers referred to in Article 28(3)” of DORA, and the same regulation treats ICT intra-group service providers as within that population [15]. On my reading, a platform team inside the same legal entity as its consumers is not a provider under a contractual arrangement and is outside the register, while a group service company that supplies the platform to regulated entities of the group may be inside it. Which of the two describes a given firm is a question of legal structure for counsel.

I am not aware of a provision of DORA that requires a concentration analysis of internal shared assets as such; the regulation’s concentration provisions are framed around third-party providers. That a supervisor will nonetheless expect a firm to know which critical or important functions depend on one internal platform, and what happens when it fails, is my expectation and not a cited requirement. Being internal does not remove a dependency from the scope of ICT risk management. UK and Swiss parallels for dependency mapping are set out in Working Paper 04 [16].

On cloud vendors. Nothing in this paper depends on one cloud. Each of the large providers offers policy-as-code at organisation scope, service catalogues and pipeline services in which these assets can be expressed. The firm should own the catalogue model and the evidence schema, and treat the vendor services as implementations.

3.8 How compounding fails

Five failures recur. Each is made worse by agents.

1. The shared-library graveyard. Assets are published and not consumed, because the programme counted components built instead of components used. Agents will not consume what is not in their context, so a graveyard can now be built faster than before, complete with good documentation that nobody and nothing reads.
2. Mandated reuse without a channel. Consumption is ordered and copies are made in private. The private copy is now one prompt away, and it will be plausible, will pass its own tests and will differ in small ways.
3. The certification bottleneck. A central board must approve every asset and every version, the catalogue becomes a queue, and teams go round it. The proposed answer is evidence-computed certification (section 3.3), with people setting the criteria.
4. The platform of everything. The platform team generalises ahead of demand and pays the production premium with nothing to spread it over. One signal, offered as an illustration and not as a tested threshold, is a catalogue entry with no production consumer two quarters after publication. The remedy is to let duplication observed in the estate, as in section 3.5, justify the next shared component.
5. The stale asset. A recipe, prompt library or context file that was true last spring. A stale shared asset is worse than none, because agents consume it with confidence and at scale, and one stale component propagates through every line that composes it. Working Paper 04 makes the same point about golden paths and their agent-readable form [16]. The catalogue needs the same versioned, queryable history as the product specifications it serves.

The common root is treating reuse as a virtue to be encouraged and not as a system to be run. Every corrective named above is a mechanism the factory already owns for its products: context injection at provisioning, policy gates, evidence-computed trust, duplication telemetry and upgrade automation. The features a factory must build for compounding are those mechanisms, applied to its own assets.

4. Recommendations

1. Build in the order in which assets compound. Evidence schema and policy packs first, then running shared services, then recipes and templates. Shared code libraries come last and by exception.
2. Apply the five-condition test to every catalogue entry. Discoverable at the moment of need; trusted by evidence; versioned with a governed upgrade path; owned and funded as a product; fed back by its consumers. Record which conditions fail. An entry that fails one is a candidate for one of the failures in section 3.8.
3. Compile the catalogue into agent context at provisioning. Treat that pipeline as a control: evidence-certified assets only, a named owner, an audit trail for every change to what is injected.
4. Compute certification tiers from evidence, and agree the criteria with the second line of defence before relying on them.
5. Give agent-era assets the same standing as any component. Prompt libraries, agent definitions, tool servers and standing-context files carry bills of materials, versions, owners and tiers.
6. Establish one shared evaluation harness and route incident and review findings into it as test cases.
7. Run upgrade as an industrial function. Agents raise pinned versions across the estate and open pull requests; named human owners review them.
8. Operate the catalogue as inner source, with human trusted committers and a contribution lane for consumers’ agents.
9. Run duplication detection as telemetry. Do not adopt an automatic extraction trigger.
10. Measure consumption, not construction. Count active consumers per asset and time to first consumption for each new one, with the rate of copied code as the counter-measure. As a headline measure I propose inherited share: the fraction of a shipped product’s bill of materials that was inherited by reference and not written for that product, tracked per production line.
11. Price concentration beside the benefit in every business case, and map shared internal assets that support critical or important functions in the firm’s dependency documentation.

5. Limitations

• The mechanism is argument. The three loops, the tier ranking, the five-condition test and the build order are proposals. None has been tested in a controlled comparison, and the ranking is my judgement.
• No measurement of reuse in agent-driven estates was found, and no survey of catalogue consumption that I could cite. The paper cannot say which assets agents in fact consume, or how fast shared assets drift.
• The fall in the production premium is an expectation. It infers from task shape to agent suitability, and METR’s work is a warning against that inference. It has not been tested against the experience of a platform team that has run agents on catalogue hardening. That question is left open.
• The evidence loop is a hypothesis. I have no data showing that accumulated evidence lowers certification or assurance cost. Whether a second-line risk function would accept evidence-computed certification in place of human attestation is unknown to me and is left open; the proposal should not be relied on before that conversation has taken place.
• Poulin’s coefficients are not quoted. The primary text could not be opened, so the paper relies only on the direction of the two coefficients. The figures, once confirmed, are measurements from the early 1990s and are not planning numbers.
• The network-effect claim has no shape. I assert that benefit grows with the number of lines where compositions overlap. I do not know the curve, and the size of the overlap in a real estate is an empirical matter this paper does not settle.
• Factory first is a position. The counter-position, that the data platform should come first, is stated in section 3.6 and is not refuted by evidence.
• Much of the cited evidence is weak in known ways. The DORA research programme reports survey associations. GitClear is one vendor’s data set and shows coincidence, not cause. METR marks its 2025 result as out of date and its 2026 data as unreliable.
• Concentration risk is priced qualitatively. The paper gives no method for quantifying it.
• The regulatory statements are a technologist’s reading, timestamped November 2026, and are not legal advice. Whether an internal platform falls inside the register of information depends on the firm’s legal structure. The UK and Swiss regimes are not analysed here.
• Verification. Source checks for this version were carried out by an AI research agent on 10 November 2026. That is not peer review, and the paper has not had a legal or practitioner review. The agent opened the web sources listed below. It could not open the text of Regulation (EU) 2022/2554 on EUR-Lex on that date: the Article 3(22) and Article 8(1) statements repeat what Working Paper 04 records from its own reading the same day, and Article 28(3) is cited only as the implementing regulation’s recitals describe it. The three books in the list were identified from publisher or author pages; their text was not opened, which is the reason for the two markers in the body.

References

All web sources accessed 10 November 2026.

1. J. S. Poulin, Measuring Software Reuse: Principles, Practices, and Economic Models, Addison-Wesley, 1997 (publisher’s listing dated 22 November 1996), chapter 3, “The Relative Costs of Developing with and for Reuse”. Table of contents at https://www.informit.com/store/measuring-software-reuse-principles-practices-and-economic-9780201634136
2. G. Niemen, “How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem”, Spotify Engineering, 17 August 2020. https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem
3. Cloud Native Computing Foundation, “Backstage project joins the CNCF Incubator”, 15 March 2022, https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/ ; and “Backstage” project page, https://www.cncf.io/projects/backstage/
4. InnerSource Commons, InnerSource Patterns, “Trusted Committer” (status: Structured). https://patterns.innersourcecommons.org/p/trusted-committer ; source at https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/trusted-committer.md
5. InnerSource Commons, “Learning Path – Trusted Committer”. https://innersourcecommons.org/learn/learning-path/trusted-committer/
6. DORA research programme (Google), State of AI-assisted Software Development 2025. https://dora.dev/research/2025/dora-report/
7. N. Harvey and D. DeBellis, “Announcing the 2025 DORA Report”, Google Cloud Blog, 23 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
8. GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”. https://www.gitclear.com/ai_assistant_code_quality_2025_research
9. METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
10. METR, “We are Changing our Developer Productivity Experiment Design”, 24 February 2026. https://metr.org/blog/2026-02-24-uplift-update/
11. H. Wright, “Hyrum’s Law”. https://www.hyrumslaw.com/
12. M. Skelton and M. Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution Press, 2019. Book page at https://teamtopologies.com/book
13. M. Fowler, with K. Beck, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1st edition 1999, 2nd edition 2018. Book page at https://martinfowler.com/books/refactoring.html
14. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1 — Articles 3(22), 8(1), 28(3) and 64. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554
15. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to standard templates for the register of information, OJ L, 2024/2956, 2.12.2024 — recitals 1 and 5 and Article 1. ELI: http://data.europa.eu/eli/reg_impl/2024/2956/oj ; read in the Official Journal PDF hosted by the European Banking Authority.
16. M. Parente, Technology Management and Agent Readiness, DEIXEI Research Series, Working Paper 04, November 2026.
17. M. Parente, Build, Configure or Consume, DEIXEI Research Series, Working Paper 07, November 2026.