You send a sample to a partner. Three weeks later the reply arrives, and it is a smiley face, sometimes a literal emoji. I have received that reply more times than I can count, and I have sent it. It is good news, and you still have no idea what to make next.
The reply says the product got better. It does not say which property moved, by how much, or what to change next. Even a perfect better, same or worse answer only sorts your options into three piles. To pick one option out of 256, you would need at least six such answers in a row, and real answers are far from perfect. Each company's own know-how narrows the search, and the rest is paid for one full product test at a time. That is how capable companies send sensible samples for years and still miss a product that has to meet several specs at once.
Neither side can explain the whole result without giving something away. The supplier knows why its material changed. The product company knows whether the product improved. Explaining either one would expose recipes, processes, test methods or models, which is what makes each company valuable. For most of my career I treated this as the price of working together: open your books, or live with three-way replies. I looked for a third option more than once and did not find one. So I built it.
I call it Minimum Knowledge Collaboration, or MKC. Each company keeps its recipes, processes, test data and models. For each option it can make, it sends out a short string of numbers that lets options be compared without showing how they are made. After each product test, it gets back suggestions of where to look next, written in its own numerical map, and its own optimizer decides what to make. I tested this in 256 simulated development programs. Every approach got the same 64 full product tests, and the usual way then got up to 2,048 to see whether it could catch up. I measured how close each approach got to the reachable target, the best product the available options could make. MKC got nearly as far as an open-books benchmark, in which the joint search sees each company's full description of its options, before MKC shortens and scrambles it. The usual exchange of samples and three-way replies got far less.
The full method, with its proofs and statistics, is in the paper on ChemRxiv (https://doi.org/10.26434/chemrxiv.15009872/v1). You do not need the math to follow the idea. I built a replay of the paper's experiments that you can watch one product test at a time: https://materiax.ai/mkc.
In the 1970s, computers on different networks could not talk to each other. TCP/IP gave them one shared set of rules for what to send, and the padlock later added to browsers made sure only the intended recipient could read a message. Nobody had to open their machine to anyone. Joint development still works like networking before that. Every partnership invents its own exchange, and the safe default is the one that carries the least information: better, same or worse. MKC is my attempt at the missing protocol: a fixed set of rules for what each company sends and gets back, with everything inside each company left alone.
A carbon-black supplier and a tire company
Take a carbon-black supplier working with a tire company, the pairing I grew up in at Cabot. The supplier controls furnace conditions, feedstock, particle shape and surface chemistry, and tests its grades in lab rubber compounds. That adds up to thousands of possible grades. The tire company controls the rest of the recipe, the mixing and curing, the tire design, and the balance between wear, rolling resistance, wet grip, handling and durability. Only a full tire test shows how the two sets of choices work together.
If both companies opened their books, one search could cover both sides at once. But each would expose things a competitor could copy or patent around. If they keep the usual wall between them, the supplier has to search thousands of options guided only by better, same or worse. Eric von Hippel, who spent his career studying how innovation moves between companies, described two ways out of this bind. You can split the work so each piece needs only one company's knowledge, or you can make the knowledge easy to hand over. Neither works well for materials. The hard part is how the pieces interact, and the knowledge nobody wants to hand over is exactly what gives each company its edge. MKC takes a third path. The knowledge stays where it is, and what passes between the companies becomes more useful.
How one round works
Each company starts by describing the options it can actually make. A private program turns each option's record, with its process settings, measured curves and lab results, into a long list of numbers. Before the work starts, the company shortens that list, scrambles it in a way only it knows, and rounds the values. In the study, about a thousand private numbers became 64 shared ones. What leaves the company is a label for the sample plus those 64 numbers. No recipe, process setting, raw curve or model goes with it, and the tire company follows the same rule for its formulations.
An independent coordinator pairs one option from each company into a possible product. A statistical model designed to learn from a few expensive experiments picks the pairing most worth testing against all the specs. The coordinator locks in that choice before any result comes back, so nobody can adjust it after the fact. The tire company builds and tests the tire. Spec names, units and raw data stay inside its own system, which passes back only scores with the labels removed.
After the test, the coordinator sends each company two suggestions in its own numerical map. Only that company holds the private model that turns those positions into materials or process changes. Like the padlock in your browser, that means only the company a suggestion is meant for can use it. One suggestion balances all the specs, and the other aims at the spec furthest from its target. The carbon-black supplier gets directions relative to the grade it just tested, and its own optimizer combines them with its process knowledge and lab results to find grades it can actually make. The tire company does the same with its formulations. The coordinator never designs carbon black and never formulates a tire. It picks the next test and tells each company where to look next. That suggestion is what the usual sample-and-reply exchange is missing.
What gets shared, and what stays private
Recipes, process settings, raw measurements, failed experiments and models stay inside each company. What crosses is limited to sample labels, the shortened numbers, scores with no names attached, and suggestions addressed to each company. Could a partner rebuild a recipe from what is shared? They would first have to work out how a company scrambled its numbers, and then turn those numbers back into a private record. The paper tested the second step directly, even giving the decoder private examples that MKC never shares, and took the first step from the closest published study. Combined, the two give about 0.0063%, roughly 1 in 16,000, as an illustration of scale rather than measured odds for a real partnership.
Minimum means the least sharing that still lets the group pick good tests and lets each company act on its suggestions. It can be measured. In the study, sharing half as many numbers kept most of the benefit, and each company can test that trade-off on its own options before a program begins.
What the suggestion back is worth
I expected the shared descriptions to carry most of the value. So the comparison I trusted most removed only the suggestions sent back. Descriptions still went out, the coordinator still picked the tests, and the options and test budget did not change. Progress fell by about two-thirds. Sharing a description helps the group choose a test. Sending back a suggestion is what lets each company use that test to decide what to make next.
How much this matters depends on the size of the problem. Take two settings from the study, each averaged over 16 simulated programs and given the same 64 full product tests. With two companies, 128 options each and two specs, open books reached 99.6% of the reachable target, MKC 98.7%, and samples with three-way replies 27.3%. The usual way makes real progress there. Given up to 2,048 tests, 15 of those 16 programs caught up with what MKC reached in 64. With four companies, 1,024 options each and four specs, open books and MKC both reached 94.1%, and samples with three-way replies 0%.
Here is what the 0% means. The product score follows the spec furthest from its target, so improving a stronger spec cannot hide a weak one. The chart also shows anything below the starting point as zero. A 0% means that after 64 tests the weakest spec had still not risen above where it started. It does not mean the companies learned nothing or that no property changed. Given 2,048 tests, the same setting averaged 22.2%, and none of its 16 programs caught up with MKC. Across all 256 programs, more options per company made catching up much harder, and more companies and more specs widened MKC's lead at the same test budget.
The extra work grows with what makes joint development hard, and it is smallest in the simple two-company case, where you need help least. Across the study, MKC needed about 40 full product tests on average to reach its result. The sample-and-reply programs used more than 1,300 on average, counting those that stopped at the 2,048-test limit, and fewer than half ever caught up. Each of those tests is a real batch, a slot on a production line and a team working at full scale. An established company absorbs that as a late launch. A startup can run out of money first.
How to explore the replay
The replay at https://materiax.ai/mkc plays back the paper's recorded experiments one product test at a time. Nothing is recalculated, and there are no equations. Four lines run over 64 tests: open books, MKC, MKC without the suggestions back, and samples with three-way replies. Start with the two-company case. The usual way makes visible progress there, and even MKC without suggestions gets close. Then press the four-company example, with 1,024 options per company and four specs, and watch the lines pull apart. A note under the chart explains the 0%. A panel next to the chart shows what was exchanged at each test: numbers and two suggestions for MKC, a physical sample and a three-way reply for the usual way.
Next, give the usual way up to 2,048 tests and see where it catches up and where it does not. A grid of 16 settings lets you replay every tested combination. The last section shows the short string of rounded numbers a company shares, next to the records and models it keeps private. If a step does not make sense, tell me which one. That is the feedback I need most.
What still has to be proven
These are computer experiments. They show that all the pieces work together as one process. They do not prove that a real tire, battery, composite or coating program will speed up by the same amount. MKC also does not replace the joint development agreement. Rules on samples, intellectual property, fields of use and commercial terms still belong there.
A first real-world trial would be small. Where a partnership has enough options and product tests on file, it can start from those records, with no shared database and no new experiments. Compare the sample-and-reply program with MKC on the same test budget. Measure the progress, the number of tests, each company's own search work and what each company had to share. If you run joint development and have a program like that, that is the conversation I want to have.
Watch the replay: https://materiax.ai/mkc.
Read the ChemRxiv paper: https://doi.org/10.26434/chemrxiv.15009872/v1