# physics.md — Office Hours Notes ## Starting point The initial instinct was that physics.md should help cover AI-assisted physics-related practical application. The key clarification was that this is **not just learning physics**. It is about giving AI-native learners a tool that fills in: - historical context, - state-of-the-art technology context, - why it matters today, - where the value is, - and how physics shows up in real systems. ## Main reframing The strongest reframing from the discussion was: > physics.md is not a general physics tutor. It is a way to understand how physical principles become technologies that matter now. That means physics.md should connect: - physical mechanism, - historical path, - modern technological application, - bottlenecks, - and practical leverage. A newer office-hours framing sharpens this further: > physics.md should feel like a decoder for modern hardware and infrastructure, starting with the systems AI-native builders already obsess over. ## Scope clarification A critical scope decision emerged: > physics.md focuses on pre-quantum physics, while still showing how state-of-the-art technology uses those physical principles. Examples raised in discussion: - how GPU matrix multiplication ultimately rests on physical systems shaped by electromagnetism, current flow, resistance, switching, interconnect, memory movement, and heat, - how Rydberg atoms and frontier compute platforms can be approached by grounding them in more classical physical intuition around energy levels, oscillation, and system behavior. This was a useful boundary because it prevents physics.md from collapsing into qubit.md. ## Relation to qubit.md The clean product architecture that emerged was: - `physics.md` = pre-quantum and quantum-adjacent grounding for modern and frontier technologies - `qubit.md` = actual quantum-computing learning path, circuit intuition, algorithms, hardware runs, and Shor-focused exploration This means physics.md can act like a broader parent layer for physical reasoning, while qubit.md remains the specialized vertical for quantum computing. ## Strong candidate thesis lines ### Thesis-facing **physics.md turns pre-quantum physics into a guide for understanding modern and frontier technology.** ### Product-facing **physics.md helps your AI explain how physics becomes technology, from charge and current in GPUs to energy states in frontier computing systems.** ### Broader worldview version **physics.md turns physics from a school subject into a map of real-world technological leverage.** ### Sharper landing-page promise **Ask about a real system, then see what mechanism is doing the work, what bottleneck actually matters, and why that changes how you think about the technology.** ## Candidate topic tracks ### 1. Compute physics - transistors - charge / current / resistance / capacitance - memory movement - signal integrity - thermal bottlenecks - GPU matrix multiplication as embodied physics - analog and photonic compute - frontier compute bridges ### 2. Sensing and control - sensors - resonance - noise - bandwidth - feedback and control - robotics and instrumentation - RF / radar / lidar ### 3. Energy and materials - batteries - motors - power electronics - solar - energy storage - thermal systems - material bottlenecks ### 4. Waves and optics - interference - modulation - lasers - fiber optics - imaging - photonics ## Core output structure idea For any topic, physics.md should help an AI answer: 1. What is the system trying to do? 2. What physical principle is doing the work? 3. What historical path led here? 4. What bottleneck or constraint matters most? 5. Why does this matter today? 6. Where is the value or leverage? 7. What adjacent frontier does this point toward? ## Biggest insights from the session 1. The product should not feel like school. 2. The product should not teach physics as a museum of formulas. 3. The wedge is practical and technological, not academic. 4. The differentiator is not “better explanation” alone, but explanation tied to history, bottlenecks, state-of-the-art tech, and real value. 5. The strongest initial wedge is likely: **helping AI-native builders explain why an important AI system is slow, expensive, or hard to scale by showing the physical machine underneath it.** ## Open questions Some early questions are now mostly resolved. The first public-facing wedge should currently bias toward **compute hardware**, with the flagship activation artifact centered on GPUs / memory / heat. The biggest remaining open questions are: 1. What should the first 10 canonical topics be after the GPU flagship example? 2. What should the second and third proof artifacts be after the compute-first activation page? 3. Should physics.md stay free distribution-first like qubit.md, or should it be paired later with premium domain reports / tools? 4. What should the first-user / first-1k distribution plan look like once the flagship artifact exists? ## Recommended next steps 1. Keep improving the flagship example page: **Why GPUs are physics, not just linear algebra**. 2. Define that artifact narrowly before expanding it: start from the job AI compute is trying to do, make memory movement feel like the main fight, and make power / heat feel unavoidable. 3. Keep refining `index.html` as a conversion surface into that flagship artifact. 4. Tighten `physics.md` further with anti-patterns, canonical examples, and sharper output guidance. 5. Build the second proof artifact around memory movement once the first proof page converts more clearly. 6. Clarify GTM / first-user distribution only after the proof surface is stronger. --- ## Office hours pass — 2026-03-28, canonicalization pass A later pass made something clearer: the product is not just converging on a thesis, it is converging on an activation pattern. That pattern is: 1. start from a real system the learner already cares about, 2. trace the physical mechanism, 3. identify the bottleneck, 4. connect it to why it matters now, 5. leave the learner with leverage. This matters because it is more specific than “explain physics better.” It defines what a successful first interaction actually feels like. ### Canonical product judgment The first public-facing wedge should still bias toward compute hardware. But the deeper canonical point is that **physics.md should win by changing how the learner sees a real system**, not by sounding smarter about physics in the abstract. That is the standard the examples, the spec, and the landing page should all align around. ### Canonical first activation artifact The strongest first activation artifact is still: > **Why GPUs are physics, not just linear algebra** Not because GPUs are the whole product, but because this example makes the product pattern obvious fast: - start with the system people already care about, - show that the math is not the machine, - explain why data movement, interconnect, heat, and power matter, - and leave the learner with a changed mental model of AI systems. --- ## Office hours pass — 2026-03-29, hard product pass This pass pushed harder on the question that matters most: what is the smallest version of the product that feels undeniable? ### Hard judgment The thesis is good enough. The bottleneck is not strategy quality anymore. The bottleneck is that the public surface still describes the product better than it demonstrates it. That means the near-term product job is narrower than “build a great physics reasoning layer.” It is: > make the compute-first front door so clear that the user immediately wants the flagship artifact. ### What changed in judgment The product now has a more explicit sequence: 1. flagship proof, **Why GPUs are physics, not just linear algebra** 2. follow-up proof, **Why memory movement is often harder than the compute** 3. expansion proof, **Why optics keeps showing up in modern systems** This matters because it turns the current strategy into a product progression instead of a pile of themes. ### Product call Do not broaden the landing page toward all topic areas too early. Lead even harder with compute. Let the broader domain map appear as the expansion path after the first mental-model win. ### Page call The landing page should do four things in order: 1. show the user the belief shift, 2. make the flagship proof path the primary CTA, 3. keep the spec and internal docs as secondary support, 4. only then show the broader product shape. ### Canonical consequence This pass materially changed the recommended action plan and strengthened the compute-first scope boundary for the public surface, so those conclusions should live in the broader product materials, not just here. --- ## Office hours pass — 2026-03-30, front-door pressure test This pass asked a harder question: if a smart technical visitor lands here for 60 seconds, what exactly are they supposed to want next? ### Hard judgment The answer still needs to get narrower. The product is not winning by showing breadth on the first page. It wins when the visitor feels one sharp upgrade: > AI hardware is a physical machine story, not just a math story. That means the first-page job is not “show all the domains physics.md may eventually cover.” It is: 1. name the user's pain in AI-system terms, 2. foreground the compute-first wedge, 3. preview the belief shift, 4. make the first proof artifact feel like the obvious next click, 5. let the broader domain map read as expansion, not the opening pitch. ### Product call Treat the first public success criterion as a belief shift. A good first interaction should quickly make the visitor feel that memory movement, interconnect, power, and heat belong in the same sentence as AI performance. ### Canonical consequence This strengthens the existing recommendation without changing the core thesis: the near-term product surface should optimize for one sharp compute-first proof, not for broad topical coverage on first contact. ### Additional 2026-03-31 pressure-test call The next failure mode is not weak thesis. It is building the flagship proof artifact too broadly. If the first artifact turns into a mini-course on GPU architecture, it will lose the plot. The first artifact should behave like a conversion proof for one specific user: - an AI-native software builder, - trying to reason about training or inference systems, - who needs to feel that the hardware is a physical machine shaped by data movement, power, and heat. That means the artifact should cut aggressively against side quests. Show the job, show the mechanism, show the bottleneck, show why AI performance is downstream of physics. Then stop. A stricter front-door conclusion from this pass: - the proof artifact is the product front door, - the markdown spec is the reasoning engine behind it, - and the landing page should sell the proof first, not the document set. --- ## Office hours pass — 2026-04-02, first-proof-artifact pass This pass pushed on a very obvious failure mode: the docs were repeatedly saying the first proof artifact mattered most, but the folder still did not contain one. ### Hard judgment That mismatch had to end. At some point, continuing to refine the strategy without shipping even a draft proof page becomes a form of hiding. So the key move in this pass was concrete: > create the first public draft of **Why GPUs are physics, not just linear algebra** and make the landing page point at it directly. ### What changed in judgment The main bottleneck is now different. Before this pass, the core problem was missing proof. After this pass, the core problem is improving the proof so it converts more sharply. That is better. Real product pressure can now happen against an actual page instead of a hypothetical artifact. ### New standard The first proof page should now be judged by harder questions: - does it break the abstraction quickly, - does it make the right user feel seen quickly, - does it make memory movement feel like the main villain, - does it make power and heat feel unavoidable, - does it make the second proof artifact feel wanted, - and does it do all that without turning into a broad GPU mini-course? ### Canonical consequence This pass changed the action plan materially enough that the broader strategy docs should say the first proof now exists in draft form. The next move is not “build the first proof page.” The next move is “make that page hit much harder.” --- ## Office hours pass — 2026-04-03, wedge-pain tightening pass This pass pushed on a YC-style question the folder was still ducking a bit: > who is desperate enough to care right now? The answer should not stay at the level of “AI-native technical learner.” That is directionally right but still too comfortable. The stronger answer is: - an AI-native software builder, - actively trying to make training or inference faster, cheaper, or easier to scale, - and running into the same reality over and over: the bottleneck is no longer only in the math or the code. ### Hard judgment The product is stronger when it names an active pain instead of a broad curiosity. The visitor should recognize themselves in the front door before they admire the thesis. That means the landing page should make room for lines like: - my model looks fast on paper but not in reality, - utilization is worse than expected, - memory traffic keeps dominating, - interconnect keeps showing up, - power and heat suddenly matter to software decisions. ### Canonical consequence This is a real wedge tightening, not just copy polish. So it should live in the broader canonical materials too: - `physics.md` - `founder-memo.md` - `ceo-physics.md` - and the front door in `index.html` ### Product call The right near-term front-door structure is now: 1. name the AI-systems pain, 2. promise the belief shift, 3. send the visitor into the GPU proof artifact, 4. keep the markdown spec and internal docs as support, 5. widen into the broader domain map only after that.