Commercial cofounder @carbonphysicsai. Turning engineering capability into something people understand, try and buy. Sharing thoughts on distribution & demand.

Joined April 2010
The next great machine is waiting on physics AI we can build on.
The next AI frontier is physics. Today, we're announcing Carbon. A discovery and testing network to connect engineers with physics AI they can trust, and use it to design the next generation of machines.
1
256
Nick Fitzpatrick retweeted
Dev Update Highlight: ScoreLab A subnet’s scoring system shapes everything its miners build. That’s why we’re building ScoreLab to test which scoring approaches reward models that help engineers make better decisions. Physics, accuracy, speed and performance near real design limits all matter. Getting this right is how we direct Bittensor’s competitive energy toward products customers will pay for.
Carbon | Development Update: October 12–19 Path to Mainnet Last update I told you I won’t pay miners for anything until this system produces something a customer will pay for. That hasn’t changed. We're getting close! We just had a model run a challenge end to end, submitted, rebuilt, scored, and evidence saved Huge milestone. This post is long, but hopefully it helps you all understand just how much thought we're putting into this. The design is meant to be robust and efficient at onboarding new challenges once it's built. We are laser focused on creating a system that can target SOTA physics AI research at ANY valuable real world engineering problem we want... Here's what changed this week is how we’re getting there. 1. The Model Rebuild Last week Carbon miner submissions ran on a ladder of permission levels. We tested all of these permission levels for exploits which was great, but when we went to run the full system it added way too much complexity and fragility. Now it's one path, any method. Using what we learned in testing. This is the hard part. Automated model building on command, but it'll be such a weapon. Miners now submit a construction contract that takes in everything the validators need to rebuild the model from scratch. Then the validator uses that Challenge’s preset training data, freezes it, and tests it in a separate environment the miner’s code never touches. No pretrained weights smuggled in. A second rebuild has to match the first. Every winning model is one we can reproduce, which is exactly what a customer needs to trust it. This is a huge benefit of these physics models being small. Rebuilding them protects us, and gives us insight into what methods are working. I think this will be an excellent way to make sure we only pay for real valuable work. 2. The Score: Score = Value This is the biggest change, and it’s the one that matters most to customers. ScoreLab is a new piece of Carbon. It’s an internal workbench where every model we build in testing is put head to head against the physics solver it’s meant to replace, on the same problem, at the same fidelity. It runs the exact same scoring code our validators run. What we measure in development is exactly what miners get paid on. It's how we choose the optimal scoring design before launching. Unique for every challenge. Focused on value for the customer. Here’s how a model gets scored now: First, the gates. Does it obey the Challenge’s physics? Is it accurate enough to be used at all? Fail either and nothing else counts. Speed can’t buy you out of a physics failure. Then two scores, and both have to be strong: Accuracy across the whole problem: not just on average, but on the hard and unusual cases too. Decision quality at the limits. Does the model put a design on the right side of the challenge's limit, and by the right margin? Then we take its recommended design and run the real solver on it. Does it actually hold up? Calling a design safe when the solver says it fails is tracked separately, because that’s the mistake that costs a customer. Then speed: measured honestly against the solver, on stated hardware. Last update I told you our old score failed the customer test: models that were accurate on average were wrong at the limits. This fixes that structurally. A model can’t score highly by being good at one thing. It has to be accurate everywhere, right where decisions get made, and fast. One strong number can’t hide a weak one. Excellent across the board, or it doesn’t win. The exact balance between those scores what ScoreLab is solving for, from evidence, not guessing. Every model that goes through ScoreLab is kept: its recipe, its training procedure, every prediction, and exactly how it did against the solver. Over time that becomes a map of which methods of building a physics model actually work, for which kinds of problem. That’s the data our intelligence product is built on. Miners compete for rewards. Carbon learns from every attempt. Internal and External. 3. The Product. Why this is bigger than scoring. A score tells a miner who won. A customer needs much more than that. They need to know where the model can be trusted, and what to do when it can’t. That’s what the Carbon Model Package is: The model, the physics contract for the job it does, a map of where its answers hold, and a guarded design workflow. When an answer is in doubt, it hands off to the full solver or to an engineer instead of guessing. The customer gets a decision with the evidence behind it, not just a prediction. So we built ScoreLab to collect exactly what that package needs. Every model it tests is kept with all of it: every prediction, how far it was from the solver across the whole problem, which side of every design limit it landed on, which mistakes would have been dangerous and which merely cautious, and whether its recommended designs held up when the solver checked them. The same measurements that decide who gets paid become the evidence that tells a customer where to trust the model. Miners compete for rewards. The customer gets the proof, and an intelligent product designed for them. 4. Miners can bring the tools they actually use This week opened the door a lot wider: Miners can use the open-source libraries they already know. Carbon pins and provisions the dependencies on our side. The first library from outside our catalogue is in our test set now. New architectures were proven. Miners can write code that builds a custom graph, a genuinely new model shape, and it goes through the same rebuild and judge as everything else. This week we tested ensembles of those graphs, and the graph operations that mesh-based models depend on. Their own AI agents. Launchpad, the mining front-end, works with whatever agent a miner prefers, and we’re about to test it end to end with AI agents mining every launch challenge. Errors that tell you what to do. If something isn’t supported, the miner gets the exact operation and what’s needed. Not a refusal, and not a silent swap for a simpler model. Novel architectures, tuned to a specific engineering problem, rebuilt and verified by the network. That’s the part of this field Bittensor can lead. Unbelievably excited about this. 5. We closed a fairness gap Our judge used to grade models on a batch of hidden questions at once, so a model could in principle look across the exam while answering it. Nobody exploited it. We found it ourselves. Every hidden question is now graded on its own. A model’s score is about the model. 6. Rewards got simple Each Challenge has a king. Beat the king and you take that Challenge’s full share for 24 hours, then it halves every day until someone beats you. “Beat” means beat it for real. Inside measurement noise, the king keeps the crown, so copying the winner and tweaking it doesn’t pay. A king who improves their own model raises the bar but doesn’t reset their clock. A king who fails a required physics check loses the crown. 7. Real miners are already shaping it A test net miner already reported a crash with graph ensembles, that there was no visibility into rebuild time, and a constant budget that charged ensembles several times over. The crash was fixed and tested the same day. Constants are now counted once, and published Challenge data comes in as a proper input. Rebuild timing goes into miner feedback next. We're build alongside miners. 💪 8. Five Challenges planned We’re building toward five launch Challenges: 1. Motor: predicts an electric motor’s torque across its rotation angle (60 points per design), - Competing against a magnetic field simulation. 2. Cooling: a cold plate. Predicts peak temperature, the temperature profile along the plate, and pressure drop. - Competing against a thermal-fluid simulation. 3. Battery: fast-charging and ageing, including the plating limit, where charging too hard damages the cell. It’s the one with a real miner on it today. - Competing against PyBaMM, the open-source battery simulator 4. Ribbed Bracket: a structural bracket’s vibration, its natural frequencies and modes. - Competing against a finite-element solver (CalculiX). 5. Burst Thermal: how a part heats up under short bursts of power, against a temperature limit near 95 °C. - Competing against a heat-transfer solver (Elmer). Where we stand on these. The first motor model just made it end to end while I was typing this out. LFG The next 4 will follow. What’s between us and mainnet DONE - One model scored end to end through the real path JUST HAPPENED. NEXT - Proof that “any model” means any model. A stock architecture, custom training, a hand-built graph, an ensemble, an outside library, and a second rebuild that matches. (LET THE MINERS EAT, but rebuild their model before grading it) THEN - All five challenges on same loop THEN - The miner experience, tested like a miner. A fresh install, then AI agents mining every Challenge through Launchpad, from research to payment. (S/O @engyai @chutes_ai for making this affordable) LAST - Testnet running exactly like mainnet: same code, same rules, same rewards. Why this way Every shortcut we skip now is a bug a miner or customer doesn’t find later. We're testing thoroughly on disposable machines (S/O @TargonCompute @lium_io), fixing on development branches, and only shipping what’s proven. We’re close. I’ll launch when those boxes are checked, not before.
1
3
10
365
Nick Fitzpatrick retweeted
Carbon | Development Update: October 12–19 Path to Mainnet Last update I told you I won’t pay miners for anything until this system produces something a customer will pay for. That hasn’t changed. We're getting close! We just had a model run a challenge end to end, submitted, rebuilt, scored, and evidence saved Huge milestone. This post is long, but hopefully it helps you all understand just how much thought we're putting into this. The design is meant to be robust and efficient at onboarding new challenges once it's built. We are laser focused on creating a system that can target SOTA physics AI research at ANY valuable real world engineering problem we want... Here's what changed this week is how we’re getting there. 1. The Model Rebuild Last week Carbon miner submissions ran on a ladder of permission levels. We tested all of these permission levels for exploits which was great, but when we went to run the full system it added way too much complexity and fragility. Now it's one path, any method. Using what we learned in testing. This is the hard part. Automated model building on command, but it'll be such a weapon. Miners now submit a construction contract that takes in everything the validators need to rebuild the model from scratch. Then the validator uses that Challenge’s preset training data, freezes it, and tests it in a separate environment the miner’s code never touches. No pretrained weights smuggled in. A second rebuild has to match the first. Every winning model is one we can reproduce, which is exactly what a customer needs to trust it. This is a huge benefit of these physics models being small. Rebuilding them protects us, and gives us insight into what methods are working. I think this will be an excellent way to make sure we only pay for real valuable work. 2. The Score: Score = Value This is the biggest change, and it’s the one that matters most to customers. ScoreLab is a new piece of Carbon. It’s an internal workbench where every model we build in testing is put head to head against the physics solver it’s meant to replace, on the same problem, at the same fidelity. It runs the exact same scoring code our validators run. What we measure in development is exactly what miners get paid on. It's how we choose the optimal scoring design before launching. Unique for every challenge. Focused on value for the customer. Here’s how a model gets scored now: First, the gates. Does it obey the Challenge’s physics? Is it accurate enough to be used at all? Fail either and nothing else counts. Speed can’t buy you out of a physics failure. Then two scores, and both have to be strong: Accuracy across the whole problem: not just on average, but on the hard and unusual cases too. Decision quality at the limits. Does the model put a design on the right side of the challenge's limit, and by the right margin? Then we take its recommended design and run the real solver on it. Does it actually hold up? Calling a design safe when the solver says it fails is tracked separately, because that’s the mistake that costs a customer. Then speed: measured honestly against the solver, on stated hardware. Last update I told you our old score failed the customer test: models that were accurate on average were wrong at the limits. This fixes that structurally. A model can’t score highly by being good at one thing. It has to be accurate everywhere, right where decisions get made, and fast. One strong number can’t hide a weak one. Excellent across the board, or it doesn’t win. The exact balance between those scores what ScoreLab is solving for, from evidence, not guessing. Every model that goes through ScoreLab is kept: its recipe, its training procedure, every prediction, and exactly how it did against the solver. Over time that becomes a map of which methods of building a physics model actually work, for which kinds of problem. That’s the data our intelligence product is built on. Miners compete for rewards. Carbon learns from every attempt. Internal and External. 3. The Product. Why this is bigger than scoring. A score tells a miner who won. A customer needs much more than that. They need to know where the model can be trusted, and what to do when it can’t. That’s what the Carbon Model Package is: The model, the physics contract for the job it does, a map of where its answers hold, and a guarded design workflow. When an answer is in doubt, it hands off to the full solver or to an engineer instead of guessing. The customer gets a decision with the evidence behind it, not just a prediction. So we built ScoreLab to collect exactly what that package needs. Every model it tests is kept with all of it: every prediction, how far it was from the solver across the whole problem, which side of every design limit it landed on, which mistakes would have been dangerous and which merely cautious, and whether its recommended designs held up when the solver checked them. The same measurements that decide who gets paid become the evidence that tells a customer where to trust the model. Miners compete for rewards. The customer gets the proof, and an intelligent product designed for them. 4. Miners can bring the tools they actually use This week opened the door a lot wider: Miners can use the open-source libraries they already know. Carbon pins and provisions the dependencies on our side. The first library from outside our catalogue is in our test set now. New architectures were proven. Miners can write code that builds a custom graph, a genuinely new model shape, and it goes through the same rebuild and judge as everything else. This week we tested ensembles of those graphs, and the graph operations that mesh-based models depend on. Their own AI agents. Launchpad, the mining front-end, works with whatever agent a miner prefers, and we’re about to test it end to end with AI agents mining every launch challenge. Errors that tell you what to do. If something isn’t supported, the miner gets the exact operation and what’s needed. Not a refusal, and not a silent swap for a simpler model. Novel architectures, tuned to a specific engineering problem, rebuilt and verified by the network. That’s the part of this field Bittensor can lead. Unbelievably excited about this. 5. We closed a fairness gap Our judge used to grade models on a batch of hidden questions at once, so a model could in principle look across the exam while answering it. Nobody exploited it. We found it ourselves. Every hidden question is now graded on its own. A model’s score is about the model. 6. Rewards got simple Each Challenge has a king. Beat the king and you take that Challenge’s full share for 24 hours, then it halves every day until someone beats you. “Beat” means beat it for real. Inside measurement noise, the king keeps the crown, so copying the winner and tweaking it doesn’t pay. A king who improves their own model raises the bar but doesn’t reset their clock. A king who fails a required physics check loses the crown. 7. Real miners are already shaping it A test net miner already reported a crash with graph ensembles, that there was no visibility into rebuild time, and a constant budget that charged ensembles several times over. The crash was fixed and tested the same day. Constants are now counted once, and published Challenge data comes in as a proper input. Rebuild timing goes into miner feedback next. We're build alongside miners. 💪 8. Five Challenges planned We’re building toward five launch Challenges: 1. Motor: predicts an electric motor’s torque across its rotation angle (60 points per design), - Competing against a magnetic field simulation. 2. Cooling: a cold plate. Predicts peak temperature, the temperature profile along the plate, and pressure drop. - Competing against a thermal-fluid simulation. 3. Battery: fast-charging and ageing, including the plating limit, where charging too hard damages the cell. It’s the one with a real miner on it today. - Competing against PyBaMM, the open-source battery simulator 4. Ribbed Bracket: a structural bracket’s vibration, its natural frequencies and modes. - Competing against a finite-element solver (CalculiX). 5. Burst Thermal: how a part heats up under short bursts of power, against a temperature limit near 95 °C. - Competing against a heat-transfer solver (Elmer). Where we stand on these. The first motor model just made it end to end while I was typing this out. LFG The next 4 will follow. What’s between us and mainnet DONE - One model scored end to end through the real path JUST HAPPENED. NEXT - Proof that “any model” means any model. A stock architecture, custom training, a hand-built graph, an ensemble, an outside library, and a second rebuild that matches. (LET THE MINERS EAT, but rebuild their model before grading it) THEN - All five challenges on same loop THEN - The miner experience, tested like a miner. A fresh install, then AI agents mining every Challenge through Launchpad, from research to payment. (S/O @engyai @chutes_ai for making this affordable) LAST - Testnet running exactly like mainnet: same code, same rules, same rewards. Why this way Every shortcut we skip now is a bug a miner or customer doesn’t find later. We're testing thoroughly on disposable machines (S/O @TargonCompute @lium_io), fixing on development branches, and only shipping what’s proven. We’re close. I’ll launch when those boxes are checked, not before.
5
9
2
36
2,808
.@carbonphysicsai simplified
What is Carbon? A short explainer... (and more detail in the article below)
7
400
Nick Fitzpatrick retweeted
Miners are already finding our testnet and loving the mining experience! The best part is this is Level 0… @MaxSebti called us out at exploit for being too careful with what we were planning to allow miners to do. We agree. So we’ve moved that from a roadmap item, to a pre-launch item. Here’s a look at how we’re getting there 👇 Testing for exploits at every level with our in-house adversarial agent before we move up. New model architectures will be Bittensor miners making real Physics AI breakthroughs for real Engineering teams. 🔥
1
4
1
36
1,661
Nick Fitzpatrick retweeted
This design was very intentional. We’ve been watching subnets experiment with IMs for a couple years now. We’ve watched the research vs revenue debates. We’re trying to end that debate with a new architecture. Bittensor caliber research and discovery, but packaged into a valuable client focused deliverable. Our first challenges are built to simulate this exact experience. A real client problem handed to Bittensor to create a valuable product. Targeted product development. Specialization can be Bittensor’s superpower when aimed at the right market. A “firehose” of intelligence as @markjeffrey called it. Independently reviewed, and continuously improved. Incentive computing baby! LFG Carbon 🔥
Seriously, how good is Bittensor.
7
29
858
Great to chat @carbonphysicsai with @markjeffrey
Hash Rate - Ep. 188: Carbon Physics AI SN116 🧙 Guests: @RyanBequette and @fitzhere9 of @carbonphysicsai 00:00 Introduction and EXPLOIT 04:00 Carbon's mission 07:00 Emulating physics with AI 29:58 Market size and growth potential 33:18 Guest backgrounds 39:52 Competitive landscape 49:58 Liquidity Debate 55:09 Recent Cryptography Hubbub
5
249
Nick Fitzpatrick retweeted
If you'd like to understand the initial services Carbon will offer, there's a dedicated customers page on our website. carbonphysics.ai/customers
8
23
605
Physics that moves at the pace of design.
Understand Physics AI in 30 seconds 👇🏼
1
124
Nick Fitzpatrick retweeted
Carbon investors, future miners and researchers, we'd love to have you in our Telegram group 🫱🏽‍🫲🏼 t.me/carbonphysicsai
🤖 Made with AI
1
7
1
24
1,433
Nick Fitzpatrick retweeted
We’re putting Bittensor to work on industrial problems, building the evidence to show customers what Physics AI can deliver. The initial eight challenge portfolio we're building out has been published on our website, check it out 👇🏼 carbonphysics.ai/portfolio
1
16
2
46
3,677
Carbon is live on Subnet 116. It's been a fun sprint with @RyanBequette to get here.
Carbon is live! Subnet 116. Physics AI is now on Bittensor Let’s go!!!
2
9
454
Nick Fitzpatrick retweeted
Graphite has ingested 3000 papers today. Graphite is Carbon's in-house testing agent built to adversarially push the limits of every Carbon challenge before it hits mainnet. It works through Carbon the way a miner would, so we can see what construction freedom and the scoring do under real use.
🤖 Made with AI
3
1
18
2,617
Nick Fitzpatrick retweeted
What is Physics AI? What is Carbon's output and why does it matter? Miners design Surrogate Models using Neural Operators for specific high value Engineering Simulation tasks. Validators grade them against Traditional Solvers and Physics Laws. That's a lot. What does it mean? Let's break that down. Traditional Solvers (The Physics Calculations): They are solving the exact mathematical equations of nature (like fluids, heat, or stress) from scratch. It is highly accurate but incredibly slow and requires massive computing power for every new scenario. Surrogate Model (A Shortcut): This is a simplified "look-alike" model trained on data from past physics simulations. It is a fast, localized approximation. Neural Operators (The System Learner): This is Surrogate Model that uses advanced AI to learn the entire continuous field of physical behavior. Instead of just learning a few data points, it learns the underlying equations (PDEs). This allows it to make instant predictions across completely different designs because it learned to map the function space used to get from A to B. Engineering Simulation (The Virtual Testbed): This is where these models are put to work inside a digital environment. It is the software pipeline where engineers subject a design to real-world forces to analyze its performance, safety, and durability before anything is physically built. Carbon models are different than traditional AI models. They're built for physics. They're going to unlock serious real world value when put into the right hands. Powered by $TAO
1
3
10
866
Nick Fitzpatrick retweeted
We wrote this a couple of months ago for 10 followers, thought it was worth resharing now, our Carbon thesis.
1
7
1
27
1,427
Physics models are a massive unlock for engineers and we're confident Bittensor can deliver SOTA use cases. $TAO
Why do engineers need Physics AI models? Right now, engineers in every sector use simulation to predict their designs performance before they build it. Surrogate models are a new class of AI model that can make the exact same performance predictions at the speed of inference, taking the physics step down from days to seconds.
3
3
258
Nick Fitzpatrick retweeted
Our friend @macrocrux pointed it out on stage at @ExploitSummit Client data handling is going to be something @carbonphysicsai has to take very seriously. We're building that infrastructure out now, and leveraging the amazing products we have in Bittensor to do so. Looking forward to working with everyone to set up a system clients are confident in. @chutes_ai @TargonCompute @lium_io @Hippius_cloud @engyai If you think your subnet can get us closer to that system, reach out! $TAO
Carbon leverages @chutes_ai #SN64 confidential compute to allow serious engineering clients to play and build on Carbon without compromising their data. Workbench (for customer challenge design) & Ask Carbon (for anyone exploring Carbon). If you'd like to learn more about Carbon, go and Ask Carbon here → carbonphysics.ai
1
10
713