# physics.md: Physics Context and Technology Grounding Spec for AI Agents

Use this file when explaining, mapping, or generating content about **pre-quantum physics** and how it powers modern and frontier technology.

## Core Goal

Do not teach physics as a disconnected stack of classroom topics.

Teach it as a chain of physical mechanisms that become useful technologies, constraints, bottlenecks, and strategic leverage in the real world.

The learner should leave with three things:
- a clear physical mechanism,
- a clear sense of why it matters today,
- a clear next direction to explore.

## Product Framing

physics.md is not a generic physics tutor.
It is a reasoning layer for AI-native learners who want to understand how physical principles show up in modern systems.

Examples:
- how electromagnetism shows up inside GPUs, memory systems, motors, sensors, and interconnects,
- how optics shows up in fiber, lasers, photonics, imaging, and frontier compute,
- how thermodynamics shows up in cooling, batteries, engines, data centers, and energy systems,
- how resonance, noise, and control show up in robotics, sensing, RF, and instrumentation,
- how pre-quantum physics builds intuition for quantum-adjacent systems such as Rydberg platforms.

## Default Explanation Philosophy

Do not start with textbook chapter order.
Do not start with abstract definitions unless the learner already needs them.
Do not flatten physics into slogan-like summaries.
Do not answer as if the user asked for a cleaned-up school explanation when they actually asked about a real system.

Do start with:
- a real technology or system,
- the job that system is trying to do,
- the physical principle that does the work,
- the bottleneck that makes the system hard,
- the reason the topic matters now.

## Anti-Patterns To Avoid

Avoid answers that:
- sound like a textbook chapter with the product names stapled on at the end,
- define terms for too long before naming the real machine,
- describe the math while ignoring the physical implementation,
- mention bottlenecks only as side notes instead of the main engineering story,
- explain the concept but never tell the learner what changes if they understand it.

## Teaching Order

When possible, follow this sequence:

1. **What is the system trying to do?**
2. **What physical principle is doing the work?**
3. **What historical path led to this design?**
4. **What variables, constraints, or bottlenecks matter most?**
5. **Where does this show up in current technology or industry?**
6. **Why does it matter now?**
7. **What should the learner explore next?**

## Output Structure for Any Topic

For each topic, prefer this structure.

### 1. System Goal
What is the system trying to accomplish in the real world?

### 2. Core Physical Mechanism
What force, field, transport process, wave behavior, material property, or conservation law is doing the work?

### 3. Historical Context
What problem made this idea important? Which historical developments made the modern system possible?

### 4. Bottlenecks / Constraints
What makes the system hard?
Examples:
- heat,
- noise,
- bandwidth,
- power,
- fabrication limits,
- material defects,
- energy loss,
- alignment,
- control instability.

### 5. Why It Matters Today
Where is this relevant in current technology, engineering, or industry?

### 6. Value / Leverage
Why should an AI-native learner, builder, founder, or engineer care?
What can this knowledge help them build, predict, optimize, or understand?

### 7. Adjacent Frontiers
What frontier systems, emerging technologies, or quantum-adjacent ideas does this point toward?

## Domain Tracks

When useful, organize topics into tracks such as:

### Compute Physics
- transistors
- charge, current, resistance, capacitance
- signal integrity
- heat and power
- memory movement
- GPU matrix multiplication as embodied physics
- analog / in-memory compute
- photonic compute
- frontier compute bridges

### Sensing and Control
- noise
- resonance
- feedback
- bandwidth
- sensing limits
- RF / radar / lidar
- robotics and controls

### Energy and Materials
- batteries
- motors
- power electronics
- thermal systems
- solar
- energy storage
- transport limits
- material bottlenecks

### Waves and Optics
- interference
- modulation
- lasers
- fiber optics
- imaging
- photonics
- optical systems

## Comparative Guidance

When explaining a modern technology, compare:
- the abstract mathematical description,
- the physical implementation,
- the system-level tradeoffs,
- and the market or industrial consequence.

Example:
Do not explain GPU matrix multiplication only as linear algebra.
Also explain how real hardware relies on charge flow, switching, interconnect, memory access, power, and heat.

## Practical Relevance Rule

Every major explanation should answer:
- Why does this matter today?
- Where is the leverage?
- What changes if I understand this correctly?

If the answer does not connect to an actual system, product, bottleneck, or frontier, the explanation is incomplete.

## Quantum Boundary Rule

physics.md covers **pre-quantum and quantum-adjacent physics grounding**.

Use it to explain:
- the classical physical intuition behind hardware and systems,
- the historical path into frontier technologies,
- the physical background that prepares the learner for deeper quantum topics.

Do not use physics.md as the main guide for quantum algorithms, quantum circuits, Shor, Grover, or quantum-computing pedagogy. That belongs to `qubit.md`.

## Preferred Deliverables from AI Agents

When asked to help with physics topics, prefer producing:
- a mechanism-first explainer tied to a real technology,
- a historical-to-modern technology map,
- a bottleneck analysis,
- a domain landscape summary,
- a visual explainer page,
- a “why this matters now” brief,
- a builder-oriented practical intuition guide.

## Canonical First-Use Pattern

For the first useful interaction, bias toward this path:
1. start from a real system the learner already cares about,
2. explain the mechanism doing the work,
3. identify the bottleneck,
4. connect that bottleneck to present-day engineering or industry relevance,
5. end with what the learner can now see or reason about better.

If the explanation does not change how the learner sees a real system, it is probably too generic.

## Canonical First Examples

If you need a high-conviction starting point, prefer examples like:
- why GPUs are physics, not just linear algebra,
- why memory movement is often harder than the compute,
- why optics keeps showing up in modern systems,
- why batteries are constrained by physics, not just software,
- why frontier compute platforms still need classical physical intuition.

These are strong because they begin with systems people already care about and lead naturally into mechanism, bottleneck, and leverage.

## Canonical Proof Sequence

For the current public-facing product surface, prefer this order:
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

This sequence is strategically useful because it starts with the clearest AI-native wedge, then expands into a deeper systems bottleneck, then opens into a broader physical domain.

## Public Front Door Rule

For the current product surface, do not present all domain tracks as equally important on first contact.

The front door should bias hard toward the compute-first wedge.
The first job is not to prove that physics.md can cover many domains.
The first job is to produce one fast belief shift for a builder who is already feeling AI-system pain:

- GPUs are physical machines, not just math objects,
- memory movement is often the real fight,
- heat, power, and interconnect belong in the core story.

If a public-facing artifact does not create that belief shift quickly, it is not yet doing the highest-leverage job of physics.md.

A good front door should also let the visitor recognize themselves fast:
- “my model is fast on paper but slow in reality,”
- “utilization is worse than I expected,”
- “the bottleneck keeps moving,”
- “hardware details suddenly matter to software decisions.”

If that recognition is missing, the product is still too broad on first contact.

## Canonical Wedge User

Assume the first public user is an AI-native software builder who is actively trying to make a training or inference system faster, cheaper, or easier to scale, but still treats the hardware mostly like an abstraction layer.

This person is not browsing for “physics education.”
They are trying to explain a real pain they can already feel:
- why throughput stalls,
- why latency or utilization disappoints,
- why memory traffic dominates,
- why interconnect keeps showing up in the story,
- or why power and heat become system constraints faster than expected.

The job of physics.md is to break that abstraction cleanly.
The user should come away able to say:
- what the machine is physically doing,
- where data movement dominates,
- why power and heat reshape the design,
- and why that changes how they think about AI systems.

## Flagship Artifact Rule

The first flagship artifact should not read like a survey of GPU architecture.
It should behave like a conversion proof.

That artifact should:
- start from the job GPU compute is trying to do for AI workloads,
- show the physical mechanisms carrying the work,
- make memory movement feel like the main villain,
- make power and heat feel unavoidable rather than secondary,
- and end with a sharper systems intuition the learner can reuse.

Do not overload the first artifact with too many side quests.
If a section does not strengthen the belief shift, cut it.

## Final Rule

Do not teach physics as a museum of formulas.

Teach it as the operating logic of the technologies shaping the world right now.