Article

Hardware engineering companies: get paid for your records

By TrustPast

Updated November 7, 2026

This page is for a hardware engineering company with 30 or more people: a product design firm, an electronics developer, a maker of instruments, controls, sensors or devices. You know the patents and the product line have value. What you may not have counted is the record of how every board, enclosure and firmware release got from a requirement to a shipped product.

That record is the design review where someone asked the awkward question, the engineering change that answered it, the test report that failed and the failure analysis that explained why. Each is a decision, written down by an engineer who had to defend it. A buyer pays to license records like these to train AI models, and the value is in how the work was done. The general case, written for trade businesses and true of a lab bench, is on what data buyers actually want from a trade business.

Here is what a hardware team keeps, what micro1 says counts, what stays out, and what moves the price.

The records a hardware engineering company keeps

These are our examples, not a buyer’s list. They are what a hardware team writes as it designs, builds and supports a product.

The requirements document. What the product must do, at what cost, in what environment, to which standards. Then the revisions, as marketing, the customer and physics each pushed back. The version history of a requirements document is a record of trade-offs.

The design reviews. Concept, preliminary, critical. The slides, the action items, the minutes that say the thermal margin looked thin and someone was given a week to prove it wasn’t. The action-item log shows which concerns were real.

Schematics, layouts and the bill of materials. Each revision with its notes. Why a regulator was swapped. Why a connector went to a second source after a shortage. The BOM history shows how a product survived its supply chain.

The engineering change notice. When a released design changes, the ECN records what, why, which serial numbers, and who signed. A product with 140 ECNs over eight years carries 140 small arguments, each settled.

Prototype builds and the build log. What was built, which rework wires were added, what the technicians noticed. The contract manufacturer’s design-for-manufacture feedback, and the answers to it.

Test plans and test reports. Functional tests, environmental tests, compliance tests at an outside lab. The report that passed is useful. The one that failed, with the margin and the retest, is more useful.

The failure analysis. A unit comes back from the field. Someone opens it, finds a cracked solder joint, traces it to a thermal cycle nobody tested for, and writes it up with the fix. This is how a problem was diagnosed, step by step, with the wrong guesses in the record.

The returns and repair records. Each return authorisation, the fault found, the repair, and the trend that eventually triggered a design change. The job files and work orders page goes through what a repair order carries and why the notes matter more than the totals.

The firmware tracker. Bugs, fixes, release notes and the threads behind them.

Then there are the files nobody lists. The lab notebook kept by the senior engineer. The spreadsheet of component substitutions made during a shortage, with the reason for each. The email thread with the compliance lab after a failed emissions scan. The bench notes a technician wrote while chasing an intermittent fault. None of these was bought as a system, so none appears when the owner counts tools. Each is where the reasoning sat before it reached a formal document.

Most of it sits in project folders and a tracker. Our project history page shows how a project’s plan, changes and close-out fit together as one record.

An invented example shows how the pieces connect. A controller was specified in 2015. At the critical design review, a reviewer questioned the input protection. Testing passed. In 2017, field returns showed a failure after power surges. The failure analysis found the protection diode undersized for a real-world transient. An ECN changed the part and the test plan added a surge case. Three systems hold that story: the review minutes, the returns database and the change log. Followed in order, it is a complete lesson in how a design team learned from the field.

See your estimate

What counts, in micro1’s own words

The eligibility line on micro1’s data partnerships page reads: “We’re looking for established companies with 30+ full-time employees, mature business operations, and substantial historical operational data.” It lists what that data can include: “internal communications, SOPs, project histories, CRM records, support tickets, and other business documentation.”

On the kind of data, micro1 says: “We are looking for data that reflects how work is actually performed within an organization.” And “The most valuable datasets capture real operational expertise, decision-making processes, and repeatable workflows”.

For a hardware company, the closest of micro1’s industry examples is software and engineering: “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases”. The page lists it under the heading “Operational data from every industry can contribute”. Hardware isn’t named on its own, and micro1 doesn’t say it is looking for hardware firms in particular. The referral page lists “All industries” among its requirements.

As our own reading of those words against an engineering office: a design review and its action items are an engineering workflow. The returns database and the firmware tracker are bug tracking. The requirements document and the roadmap are product planning. The lab’s wiki of test setups and known issues is a technical knowledge base. And a failure analysis is a decision-making process in its most complete form: the evidence, the hypotheses, the test that ruled them out.

On volume, micro1 says: “There’s no fixed minimum number of files, documents, or terabytes.” It says “Companies with several years of records across multiple business systems are generally a stronger fit.” A hardware team usually has at least four systems: the design data vault, the tracker, the returns database and email.

What is never included

Personal data stays out: customer names on return forms, staff files, payroll, payment details. Our page on what is never included shows where each hides. A hardware company has two harder lines, as our own advice.

Controlled technology. This is the first question for any engineering firm that has touched defense, aerospace, space, encryption or advanced computing. The Bureau of Industry and Security says the Export Administration Regulations govern “the export, reexport, and transfer (in-country) of items “subject to the EAR,”” where an item means “commodities, software, and technology”. On its deemed exports page it says: “A deemed export refers to the sharing or release of controlled technology or source code to a foreign person within the United States.” So the question is not only where the files go but who reads them. The same agency lists the State Department’s Directorate of Defense Trade Controls among the other agencies with export control responsibilities, with jurisdiction over defense articles and defense services. micro1 publishes that its data is licensed “exclusively to labs and enterprises based in the U.S. and allied countries”. That is a buyer’s commitment, not an export determination. Keep every controlled or possibly controlled file out of the inventory until counsel has classified it. Ask counsel.

Client designs. A design firm builds for clients, and the development agreement usually says who owns the schematics, the layouts and the firmware. Often the client owns the deliverable and the firm keeps its own methods. The test reports and the failure analyses may be the firm’s, or they may be the client’s; only the contract says. Our page on client-owned work and NDAs shows how to sort a project folder, and counsel has the final word.

Then the obvious ones. Supplier pricing under NDA, patent drafts not yet filed, and anything a regulator has asked you to keep confidential stay where they are until counsel says otherwise.

How de-identification works

micro1 says the company doesn’t need to scrub its own files: “No, micro1 has processes for de-identifying and transforming sensitive information.”

Before any participation, micro1 says the two sides confirm four things, including “De-identified before sharing”, explained as “Personal and identifying information is removed or transformed before your data is shared with third parties”, and “Data segregation”, explained as “Your data is kept separate from other companies’ data, with access restricted to authorized personnel”.

After data is shared, micro1 says “personally identifiable information may be removed and certain datasets may undergo synthetic rewrites that preserve workflow structure while reducing direct ties to original records.” It says data is “retained only for a limited period based on agreed retention policies”, and that “companies are given the opportunity to review representative samples before prepared data is used.” Its page adds that “employees with access to data systems use company-managed devices and follow established security controls and training requirements.”

On an engineering change notice, as our own illustration, the engineers’ names, the customer’s name and the serial numbers tied to a customer are the identifying parts. The reason for the change, the parts affected, the test that justified it and the effective date are the work. A synthetic rewrite matters for a hardware firm: a well-known product can be recognised by its specifications even with every name removed. Ask how micro1 would treat that. More on each step is on how de-identification works.

What decides the price

micro1 publishes three tiers on its data partnerships page. $100K-500K for “Qualified Enterprise Data Partnerships” (indicative, not an offer). $500K-3M for “Large-scale operational datasets or ongoing participation across multiple teams and business functions” (indicative, not an offer). $3M+ for “Highly unique, proprietary operational data” (indicative, not an offer).

It names the factors: “dataset size and volume, workflow complexity, data quality, domain expertise represented, and the uniqueness of the operational knowledge contained within the dataset.” And it adds: “Each partnership is evaluated individually, and compensation is aligned with the overall value and relevance of the data provided.” Its estimate page says the final payout depends on “data sources, volume, quality, access terms, and due diligence.”

As our own reading, for a hardware company:

Linked records. A design review whose action items lead to ECNs, test reports and field data is one connected record. The same documents in separate, unlinked drives are harder to value.
Failures with explanations. A returns database with fault codes is a list. Returns with failure analyses attached are a record of diagnosis.
Domain expertise. Power electronics, RF, optics and safety-critical design each carry knowledge that is hard to find in public. micro1 names “domain expertise represented”.
Years. Several product generations show how the team’s practice changed. micro1’s estimate asks how many years of data you have, “Typically the number of years you’ve been in business”.

What lowers it: projects that only kept the released files, a migration off an old design vault that left the history behind, and long gaps in the tracker. If you changed systems, our page on whether old systems count shows how to keep the history before access ends.

micro1’s steps say it pays “in full within 30 days of acceptance, with payments typically ranging from $100K to over $3M” (indicative, not an offer). On 9 October 2026 it announced a commitment to spend $1 billion over the next 12 months on enterprise operational data. The factors are explained on what decides the price of your records.

Which programme fits

This is a micro1 page. Its line is 30 or more people, now or at peak, or a company of any size outside the US. The referral page lists the enterprise requirements as “30+ employees”, “US and Western markets”, “English” and “All industries”. Count engineers, technicians, test, support and the office. The estimate asks your headcount and names the programme that fits it.

A closed hardware company still has its design history. micro1’s referral page lists a Defunct Company Data Partnership: “We are acquiring data from companies that are no longer operating.” Its listed requirements are “30+ employees”, “10+ Countries”, “English” and “All industries”, with company compensation of $100K-$3M+ (indicative, not an offer) “for approved data packages”. For a closed engineering firm, controlled-data questions come first, then who can sign. Both are on the page for closed companies.

A SaaS and subscription company keeps the same tracker, release notes and incident threads, without the solder. A consulting or advisory firm shares the client-ownership question: the deliverable belongs to the client and the method belongs to the firm. And a manufacturing or industrial company is where an ECN lands, with travelers and nonconformance reports picking up where the test reports stop.

TrustPast

Questions and answers

Does micro1 look for engineering records?

Its data partnerships page lists software and engineering among its industry examples: “Source code documentation, engineering workflows, bug tracking, product planning, and technical knowledge bases”. micro1 decides what it licenses after it has reviewed the company.

Some of our designs are export controlled. What then?

Keep those files out until counsel has looked at them. The Bureau of Industry and Security says a deemed export is the sharing or release of controlled technology or source code to a foreign person within the United States, so even a review by the wrong person can matter. Ask counsel.

We design for clients. Whose files are they?

The development agreement decides. Often the client owns the design and the company owns its own methods and tools; that is our advice, not micro1’s, and counsel should read the contracts before anything is listed.

Do we have to remove engineers’ names from the tracker?

No. micro1 says it “has processes for de-identifying and transforming sensitive information”, and that personal and identifying information is removed or transformed before the data is shared with third parties.

What could a hardware company be paid?

micro1 publishes tiers of $100K-500K, $500K-3M and $3M+ (indicative, not an offer). It says compensation is based on the quality, uniqueness and value of the data provided.