Make Copying Irrational: Screens Reveal the Answer, Not the Evaluation Function

If a partner can rebuild your product from the screens, stay necessary by transferring operation of today’s offer — not by building a leash — while remaining the rational path for evolution.

Scott Farrell · LeverageAI · August 2026

Here is the fear, stated the way it arrives in a working session. You install the first product with a partner consultancy. They see the screens. They watch the workflow. Their better people start asking whether they could rebuild it. Then they notice five more friction surfaces in their book of work — and the quiet question is whether they need you for any of them.

That fear is rational. Modern coding agents make the broad visible shape of an application cheaper to approximate every quarter. Upload, extract, compare, decide, report: a capable firm can reproduce the outline of that loop. “Badly” can still be commercially adequate for a while. You cannot build a strategy that assumes they will fail at imitation.

The usual answers are both wrong.

The first wrong answer is to treat the application as the asset and sell it as a finished project: here is the code, pay the fee, you own it. That prices the shell and gives away the system that made the commercial promise safe to sell.

The second wrong answer is to stay indispensable to day-to-day operation — to design a product the partner cannot run without you. That fails your own forward-deployed doctrine. A buyer who cannot run, extend and audit what they paid for within a reasonable window did not buy an asset. They bought a leash.

Do not remain indispensable to operating the offer. Remain valuable to evolving the practice.

This article is a commercial design for that sentence. The specimen is real and limited: FDE BI and the Data Readiness Review as the first productised offer inside a partner-consultancy relationship. Treat everything that follows as n=1 — a defensible architecture you can negotiate from, not a portfolio study with renewal rates. Where I name fee components, I mean structure; I do not invent dollar magnitudes the source material does not have.

Software is a weak moat. That is not the whole problem.

Frontier capability is symmetric. Competitors rent the same models, the same agent frameworks, the same cloud primitives. Architecture sketches travel. Interfaces travel. What does not travel easily is the year of discrimination that made one design safe to promote and another design a support disaster.

That memory argument is already minted. This piece does not re-teach it. It extends it into a deliberate transfer strategy: let the partner become competent at operating today’s promoted answer while you remain the economically rational way to evolve the evaluation function, the harness and the next commercial units.

The market language is moving the same way. In AWS’s own Partner Network announcement of Partner-Led Forward Deployed Engineering, engagements are described as building a reusable delivery harness the partner owns permanently — evaluation frameworks, context graph, domain patterns — with delivery IP staying with the partner and systems structured for self-sufficiency rather than ongoing dependency.¹ That is not our fee model. It is public corroboration that “hostage as moat” is no longer a respectable industrial story.

So the question tightens. If they can copy the screens, and if permanent operating dependence is a product failure, how do you stay commercially necessary without cosplay exclusivity?

Screens reveal the promoted answer, not the evaluation function

Someone viewing FDE BI can see what survived: the chosen workflow, the visible findings surface, the accepted UI, the current extractor outputs, the report shape, pieces of the architecture. That is the promoted answer. It is also what a motivated team with agents will try to rebuild first.

What they do not see — and what does not travel with a screen recording — is the machinery that made promotion meaningful:

• rejected project shapes that looked plausible and failed economically;
• failed architectural variants and the reason one abstraction was refused;
• privacy boundaries and sensor outputs found unsafe after use;
• hidden evaluation cases that only appear under real engagement load;
• which client exception stayed local and which pattern was reusable;
• which promotion created too much support burden;
• which future trigger reopens a design that currently looks finished.

A copyist inherits the answer you ship. They do not automatically inherit the rejection history and evaluation function that made shipping that answer rational. That is why the field-pattern ledger matters in the parent discovery doctrine: context, value delivered, failure shape, invariant versus local variation, receipts, ownership, support burden, decision and revisit trigger — then post-promotion measures that test whether the reusable claim actually reduced cycle time, reused without forks, lowered escalations and stayed supportable.

You can reverse-engineer a workflow diagram from a UI. You cannot reverse-engineer a year of “we tried that shape and it created three support classes we refuse to reintroduce” without living the year or buying access to the maintained ledger and harness.

Walk that distinction on the specimen. A partner watching a Data Readiness engagement can see findings appear, decisions get dispositioned, and a scope pack compile. What they cannot see from the glass is why a particular sensor was refused for one source class; why two findings that look similar were routed to different authority; why a model interpretation was kept out of the commercially issuable set until a human accepted it; why one “obvious” abstraction was rejected because it forked under real estates. Those are evaluation-function residues. They are expensive to rediscover and cheap to inherit if the relationship is designed to keep them compounding on the licensed path.

This is also why “they can steal the code, not the year” is the right parent organ and the wrong whole article. The memory moat explains what does not travel. This piece is about what you do commercially once you accept that fact: transfer the promoted answer’s operation, keep the evaluation function under a maintained relationship, and stop pretending UI secrecy is a strategy.

The anti-dependency test cuts both ways

Your commercial objective should not be: the partner can never deliver the Data Readiness Review without you. That would make you the next bottleneck and contradict the Practice OS you claim to install.

The better objective is sharper:

The partner becomes capable of delivering the current product. You remain the fastest, safest and most credible way to improve the product, govern its evolution and create the next five.

Engagement one can still look like heroics. Engagement two is the honest test: can ordinary partner staff lead more of the work because shared machinery improved — sensors, evals, runbooks, claim rules — rather than because the same specialist carried everything again? If engagement two still requires the founder to be the runtime, you sold a project, not a practice.

That is transfer. Transfer is not charity. It is how you avoid building a product that fails the buyer’s six-month test and how you free your scarce time for the layers of work that actually differentiate you. The partner’s interest in transfer is obvious: they cannot productise what only you can operate. Your interest is less obvious and more important: if you remain the execution runtime, you never get paid for the factory, and every next offer is still your calendar. The anti-dependency test is not only buyer protection. It is creator protection against becoming a high-status bottleneck.

When transfer is real, the commercial conversation changes. You stop arguing about whether they are “allowed” to understand the product. You start arguing about which rungs of work are still worth buying from you after they can run the ordinary cases. That is a healthier dependency — and one a sophisticated partner will actually renew.

The five-level relevance ladder

Relevance should move upward as the partner learns. If it does not, either you failed to transfer or you failed to keep inventing. The ladder is the design instrument.

The progression is not a polite org chart. It is the commercial spine:

That is not being cut out. That is moving from project labour to practice infrastructure. The weak role is “developer of the readiness app.” The better role is architect and maintainer of the partner’s AI-native productised-services capability — measured by new offers launched, unpaid proposal effort removed, downstream margin, time to the next offer, share of ordinary cases delivered by partner staff, and reusable field learning promoted safely.

The partner may copy the first noun. Your advantage is the ability to keep producing the verbs: friction → commercial redesign → bounded product → safe perception and cognition → instrumented economics → next product. That loop is the foundry posture already argued for AI-native consultancies; here it is the reason the creator stays on the ladder after operation transfers.

Copy-path costs versus partner-path benefits

The partner will compare two futures. Your job is to make the second superior in value, speed and risk — not merely illegal under a clause nobody wants to litigate.

Contracts help. They are the backstop, not the moat. The stronger defence is that partnership creates more economic value than bypassing it saves. If the partner path is slow, closed, or priced as permanent bondage, a rational firm will try to copy. If the partner path is the quickest way to run today’s offer and invent tomorrow’s, copying becomes the expensive distraction.

Notice what you are not asking them to believe. You are not asking them to believe reverse engineering is impossible. You are asking them to price the year they do not have, the support classes they have not yet discovered, and the next five offers they will not invent while their best people rebuild a facsimile of the first.

Make the comparison legible inside the partner firm. Put both paths on one page in the commercial discussion: rebuild cost in senior hours, time-to-market for offer two and three, residual support risk, and the opportunity cost of taking their strongest delivery people off accounts. Against that, put licence + update cadence + escalation for novelty + co-creation of the next offer. If you cannot win that spreadsheet without a threat clause, the product relationship is under-designed. Fix the economics before you tighten the contract language.

There is a second failure mode on the partner path: pricing operation forever. If every ordinary engagement still requires your hands, the partner will correctly conclude they bought labour, not capability — and the copy path starts looking like liberation. Transfer of level-1 and progressive level-2 work is what keeps the partner path rational for them. Evolution and invention fees are what keep it rational for you.

Three-kernel ownership as contract architecture

The clean ownership split already exists in the Practice OS as three territories. Reuse it as the commercial map; do not collapse three obligations into one “we jointly own everything” clause.

The value is the runtime join, not the transfer of every asset into one party’s ownership. The partner does not need ownership of your entire kernel to use a licensed release against its accounts. You do not need ownership of their accounts, delivery experience or client outputs.

The partner owns its territory. You own the map of the new country and the machinery for entering it.

Promotion into the capability kernel still needs protocol: capture in the engagement record first; classify; de-identify; abstract to a failure shape or design rule; verify transferability; human taste gate; leave the client a usable record. Automatic climb of client material is a confidentiality incident with a calendar invite from Legal, not compounding.

That protocol is also part of why a screen copy fails as a long-term strategy. A facsimile interface does not include a governed promotion membrane. Without it, every clever local fix either stays trapped in one engagement or leaks unsafely into the next. The partner path should make safe write-back easier than either of those failure modes — which is another way of saying the relationship is selling compounding, not just a UI.

Commercially, that map answers the dangerous transaction. Do not sell: “here is the application; pay a project fee; you now own it.” Sell something closer to: install and operate an AI-native offer-creation capability inside the partner firm, beginning with Data Readiness as the first proven product. FDE BI is the first specimen and revenue product. It is not the full commercial boundary.

A worked fee structure (components, not invented numbers)

Precise amounts require negotiation. The components should track the ladder, not a vague “support retainer.”

Four stages make the fees land as a programme rather than a pile of invoices:

1. Launch the first offer — product definition, commercial lane, co-delivery, instrumentation.
2. Prove transfer — co-deliver engagement one; promote safe reusable learning; run engagement two with greater partner leadership.
3. Build the offer portfolio — regular cadence of friction mapping, candidate ranking, design, launch, ledger write-back.
4. Operate the capability kernel — versions, eval harnesses, design authority, certification, cross-client promotion gates.

Add an explicit buyout or broader field-of-use option if the partner eventually wants deeper ownership of some layer. A clear, expensive but fair buyout path is better than pretending permanent exclusivity will hold forever. It gives the partner strategic certainty and correctly prices the acquisition of future rights rather than mere use of the current release. Buyout is a feature of adult commercial design, not a confession that the relationship failed.

How the pieces interact in a real year looks like this. The installation fee covers the first product landing and the first transfer attempt. The annual licence keeps the evaluation harness, sensor library and doctrine current while the partner’s staff run ordinary cases. Per-engagement fees keep the relationship aligned with volume without forcing you into every delivery room. When the firm wants a CFO-facing or operations-facing cousin of the readiness offer, that is a new-offer build — a separate commercial unit, not “more of the same support.” When something novel appears that no fossil covers, design-authority hours are the priced escalation, not an unlimited chat channel. Certification makes the transfer claim auditable: people pass against production evidence, or they do not.

If the partner later wants exclusive field-of-use in a territory, or ownership of a vessel layer that today sits in the licensed kernel, the buyout conversation has a shape: which layer, which rights, which ongoing licence remains for updates they still want, and what price correctly compensates the year of discrimination already embedded. Without that door, a sophisticated partner treats “forever exclusive” as fiction and plans the copy path quietly. With the door, the conversation stays commercial.

Contract checklist (not legal advice)

A properly drafted agreement should address, at minimum:

• Background IP — what each party brings in, unchanged.
• Partner- and client-owned materials — firm kernel and client kernel stay distinct.
• Licensed fields of use — which offers, territories, and account classes the licence covers.
• Rights to generic components and improvements — who owns what after de-identified promotion.
• Confidentiality and de-identification — promotion protocol, not hope.
• Permitted reuse and promotion — what may climb into the capability kernel.
• Reverse engineering and unauthorised replication — the backstop clause, not the strategy.
• Audit rights — enough to verify licence use and separation of territories.
• Termination and continuity — what the partner can keep running; what reverts.
• Source or operational escrow — where appropriate, so anti-dependency is real under stress.
• Optional buyout economics — triggers, valuation method, what layers transfer, what remains licensed.

This list is an editorial checklist for commercial design conversation. It is not legal advice. Those provisions need actual legal drafting under the jurisdictions and deal size you are in. The broad commercial rule still stands: do not use a vague “we own everything we jointly develop” clause. Build the three-kernel ownership map into the agreement.

Specimen discipline still applies to the product itself: one working proof does not become five cargo-cult clones. The relationship should make the next offer a deliberate foundry output, not a screen-copy project.

What “necessary” means after the screens are public

Competitors can copy the offer name by Tuesday. They can copy report headings and brochure language. What is hard to copy is the governed delivery system that makes an otherwise dangerous commercial promise economically repeatable: sensors, safe representation, bronze evidence, engagement wiki, blind reconciliation, citation validation, separation of observed / interpreted / decided / scoped states, disposition controls, scope compilation, and the broader kernel that understands project selection, governance, delivery and failure shapes.

That stack is why the moat was never “uses AI.” It is composition. The Practice OS says the same thing at firm scale: neither the consultancy’s history nor the FDE kernel is the product alone. The product is the join.

Your relevance, after the first product is visible, is not that you once saw the right answer for one domain surface. It is that you can repeatedly perform the transformation:

Measure the better role with those outcomes — not with how long you can hide a screen.

• New offers launched per year
• Paid entry products sold through the partner’s installed base
• Reduction in unpaid proposal effort on the productised lane
• Downstream margin and change-request shape after readiness
• Escalation rate for fossilised exception classes (should fall)
• Time to launch the next offer versus the first
• Share of ordinary cases delivered by ordinary partner staff
• Reusable field learning promoted with receipts — and rejected when unsafe

Those are practice metrics. They assume transfer happened. They also assume you stayed on the upper rungs of the ladder. If both are true, the partner does not need you to run yesterday’s product — and still chooses the relationship because it remains the quickest and most reliable way to create tomorrow’s.

FDE BI is the first car. The durable business is the factory that discovers which car should exist next, builds it, proves it, and makes each subsequent one cheaper and safer to launch.

Software remains a weak moat. Permanent dependency remains a bad product. Between those two failures sits a third design: transfer operation, retain evolution, price the factory, write the buyout as a door rather than a myth of forever. That is how you make copying irrational without building a hostage.