# CEO Review Draft — physics.md ## What business are we actually in? We are not in the business of generic physics education. We are in the business of helping AI-native learners and builders understand how physical principles become useful technologies, constraints, and leverage in the real world. The sharper version is this: > physics.md is a decoder for modern hardware, infrastructure, and frontier systems, starting from the physical bottlenecks hidden underneath software abstractions. That is much better than “learn physics with AI.” ## The problem A modern learner can ask an LLM about electromagnetism, optics, thermodynamics, semiconductors, batteries, or photonics and get an answer. But the answer is often flattened. It explains the concept in textbook order, strips away the historical path, misses the actual bottleneck, and does not connect the mechanism to why the technology matters today. The result is shallow understanding. The learner gets explanations, but not a map. The more operational version of the problem is that users want to understand real systems like GPUs, memory hierarchies, cooling, photonics, sensors, or batteries, but generic AI keeps returning chapter summaries. ## The product thesis physics.md should turn an AI agent into a physics-grounded interpreter of real technology. That means the product should help answer: - what physical principle is doing the work, - what historical path led here, - what constraint or bottleneck matters, - why this matters now, - where the value is. The user should leave with practical understanding, not just a cleaner school-style explanation. The standard is not “did the AI explain physics correctly?” The standard is “did the AI change how the user sees a real system?” ## Scope boundary physics.md should focus on **pre-quantum physics** and the way it powers modern and frontier systems. Examples: - electromagnetism in GPUs, memory systems, motors, and interconnects, - optics in photonics, fiber, imaging, and sensing, - thermodynamics in compute cooling, engines, and batteries, - control, resonance, and noise in robotics, instrumentation, and RF, - classical physical intuition that bridges toward quantum-adjacent platforms such as Rydberg systems. This is a strong boundary. It keeps physics.md from dissolving into “all science.” ## Wedge user The wedge user is: > an AI-native technical learner or builder who wants to understand the physics behind important modern technologies without getting trapped in textbook abstraction. For the first public wedge, bias even narrower: > an AI-native software builder trying to make a training or inference system faster, cheaper, or easier to scale, but still treating hardware like an abstraction layer. That pain matters. The first user should not arrive with abstract curiosity alone. They should already feel some version of: - the model is slower than expected, - utilization is disappointing, - memory bandwidth keeps dominating, - interconnect keeps showing up, - or power and heat are suddenly product constraints. This user may be: - a software or AI engineer trying to understand real hardware, - a founder or builder trying to understand where technological leverage lives, - a technically curious learner trying to connect physical principles to current systems. ## Narrowest wedge The public entry should stay **compute hardware first**. More specifically: > help AI-native learners understand why GPUs, memory movement, interconnect, power delivery, and heat are physics problems, not just software or math problems. This is the best wedge because: - the user already cares, - the relevance is immediate, - the bottlenecks are real, - and the lesson generalizes outward into optics, energy, sensing, and frontier hardware. ## Core promise A strong thesis line is: > physics.md turns pre-quantum physics into a guide for understanding modern and frontier technology. A stronger landing-page promise is: > Ask about a system you already care about, then see what mechanism is doing the work, what bottleneck is actually limiting it, and why that matters now. ## Why this matters now Physics is becoming more important, not less. The technologies shaping the next decade are constrained by physical bottlenecks: - heat, - power, - bandwidth, - material limits, - fabrication difficulty, - sensing limits, - noise, - control, - energy transport. As AI-native learners and builders move closer to hardware, energy, robotics, chips, optics, and frontier systems, they need a better way to reason from physical principle to practical value. That is the opportunity. ## Product structure ### Free layer - use `physics.md` with your AI agent - start from a real system, not a chapter title - get a mechanism-first explanation tied to history, bottlenecks, and modern use ### Activation layer - the first “oh, this is how physics actually shows up in this thing” moment - the ideal path is: real system → mechanism → bottleneck → why now → leverage - the strongest first activation artifact is a GPU / memory / heat explainer for AI-native learners - the second wave should likely expand into memory movement and optics ### Retention layer Users continue through domain tracks such as: - compute physics, - sensing and control, - energy and materials, - waves and optics. ### Premium or higher-value direction Potential premium layers could include: - domain-specific deep dives, - state-of-the-art technology landscape reports, - builder/founder briefs, - visual explainer systems, - specialized frontier hardware tracks. ## What the office-hours pass clarified The key office-hours judgment is that the strategy is still ahead of the proof surface. That means the next product move is not another memo. It is a proof artifact that makes the thesis feel undeniable. The first three proof artifacts should likely be: 1. **Why GPUs are physics, not just linear algebra** 2. **Why memory movement is often harder than the compute** 3. **Why optics keeps showing up in modern systems** That gives the product a coherent opening sequence instead of a bag of possible topics. The first proof now exists as an initial draft page in this folder: - `why-gpus-are-physics.html` That means the main bottleneck changed during this pass. It is no longer proof-artifact absence. It is proof-artifact quality and conversion strength. The first artifact also needs a tighter quality bar. It should not become a GPU architecture tour. It should start from the job AI compute is trying to do, make memory movement feel like the main fight, and make power / heat feel like unavoidable design forces. ## The moat The moat is not “explains physics more clearly.” That is too easy to imitate. The moat is the combination of: - physics grounding, - historical context, - state-of-the-art relevance, - bottleneck analysis, - value / leverage framing, - strong topic architecture around technologies that matter now, - and proof artifacts that change the user's mental model fast. In other words, physics.md should not just answer “what is this?” It should answer “why does this matter, what is doing the work, what is hard, and where is the leverage?” ## Risks 1. Too broad. If physics.md tries to cover all of physics equally, it becomes mush. 2. Too educational. If it feels like school, it loses the real-world technology wedge. 3. Too futuristic. If it leans too hard into frontier systems without building classical grounding first, it becomes hypey and fragile. 4. Too explain-y. If it explains well but does not map toward practical value, it gets replaced by generic LLMs. 5. Too strategy-heavy. If the page and docs keep improving while the public proof artifact stays weak, the product still will not feel real enough. ## Strategic recommendation Start with this wedge: > physics.md is for AI-native learners trying to understand the physics behind important technologies shaping the world right now. More specifically, the public-facing entry should bias toward: > helping AI-native learners understand compute hardware first, especially GPUs, memory movement, interconnect, power, and heat. The public product surface should behave like this: 1. name the user's pain in concrete AI-system terms, 2. show the flagship example, 3. preview the belief shift the artifact delivers, 4. make the flagship proof path the primary CTA, 5. keep the spec and internal docs as secondary support, 6. only then expand into the broader product map. The key product standard is not just “this page explains the idea well.” It is: > does the page make the visitor want the first proof artifact badly enough to click, because they recognize their own bottleneck and can already feel the mental-model upgrade waiting on the other side? Another way to say it: > the proof artifact is the product front door, and the markdown spec is the reasoning engine behind it. For the current folder state, that means `index.html` should explicitly send users into `why-gpus-are-physics.html`, and future product work should keep making that page more undeniable before adding more strategic prose. Build around domains where physics is obviously doing the work: - compute hardware, - optics, - sensing, - energy, - materials, - control systems. Let frontier topics emerge as adjacent branches, not the initial center. ## CEO verdict There is a real product-shaped idea here if the scope stays disciplined. The good version is not “physics tutor.” The good version is a physics-grounded reasoning layer for understanding modern technology and where real leverage lives. But the near-term job is narrower than the thesis. The near-term job is to make the compute-first front door undeniable.