A visual research report · 1480s → 1986

Engineering sketches
become living studies.

A drawing holds a theory of how something works. A Napkin study adds the quantities, assumptions and checks needed to test one part of that theory.

Explore fourteen artifacts, then follow a concrete chat workflow for each. The models use modern illustrative inputs: they answer sizing questions without claiming to reconstruct the original machines.

Explore the drawings ↓

14 source artifacts70 chat steps14 checked models

Leonardo’s water-machine studies in the Codex Atlanticus — Leonardo da Vinci · water mechanisms · c. 1480–1482
Codex Atlanticus f. 1069r · Biblioteca Ambrosiana ↗

What counts as a “napkin”?

Here, “napkin” means a compact piece of engineering reasoning. This curated archive contains one manuscript, one laboratory notebook, one later published illustration and eleven patent drawings. It is a lineage of ways to reason, rather than a complete history of invention. Dates below belong to the visible artifacts; patent dates are grants. Earlier design dates appear separately.

01 · The archive

Follow the engineering thought.

Select a drawing to see its source,
decision question and five chat exchanges.

Find a drawingEngineering domainArtifact type14 drawings

Biblioteca Ambrosiana · c. 1480–1482
Manuscript · Source record ↗

01 / 14 · Water + motion

Water-raising machines

Leonardo da Vinci

Codex Atlanticus, folio 1069r. Pen, ink and wash studies of water-raising mechanisms, screw forms and a siphon bucket. This sheet records several mechanisms rather than one finished machine. [Source]

What the drawing teaches

A mechanism drawing can become a power budget before its gears become detailed geometry.

The contemporary study

How much shaft power lifts a chosen water flow?

Flow, lift height, efficiency → shaft power → drive check.

Scope boundary. A steady hydraulic power budget; no gear motion, cavitation or pump curve. Efficiency is assumed.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Water-raising machines — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve pump topology and the water-lift intention; never infer dimensions from the folio. The engineering question is: How much shaft power lifts a chosen water flow? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Flow, lift height, efficiency → shaft power → drive check.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "davinci". Explain pumpPower and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
Does required power exceed 200 W at 5 L/s? Which input dominates? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for pumpPower versus flow. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Measure flow, lift and input torque/speed on a bench pump; compare power and losses. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

130.8 WpumpPower

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

rho = 1000 kg/m^3 "Illustrative water density"
g = 9.81 m/s^2
flow = 0.002 m^3/s in 0.001..0.005 ± 10% "Modern illustrative flow"
head = 3 m "Assumed lift height"
efficiency = 0.45 "Assumed overall efficiency"
pumpPower := rho*g*flow*head/efficiency [W]
check drive: pumpPower <= 200 W
sweep Flow: flow = 0.001, 0.002, 0.005 m^3/s

Library of Congress, Manuscript Division · 10 March 1876
Notebook · Source record ↗

02 / 14 · Signals + timing

Liquid transmitter

Alexander Graham Bell

Laboratory notebook, pages 40–41, associated with the intelligible transmission experiment. This is an experimental record with an apparatus drawing, rather than a patent sheet. [Source]

What the drawing teaches

Preserve the measured observation alongside the apparatus. A DC resistance model isolates one link in the sound-to-signal chain.

The contemporary study

How large is a static current change from a resistance perturbation?

Supply, series resistance, transmitter resistance and a perturbation → two DC operating points.

Scope boundary. A pair of DC points; no acoustics, diaphragm motion, waveform, intelligibility or transient circuit simulation.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Liquid transmitter — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the notebook entry and liquid-transmitter drawing; mark sound-to-resistance coupling as unresolved. The engineering question is: How large is a static current change from a resistance perturbation? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Supply, series resistance, transmitter resistance and a perturbation → two DC operating points.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "bell". Explain signalChange and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
How large must the resistance change be to produce 0.2 mA? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for signalChange versus deltaResistance. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Measure static resistance versus contact displacement and compare the predicted current difference. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

0.01 Abaseline0.009677 Aperturbed0.3226 mAsignalChange

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

voltage = 3 V "Illustrative bench supply"
seriesResistance = 100 ohm
transmitterResistance = 200 ohm "Illustrative nominal liquid-contact resistance"
deltaResistance = 10 ohm in 1..30 "Small imposed resistance change"
baseline := voltage/(seriesResistance+transmitterResistance) [A]
perturbed := voltage/(seriesResistance+transmitterResistance+deltaResistance) [A]
signalChange := abs(perturbed-baseline) [mA]
check measurable: signalChange >= 0.2 mA
sweep Contact: deltaResistance = 1, 10, 30 ohm

R. H. Thurston, 1878 · 1878 · 1784 design
Published illustration · Source record ↗

03 / 14 · Water + motion

Separate-condenser engine

Boulton & Watt / R. H. Thurston

Thurston’s 1878 illustration depicts a Boulton & Watt engine design from 1784. It shows cylinder, valves, beam linkage, pumps and governor. It is a retrospective illustration, not Watt’s original condenser sketch. [Source]

What the drawing teaches

Separate the pressure-to-work calculation from the thermal explanation. The engine layout alone cannot supply its operating pressure.

The contemporary study

What shaft power follows from an assumed mean effective pressure?

Mean effective pressure, displaced volume and stroke frequency → indicated work → shaft power.

Scope boundary. Not a steam cycle or condenser heat-transfer model. Mean effective pressure must come from evidence.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Separate-condenser engine — illustrative sizing”. Keep the attached historical drawing as a source reference. Label the source as an 1878 published engraving of a 1784 design, and retain the condenser idea. The engineering question is: What shaft power follows from an assumed mean effective pressure? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Mean effective pressure, displaced volume and stroke frequency → indicated work → shaft power.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "watt". Explain shaftPower and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
What mean effective pressure makes the 2 kW check pass? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for shaftPower versus pressure. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Compare with a measured indicator diagram, actual displacement and brake power. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

1500 Jwork2400 WshaftPower

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

pressure = 150 kPa in 100..200 ± 10% "Assumed mean effective pressure"
swept = 0.01 m^3 "Assumed swept volume per working stroke"
strokes = 2 Hz "Power strokes per second, not shaft rpm"
efficiency = 0.8 "Assumed mechanical efficiency"
work := pressure*swept [J]
shaftPower := work*strokes*efficiency [W]
check output: shaftPower >= 2000 W
sweep Pressure: pressure = 100, 150, 200 kPa

U.S. National Archives · 27 January 1880
Patent drawing · Source record ↗

04 / 14 · Electricity

Carbon-filament lamp

Thomas A. Edison

US223898, Electric Lamp: a carbon filament, sealed evacuated enclosure and electrical leads. The patent combines these elements; it is not evidence that electric light began with this disclosure. [Source]

What the drawing teaches

A lamp is an electrical, thermal and materials system. Start with the supply and hot resistance, then identify the missing thermal evidence.

The contemporary study

What current and power does an assumed hot filament draw?

Operating voltage and hot resistance → current and electrical power → supply checks.

Scope boundary. DC electrical sizing only; no radiation, temperature-dependent resistance, vacuum physics, brightness or lifetime prediction.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Carbon-filament lamp — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the patent structure and filament-support intent; do not estimate temperature from the image. The engineering question is: What current and power does an assumed hot filament draw? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Operating voltage and hot resistance → current and electrical power → supply checks.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "edison". Explain power and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
Which resistance values stay below both 60 W and 0.6 A? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for power versus resistance. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Measure hot resistance and supply power; use optical and thermal measurements for brightness and lifetime. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

0.5 Acurrent50 Wpower

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

voltage = 100 V "Illustrative modern supply assumption"
resistance = 200 ohm in 100..400 ± 10% "Assumed operating-temperature resistance"
current := voltage/resistance [A]
power := voltage*current [W]
check powerBudget: power <= 60 W
check currentBudget: current <= 0.6 A
sweep Filament: resistance = 100, 200, 400 ohm

Nikola Tesla · US381968 · 1 May 1888
Patent drawing · Source record ↗

05 / 14 · Electricity

Rotating-field motor

Nikola Tesla

US381968, Electro-Magnetic Motor, sheet 1. Electrical phase arrangements produce progression of magnetic poles and rotor motion; the sheet combines circuits with physical layout. [Source]

What the drawing teaches

Translate field motion into synchronous speed. Treat slip as a measured or assumed input until a richer motor model is available.

The contemporary study

How do assumed slip and mechanical output set shaft speed and torque?

Supply frequency and pole count → synchronous angular speed → slip-adjusted shaft speed → torque.

Scope boundary. Slip and output power are independent assumptions; no electromagnetic field solve, starting torque or torque-slip prediction.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Rotating-field motor — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the rotating-field winding idea; separate the conceptual motor from any later machine rating. The engineering question is: How do assumed slip and mechanical output set shaft speed and torque? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Supply frequency and pole count → synchronous angular speed → slip-adjusted shaft speed → torque.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "tesla". Explain torque and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
How does increasing assumed slip alter the torque for a fixed 500 W shaft output? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for torque versus slip. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Compare tachometer and dynamometer measurements and the motor datasheet. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

157.1 rad/ssyncOmega150.8 rad/sshaftOmega3.316 N*mtorque

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: passed.
A failed check is a design result, not a syntax failure.

frequency = 50 Hz "Illustrative supply frequency"
poles = 4 "Assumed total magnetic poles"
slip = 0.04 in 0.01..0.1 "Assumed motoring slip"
power = 500 W "Assumed mechanical shaft output"
syncOmega := 4*pi*frequency/poles [rad/s]
shaftOmega := syncOmega*(1-slip) [rad/s]
torque := power/shaftOmega [N*m]
check torqueBudget: torque <= 4 N*m
sweep Slip: slip = 0.01, 0.04, 0.1

Orville & Wilbur Wright · US821393 · 22 May 1906
Patent drawing · Source record ↗

06 / 14 · Flight + propulsion

Wing-warping aircraft

Orville & Wilbur Wright

US821393, Flying-Machine, sheet 1. Filed in 1903, it emphasizes equilibrium, wing deformation and coordinated control. The visible artifact shows a glider/control architecture, not the powered 1903 Flyer. [Source]

What the drawing teaches

Lift sizing gives a useful first gate, but a passing lift check says nothing about whether wing warping restores equilibrium.

The contemporary study

What airspeed gives enough idealized lift for an assumed mass?

Air density, speed, lifting area and assumed lift coefficient → lift compared with weight.

Scope boundary. Steady lift sizing only; no wing-warping control effectiveness, stall, stability, biplane interference or CFD.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Wing-warping aircraft — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the wing-warping control concept and patent date; keep the drawing distinct from the 1903 flight. The engineering question is: What airspeed gives enough idealized lift for an assumed mass? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Air density, speed, lifting area and assumed lift coefficient → lift compared with weight.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "wright". Explain lift and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
At what speed does this fixed-CL model first carry the assumed mass? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for lift versus speed. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Replace CL with wind-tunnel or flight measurements; compare lift and inspect stall behavior. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

2943 Nweight2117 Nlift

Verified with the repository’s parser and analytic evaluator.
Baseline checks: failed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

rho = 1.225 kg/m^3 "Illustrative air density"
speed = 12 m/s in 8..18 ± 5% "Illustrative flight speed"
area = 30 m^2 "Assumed lifting area"
CL = 0.8 "Assumed lift coefficient"
mass = 300 kg "Assumed all-up mass"
weight := mass*9.81 m/s^2 [N]
lift := 0.5*rho*speed^2*area*CL [N]
check support: lift >= weight
sweep Speed: speed = 8, 12, 18 m/s

Robert H. Goddard · US1102653 · 7 July 1914
Patent drawing · Source record ↗

07 / 14 · Flight + propulsion

Multistage rocket

Robert H. Goddard

US1102653, Rocket Apparatus, sheet 1. The disclosure describes solid explosive disks, a primary rocket and an auxiliary rocket. This is staged solid-charge apparatus, distinct from Goddard’s 1926 liquid-fuel flight. [Source]

What the drawing teaches

A staged system needs an explicit mass-accounting boundary. An ideal velocity budget is one question; successful staging is another.

The contemporary study

What ideal velocity budget results from two assumed stage mass ratios?

Two dimensionless stage mass ratios and effective exhaust speed → summed ideal delta-v.

Scope boundary. Ideal rocket equation only; no gravity or drag losses, burn timing, structural staging feasibility or trajectory integration.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Multistage rocket — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the 1914 staged apparatus; do not relabel it as the 1926 liquid-fuel rocket. The engineering question is: What ideal velocity budget results from two assumed stage mass ratios? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Two dimensionless stage mass ratios and effective exhaust speed → summed ideal delta-v.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "goddard". Explain totalDeltaV and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
Does the ideal 3.5 km/s budget survive a lower assumed effective exhaust speed? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for totalDeltaV versus exhaustSpeed. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Build a consistent stage mass budget, then compare engine-test effective exhaust speed and an external trajectory analysis. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

2197 m/sstage11386 m/sstage23584 m/stotalDeltaV

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

exhaustSpeed = 2000 m/s in 1500..2500 "Illustrative effective exhaust speed"
ratio1 = 3 "Assumed wet-to-final mass ratio for stage one"
ratio2 = 2 "Assumed wet-to-final mass ratio for stage two"
stage1 := exhaustSpeed*log(ratio1) [m/s]
stage2 := exhaustSpeed*log(ratio2) [m/s]
totalDeltaV := stage1+stage2 [m/s]
check budget: totalDeltaV >= 3500 m/s
sweep Exhaust: exhaustSpeed = 1500, 2000, 2500 m/s

Frank Whittle · US2168726 · 8 August 1939
Patent drawing · Source record ↗

08 / 14 · Flight + propulsion

Turbojet flow path

Frank Whittle

US2168726, Propulsion of Aircraft and Gas Turbines, sheet 1. The cross-section links compression, combustion, turbine drive and propulsive discharge. This displayed US patent is dated 1939, not the earlier British filing. [Source]

What the drawing teaches

Flow components must balance momentum and energy as well as fit. Begin with the exit conditions, then ask where those conditions come from.

The contemporary study

What momentum thrust follows from assumed inlet and exit conditions?

Air and fuel mass flows, flight speed, exhaust speed and pressure thrust → net momentum thrust.

Scope boundary. An algebraic momentum balance; no compressor/turbine matching, combustion, thermal cycle or CFD.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Turbojet flow path — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the flow-path concept and identify the actual 1939 US patent sheet. The engineering question is: What momentum thrust follows from assumed inlet and exit conditions? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Air and fuel mass flows, flight speed, exhaust speed and pressure thrust → net momentum thrust.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "whittle". Explain thrust and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
How much does the 3.5 kN check depend on assumed exit speed? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for thrust versus exitSpeed. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Compare measured mass flow and net thrust; obtain exit conditions from an external cycle calculation or test. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

3590 Nthrust

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

airflow = 10 kg/s "Illustrative inlet air mass flow"
fuelFlow = 0.2 kg/s "Illustrative fuel mass flow"
flightSpeed = 100 m/s
exitSpeed = 450 m/s in 350..550 "Assumed exhaust speed"
pressureThrust = 0 N "Assumed pressure-matched exhaust"
thrust := (airflow+fuelFlow)*exitSpeed-airflow*flightSpeed+pressureThrust [N]
check thrustBudget: thrust >= 3500 N
sweep Exhaust: exitSpeed = 350, 450, 550 m/s

Hedy Kiesler Markey & George Antheil · US2292387 · 11 August 1942
Patent drawing · Source record ↗

09 / 14 · Signals + timing

Synchronized frequency hopping

Hedy Lamarr & George Antheil

US2292387, Secret Communication System, credits Hedy Kiesler Markey and George Antheil. Matched record mechanisms coordinate transmitter and receiver frequency changes for remote control. This is not a modern Wi-Fi implementation. [Source]

What the drawing teaches

Timing agreement is an engineering requirement. Budget dwell, retuning and uncertainty before claiming a usable communication channel.

The contemporary study

How much time remains after retuning and synchronization allowances?

Dwell, settling and synchronization-error allowance → usable time and duty fraction.

Scope boundary. Static timing budget only; no generated hop sequence, RF propagation, modulation, interference resilience or security claim.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Synchronized frequency hopping — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve coordinated transmitter/receiver switching; avoid claiming a modern digital protocol reconstruction. The engineering question is: How much time remains after retuning and synchronization allowances? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Dwell, settling and synchronization-error allowance → usable time and duty fraction.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "lamarr". Explain usableDwell and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
What retuning delay leaves at least 10 ms of usable dwell? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for usableDwell versus settling. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Measure tuning settle time and clock misalignment; inspect a radio trace with external tools. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

16 msusableDwell0.8 dutyFraction

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: passed.
A failed check is a design result, not a syntax failure.

dwell = 20 ms "Illustrative dwell per channel"
settling = 2 ms in 1..6 "Assumed radio retuning time"
syncError = 1 ms "Assumed worst timing misalignment"
usableDwell := dwell-settling-2*syncError [ms]
dutyFraction := usableDwell/dwell
check usefulTime: usableDwell >= 10 ms
check positiveBudget: dutyFraction >= 0
sweep Retune: settling = 1, 2, 6 ms

R. Buckminster Fuller · US2682235 · 29 June 1954
Patent drawing · Source record ↗

10 / 14 · Structures + materials

Geodesic structure

R. Buckminster Fuller

US2682235, Building Construction, sheet 1. Repeated structural members organize an approximately spherical enclosure. The drawing supports a geometric construction rule, not a universal priority claim for geodesic geometry. [Source]

What the drawing teaches

Local member geometry can build a global shell; local stress cannot by itself establish global stability.

The contemporary study

What axial stress follows for one idealized loaded strut?

An externally supplied strut force, section area and allowable stress → axial stress and margin.

Scope boundary. Single-member axial stress only; not a dome stiffness solve, FEA, buckling check or code-compliant building design.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Geodesic structure — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the triangulated dome topology; treat load-sharing as an unresolved structural question. The engineering question is: What axial stress follows for one idealized loaded strut? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: An externally supplied strut force, section area and allowable stress → axial stress and margin.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "fuller". Explain stress and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
Which supplied axial loads meet both stress and 1.5 margin checks? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for stress versus force. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Use a structural analysis to obtain member forces; compare coupon, joint and buckling tests. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

20 MPastress2.5 margin

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

force = 2000 N in 1000..4000 "Assumed axial force from external load analysis"
area = 100 mm^2 "Assumed strut cross-sectional area"
allowable = 50 MPa "Illustrative material stress allowance"
stress := force/area [MPa]
margin := allowable/stress
check material: stress <= allowable
check marginBudget: margin >= 1.5
sweep Load: force = 1000, 2000, 4000 N

George de Mestral · US2717437 · 13 September 1955
Patent drawing · Source record ↗

11 / 14 · Structures + materials

Hook-and-loop fastening

George de Mestral

US2717437, Velvet Type Fabric and Method of Producing Same. The disclosure describes manufactured fabric and engaging hook formation. “Hook-and-loop” names the mechanism; VELCRO is a trademark. [Source]

What the drawing teaches

Turn a material mechanism into an empirical load-per-area rule. The measurement conditions matter as much as the chosen area.

The contemporary study

How large a bonded engagement area carries an assumed shear load?

Engaged area, empirical shear strength, load and a sizing factor → shear capacity check.

Scope boundary. Uniform static shear with an empirical strength; no peel mechanics, individual hook contact, fatigue or textile modeling.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Hook-and-loop fastening — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve hook/loop engagement intent and the 1955 patent; avoid implying trademark endorsement. The engineering question is: How large a bonded engagement area carries an assumed shear load? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Engaged area, empirical shear strength, load and a sizing factor → shear capacity check.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "demestral". Explain capacity and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
What area passes, and how sensitive is the answer to measured shear strength? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for capacity versus area. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Obtain product-specific shear and peel tests, aging and repeated-engagement data. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

100 Ncapacity100 Nrequired

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

area = 20 cm^2 in 5..40 "Illustrative engaged area"
shearStrength = 5 N/cm^2 ± 20% "Assumed tested shear capacity per area"
load = 50 N "Illustrative application load"
safety = 2 "Assumed sizing factor"
capacity := area*shearStrength [N]
required := load*safety [N]
check hold: capacity >= required
sweep Engagement: area = 5, 20, 40 cm^2

Jack S. Kilby · US3138743 · 23 June 1964
Patent drawing · Source record ↗

12 / 14 · Electricity

Miniaturized circuit

Jack S. Kilby

US3138743, Miniaturized Electronic Circuits, sheet 2, figures 6a/6b. Physical layout and equivalent circuit appear together. This is a patent substitute for the 1958 notebook; the key view was published sideways. [Source]

What the drawing teaches

Keep physical arrangement and circuit topology distinct. A generic RC proxy tests one miniaturization tradeoff without pretending to reconstruct this circuit.

The contemporary study

How does assumed lumped parasitic capacitance limit a simple RC response?

Assumed resistance and lumped capacitance → ideal one-pole time constant, rise-time estimate and cutoff.

Scope boundary. A generic one-pole proxy motivated by miniaturization, not the patent circuit reconstructed or simulated. No SPICE or transistor model.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Miniaturized circuit — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the actual 1964 patent sheet and flying-wire/equivalent circuit images; distinguish the 1958 demonstration. The engineering question is: How does assumed lumped parasitic capacitance limit a simple RC response? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Assumed resistance and lumped capacitance → ideal one-pole time constant, rise-time estimate and cutoff.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "kilby". Explain timeConstant and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
Which capacitance values meet both a 100 ns rise-time budget and 5 MHz cutoff? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for timeConstant versus capacitance. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Compare measured capacitance and oscilloscope response; validate the full circuit in an external circuit tool. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

20 nstimeConstant44 nsriseTime7.958 MHzfrequencyLimit

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

resistance = 1000 ohm "Illustrative circuit resistance"
capacitance = 20 pF in 5..100 "Assumed lumped capacitance"
timeConstant := resistance*capacitance [ns]
riseTime := 2.2*timeConstant [ns]
frequencyLimit := 1/(2*pi*timeConstant) [MHz]
check edge: riseTime <= 100 ns
check bandwidth: frequencyLimit >= 5 MHz
sweep Parasitic: capacitance = 5, 20, 100 pF

Douglas C. Engelbart · US3541541 · 17 November 1970
Patent drawing · Source record ↗

13 / 14 · Signals + timing

X–Y position indicator

Douglas C. Engelbart

US3541541, X-Y Position Indicator for a Display System, sheet 1. Orthogonal wheels turn hand motion into display-position signals. This artifact is the patent drawing, not an image from the 1968 demonstration. [Source]

What the drawing teaches

Resolve motion into independent coordinates, then ask how wheel geometry sets the smallest displacement you can report.

The contemporary study

What surface displacement corresponds to one wheel-encoder count?

Wheel diameter and encoder counts → wheel circumference and displacement per count.

Scope boundary. Ideal no-slip wheel kinematics; no friction/contact solve, direction-decoding electronics or usability prediction.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “X–Y position indicator — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the orthogonal-wheel X–Y measurement concept rather than substituting a later optical mouse. The engineering question is: What surface displacement corresponds to one wheel-encoder count? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Wheel diameter and encoder counts → wheel circumference and displacement per count.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "engelbart". Explain stepSize and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
How does wheel diameter change spatial resolution at fixed encoder counts? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for stepSize versus wheelDiameter. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Roll a measured distance; compare counts in both directions and assess slip. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

0.6283 mmstepSize62.83 mmcircumference

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: passed.
A failed check is a design result, not a syntax failure.

wheelDiameter = 20 mm in 10..30 "Illustrative rolling wheel diameter"
counts = 100 "Assumed counts per revolution"
stepSize := pi*wheelDiameter/counts [mm]
circumference := pi*wheelDiameter [mm]
check resolution: stepSize <= 1 mm
probe resolutionValue: stepSize [mm]
sweep Wheel: wheelDiameter = 10, 20, 30 mm

James Dyson · US4593429 · 10 June 1986
Patent drawing · Source record ↗

14 / 14 · Water + motion

Cyclonic vacuum cleaner

James Dyson

US4593429, Vacuum Cleaning Appliance, sheet 1. Airflow links the cleaning head, cyclone arrangements, dust collection and cleaner body. The drawing does not establish a particular number of prototypes. [Source]

What the drawing teaches

Follow the airflow and its pressure losses. A fan-power budget is useful even while particle separation needs measurement or a richer model.

The contemporary study

How much fan shaft power supports an assumed flow and pressure drop?

Flow, assumed measured system pressure drop and efficiency → required shaft power.

Scope boundary. Steady power budget; no cyclone separation efficiency, particle trajectories, fouling evolution or CFD. Pressure drop and efficiency may vary with flow.

Historical idea → contemporary chat workflow

Five exchanges to make it testable.

The prompts below reinterpret the engineering question. They are not reconstructed historical conversations.

01
Preserve the source and the question
Create a Napkin study called “Cyclonic vacuum cleaner — illustrative sizing”. Keep the attached historical drawing as a source reference. Preserve the appliance layout and airflow path from the 1986 patent; avoid trademark endorsement. The engineering question is: How much fan shaft power supports an assumed flow and pressure drop? Do not invent historical dimensions or ratings.
napkin_capabilities → napkin_create → napkin_snapshot; optional napkin_edit set-drawing for source metadata.
02
Separate facts from assumptions
List what the source supports, what is uncertain, and what must be measured. For this first pass use clearly labeled modern illustrative values, never historical measurements. Model this chain: Flow, assumed measured system pressure drop and efficiency → required shaft power.
Input quantities carry units, ranges, tolerances and assumption strings. Derived quantities retain equations.
03
Encode the compact sketch model
Use napkin_sketch to apply the following text to the study with the current expectedRevision and prefix "dyson". Explain shaftPower and open the study. These numbers are illustrative assumptions.
napkin_snapshot → napkin_sketch → napkin_explain → napkin_open; scalar code below.
04
Ask a decision question
What airflow stays within 300 W if the assumed pressure drop holds? Run the named scalar sweep in analytic mode and use napkin_analyze sensitivity for shaftPower versus flow. Report units, the check outcomes and assumptions; keep baseline inputs unchanged.
napkin_run for the sweep; napkin_analyze kind=sensitivity using returned quantity refs.
05
Compare against evidence and revise
Measure pressure drop against flow, fan curve and dust-collection performance; replace constants with evidence. Attach test or external-analysis evidence as source references. Compare like-for-like conditions, explain any discrepancy, and revise only inputs justified by that evidence. Report what the model still cannot answer.
napkin_explain → evidence reference via napkin_edit → revision-checked input update → rerun; prior runs become stale.

Step 03 · paste alongside the prompt

A runnable sketch model

Every number is a modern illustrative assumption, not a historical reconstruction.

= defines inputs; := defines derived quantities; check states the decision threshold; sweep changes one input across scalar cases.

240 WshaftPower

Verified with the repository’s parser and analytic evaluator.
Baseline checks: passed · three-case sweep checks: failed.
A failed check is a design result, not a syntax failure.

flow = 0.03 m^3/s in 0.01..0.05 "Illustrative operating airflow"
pressureDrop = 4000 Pa ± 20% "Assumed measured total system loss"
efficiency = 0.5 "Assumed fan efficiency at operating point"
shaftPower := flow*pressureDrop/efficiency [W]
check motorBudget: shaftPower <= 300 W
probe fanPower: shaftPower [W]
sweep Airflow: flow = 0.01, 0.03, 0.05 m^3/s

02 · One discipline across fourteen domains

Keep the source, drawing and model distinct.

A source image is evidence.

The scalar sketch text creates analytical records; it does not create a drawing of the historical mechanism. Add coarse linked geometry separately with napkin_edit when actual dimensions are available. The image tells you what was depicted. It does not supply unknown dimensions, performance curves or test results. Store its URL and description as a source reference. If a linked Napkin drawing is added, its dimensions and transforms must come from explicit model bindings.

An equation is a claim you can inspect.

These examples use supported unit-aware scalar expressions, checks, sweeps and sensitivity. They do not require recognizing a scanned patent as geometry. A schematic can explain topology while the analytical quantities remain explicit.

Give every input a provenance.

Source-supported: what the cited artifact actually establishes. Measured: a value with test conditions, instrument and uncertainty. Assumed: an illustrative value awaiting evidence. Derived: an equation with named inputs. Every numeric input in this report belongs to the assumed category, including constants adopted for the exercise.

A sweep is a question, not a baseline edit.

Run the saved scenario and inspect all cases. A failed threshold at one case is useful information. Sensitivity reports a local numerical derivative; it does not prove validity outside the model’s stated assumptions.

Discovernapkin_capabilitiesCreate + inspectnapkin_create → napkin_snapshotEncode + explainnapkin_sketch → napkin_explain → napkin_openAsk + verifynapkin_run → napkin_analyzeEvidence + revisionnapkin_edit → snapshot → rerun

Revision discipline. Read the current snapshot before a mutation and pass its revision as expectedRevision. Use returned study, scenario and quantity references; do not invent IDs. Reuse the same sketch prefix for an update, and inspect any obsolete entities rather than assuming they disappear. After an edit, previous run results refer to an older revision and must be rerun. Discover the installed capabilities first: a cached plugin may lag behind this repository.

Technical basis: package guide, sizing analysis, local plugin guide. Local reference snapshots accompany this report. The package guide contains a legacy 0.5.0 version label; executable examples were checked against this repository’s 0.6.1 source. Full numerical validation traces retain all fourteen runs.

A small consequence you can change

Lift rises with speed squared.

For the Wright-inspired study, fixed illustrative inputs are density 1.225 kg/m³, area 30 m², lift coefficient 0.8 and mass 300 kg. Move only airspeed. This steady lift budget does not assess wing-warping control or stall.

Standalone report calculator · not connected to Napkin MCP.

Illustrative airspeed 12 m/s

Idealized lift2,117 NWeight2,943 N

✕ Lift is below assumed weight

L = ½ ρ v² S C_L · crossing ≈ 14.15 m/s

03 · Build a useful first study

Begin where evidence is easiest to collect.

01 · Start with a bench check

Water power or wheel resolution

Leonardo’s power budget and Engelbart’s wheel geometry use directly measurable inputs. Change flow or diameter, inspect one output and compare it with a bench measurement. You can close the evidence loop quickly.

Open water-power study ↗

02 · Add empirical behavior

Resistance, pressure loss or shear

Bell, Edison, Dyson and de Mestral bring in values that vary with operating conditions. Keep the assumed constant visible; then replace it with a measurement at the matching operating point.

Open fan-power study ↗

03 · Expand the model boundary

Control, fields, cycles or structure

Wright, Tesla, Whittle, Goddard and Fuller expose what a scalar model leaves unresolved. Establish a sizing baseline, then take stability, field behavior, thermal matching or structural integrity to specialist analysis and tests.

Open flight study ↗

The best first study has one decision, a short chain of equations and a measurement that could prove an assumption wrong. The historical drawing supplies the question. Your evidence makes the contemporary model useful.

Engineering sketchesbecome living studies.

Follow the engineering thought.

Water-raising machines

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Liquid transmitter

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Separate-condenser engine

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Carbon-filament lamp

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Rotating-field motor

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Wing-warping aircraft

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Multistage rocket

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Turbojet flow path

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Ask a decision question

Compare against evidence and revise

A runnable sketch model

Synchronized frequency hopping

The contemporary study

Five exchanges to make it testable.

Preserve the source and the question

Separate facts from assumptions

Encode the compact sketch model

Engineering sketches
become living studies.