Your Engineering Firm Is Not a Training Dataset

I have become increasingly frustrated with a certain kind of cold call.

The pitch usually comes from a startup that wants to “partner” with an engineering firm. Sometimes the proposal involves payment per unit. Sometimes it is based on performance. Sometimes there is a promise of future revenue, shared upside, equity, or access to a new market.

The language varies, but the underlying proposition is often the same:

They want access to the accumulated knowledge inside the engineering company without paying the actual cost of developing that knowledge.

What they are seeking is not merely engineering labor. They want the methods behind the labor.

They want to know how we decompose a complex problem, how we select tools, how we structure development, how we evaluate risk, how we perform design reviews, how we test, how we document, how we detect failure modes, and how we maintain quality across an entire development process.

That knowledge may have taken decades to develop.

It was acquired through successful projects, failed experiments, difficult customers, production problems, field failures, regulatory constraints, technical dead ends, and countless hours of disciplined engineering judgment.

That body of knowledge is one of the primary assets of an engineering firm.

Increasingly, however, some startups appear to view engineering firms as convenient sources of training data.

The New Form of Knowledge Extraction

The rapid development of artificial intelligence has made internal process knowledge unusually valuable.

AI systems can now be given structured instructions describing how to perform specialized work. These instructions may take the form of prompt libraries, workflow documents, process descriptions, tool-integration instructions, quality-control procedures, or files resembling a SKILLS.md library.

The filename is not important.

What matters is the function.

These files teach an AI system how a skilled person or organization approaches a task. They may describe:

• How to analyze a customer requirement
• How to select an architecture
• How to review source code
• How to troubleshoot hardware
• How to use specialized development tools
• How to structure validation
• How to identify quality risks
• How to prepare documentation
• How to manage configuration and release processes
• How to convert ambiguous requirements into executable engineering work

That is not generic information. It is often the operating intelligence of the company.

Once transferred into an AI system, that intelligence can be replicated at nearly zero marginal cost. The company that contributed the knowledge may receive a small consulting fee, a speculative revenue-sharing agreement, or a promise of future work. The recipient, meanwhile, may obtain a reusable approximation of the firm’s accumulated expertise.

This creates a severe mismatch between compensation and value.

A startup may offer to pay for a few meetings, a pilot program, or a limited engagement. But the value being extracted may represent years of organizational learning.

The engineering firm is effectively being asked to sell its factory for the price of a few finished products.

Why Performance-Based Compensation Is Often Misaligned

Per-unit and performance-based arrangements are not inherently illegitimate. In the right circumstances, they can align incentives and create shared opportunity.

The problem is that many startups asking for these arrangements have little or no proven sales volume.

They are asking the engineering firm to contribute valuable intellectual capital today in exchange for hypothetical compensation tomorrow.

The startup may promise revenue when the product ships, when customers adopt it, when funding arrives, or when a future milestone is reached. But many startups never reach those milestones.

The engineering firm bears the immediate cost.

Its engineers spend real time. Its internal methods are exposed. Its know-how is transferred. Its opportunity cost is incurred. Its proprietary processes may be converted into software or AI instructions that the startup can continue using after the relationship ends.

The startup receives something durable.

The engineering firm receives a possibility.

That is not a balanced partnership.

A legitimate risk-sharing arrangement requires both parties to contribute something of comparable value and to bear comparable risk. Too often, the startup contributes an idea and an optimistic forecast while expecting the engineering firm to contribute labor, experience, process knowledge, technical judgment, and sometimes financing through deferred compensation.

An idea is not equivalent to an engineering organization.

Know-How Is Not the Same as a Deliverable

This distinction is essential.

When a customer hires an engineering consulting firm, the customer may own the contracted deliverables. Depending on the agreement, those deliverables may include schematics, source code, design files, specifications, test results, manufacturing documentation, or other defined work products.

That does not ordinarily mean the customer acquires the consulting firm itself.

The firm’s know-how remains distinct from the deliverables.

Know-how includes the general methods, experience, internal tools, reusable processes, templates, judgment, development practices, quality systems, and problem-solving techniques used to produce the work.

A customer may own the software created for its product.

That does not mean the customer owns the internal instructions that teach our engineers how to create reliable software.

A customer may own the circuit-board design produced under the engagement.

That does not mean the customer owns our methods for component selection, risk analysis, design review, verification planning, or failure investigation.

A customer may own the final report.

That does not mean the customer owns the process by which we learned to produce accurate reports.

These distinctions have always mattered in professional services. AI has made them more visible because internal know-how can now be captured, encoded, and operationalized in a form that is immediately reusable.

Engineers Are Beginning to Recognize the Risk

My engineers have begun treating AI skill libraries and process instructions as closely held company know-how.

They understand what these materials represent.

A sufficiently detailed collection of engineering skills can contain the logic of the business: how work is performed, how decisions are made, how quality is enforced, and how less-experienced personnel are guided toward expert outcomes.

Giving those materials to a customer would not be comparable to delivering source code for a product.

It could be comparable to delivering the internal operating system of the engineering firm.

In the extreme case, a firm could train a customer’s AI system to reproduce the firm’s methods, reduce the customer’s future dependence on the firm, and transfer years of institutional knowledge for a small one-time payment.

The firm would be participating in its own displacement.

That is not technological progress. It is poor stewardship.

Partnership Requires Recognition of Value

A real partnership begins with an honest accounting of what each party is contributing.

If a company wants engineering labor, it should pay for engineering labor.

If it wants a completed product, it should contract for the product.

If it wants a license to proprietary tools or processes, it should negotiate and pay for that license.

If it wants to train an AI system on an engineering firm’s internal methods, then it is seeking access to a core intellectual asset. That access must be treated accordingly.

The compensation should reflect:

• The cost of developing the know-how
• The competitive value of the information
• The scope of reuse
• The duration of the license
• Whether the knowledge can be sublicensed
• Whether it will be used to train AI
• Whether it can be incorporated into commercial products
• Whether it reduces future demand for the firm’s services
• The risk that the information may be copied or redistributed
• The strategic value transferred to the recipient

A vague promise of future revenue is not sufficient compensation for permanent transfer of reusable organizational intelligence.

Engineering Firms Must Establish Clear Boundaries

Engineering firms need to become much more deliberate about protecting their internal knowledge.

Contracts should clearly distinguish customer deliverables from retained background technology and know-how.

Confidentiality provisions should address the use of supplied information for AI training.

Statements of work should define exactly what documentation will be delivered.

Internal process documents should not be transferred casually merely because a customer requests them.

AI prompts, agent instructions, workflow libraries, internal checklists, tool instructions, and quality procedures should be treated as intellectual property.

Access should be limited according to business need.

Employees and contractors should understand that a process encoded as an AI skill is still a company asset.

The fact that information is written in Markdown rather than compiled into software does not make it valueless.

In many cases, the Markdown may be more valuable than the software.

We Are Willing to Create Value, Not Surrender It

Engineering firms exist to solve difficult problems.

We want our customers to succeed. We want to transfer the product knowledge necessary for them to manufacture, maintain, support, and improve the systems we develop for them.

But there is a difference between enabling a customer to own and support its product and teaching the customer how to replace the engineering organization that created it.

That boundary must remain clear.

We will deliver what we contractually agree to deliver.

We will protect our customers’ intellectual property.

We will honor legitimate ownership rights.

We will also protect our own intellectual property, including the accumulated know-how that allows us to perform at a high level.

Our internal methods are not incidental byproducts of the work.

They are part of the value being purchased when a customer hires us.

They are not free.

They are not automatically included.

And they are not a training dataset for someone else’s AI.