IDETC teaching slides: plain-language drop-test explainers (#94)

[sgbaird]

Addresses #94.

Adds presentation/idetc-2026-teaching/: two jargon-free teaching figures built from a real drop (57vqhX_Signal50.csv, corrected J211 CFC filter, pre-trigger baseline), the title-anchored script that inserts them as slides with full speaker-note talk tracks, and a README.

The edited deck was uploaded to SharePoint ("IDETC Tensegrity Slides Draft 1.pptx", v31.0); the idetc-2026.pptx share link is read-only, so run add_teaching_slides.py on it to apply the same insertion.

Generated with Claude Code

[sgbaird]

@claude your PPT_EDIT_LINK, at least now, is definitely going to idetc-2026.pptx, which I still want to use as the one we edit. PPT_EDIT_PASSWORD applies to that edit link. Verify that.

[claude]

Claude finished @sgbaird's task in 2m 36s —— View job

---

Verified: PPT_EDIT_LINK resolves to idetc-2026.pptx, and PPT_EDIT_PASSWORD unlocks it with edit rights

• Gather context (recipe doc, env var names)
• Unlock the sharing link with the password (guestaccess form postback)
• Read stored-file metadata and confirm which .pptx the link resolves to
• Check the permission the link grants (edit vs view)
• Report results

I ran the read-only unlock from docs/onedrive-sharepoint-ppt-access.md (form postback → Doc.aspx redirect → FedAuth cookie → GetFileById metadata). No writes were made, and no secrets were printed anywhere. Results:

Check	Result
Password accepted	Yes (Doc.aspx redirect, FedAuth cookie issued)
File name	idetc-2026.pptx
Size	158,797,850 bytes (~151 MB)
Last modified	2026-08-17T17:03:03Z
Version	3.0
Guest identity	Guest Contributor
EditListItems permission bit	Yes (a true edit link, not view-only)

So this is a genuine edit link, not the view link that silently discards changes: the guest session identifies as "Guest Contributor" with the edit permission bit set, which is exactly the signature the recipe doc says an edit-enabled link produces.

One implication worth flagging: when this PR was made, the idetc-2026.pptx link was read-only, so the two teaching slides were applied to "IDETC Tensegrity Slides Draft 1.pptx" instead. Since the link now grants edit on idetc-2026.pptx itself, the same insertion (add_teaching_slides.py content, applied through the web editor per the recipe) can go into the real deck. Say the word (e.g. "@claude apply the teaching slides to the deck") and I'll do that as a follow-up.

[sgbaird]

@claude apply the teaching slides to the deck

[claude]

Claude finished @sgbaird's task in 43m 1s —— View job

---

Done: both teaching slides are in idetc-2026.pptx, verified against the re-downloaded stored file

• Gather context (recipe doc, teaching-slides script, README)
• Unlock the edit link and download the stored deck (read-only plan phase)
• Plan: parse the deck with python-pptx, decide anchor slide and operations
• Apply: insert the two slides via the Office web editor (headless Chrome)
• Fix autocorrect fallout: reword note and figure text to be dash-free, regenerate figures, swap them into the deck
• Replace slide 10's placeholder note paragraph
• Verify: re-download the stored deck and diff against the plan
• Commit the repo-side wording sync (dc62a02)

What the deck looks like now (25 slides, was 23)

• Slide 12: "Each drop tells a two-part story: the jolt going in, and the ringing that follows." with the full-width figure below the title and the complete talk track in speaker notes.
• Slide 13: "Every recording gets the same standard treatment, and each drop boils down to one score." likewise. Both sit right after the sensors slide (11) and before the data-comparison slide (14), as planned.
• Slide 10 (drop video): the "Need more information about the drop tests…" placeholder paragraph in the speaker notes is replaced by the plain-language rig description. The rest of that note, including its Wingdings arrow character, is untouched (the editor silently drops typed non-ASCII, so I replaced only the placeholder paragraph by keyboard selection).

Every claim above was verified by re-downloading the stored blob and parsing it, not by trusting the editor: 25 slides in the right order, exact titles, exact notes, both figure PNGs byte-exact in the file (360,157 and 323,969 bytes), layout "Title Only" on both new slides, figures at top 1.49 in / 1.50 in (below the title band, full slide width), and every untouched slide hash-identical to the pre-edit download.

One wording change, synced to the repo

PowerPoint's autocorrect converts a typed " - " into an en dash mid-note, which this repo bans outright. The first pass of notes landed with en dashes in the stored file, so I reworded every spaced-hyphen construction (colons, commas, periods, parentheses, which is what the style guide prefers anyway) in the notes and in the six figure annotations, regenerated the figures, retyped the notes, and swapped the figures in place via the Picture ribbon's Change Picture (byte-exact, keeps geometry). Commit dc62a02 updates add_teaching_slides.py, make_teaching_figures.py, both PNGs, and the README (which also no longer claims the idetc-2026.pptx link is read-only) so the repo matches the deck exactly.

Findings worth folding into the recipe doc (it lives on the docs/onedrive-sharepoint-ppt-access.md branch, not this one)

• #ReactModalDiv is a second kind of invisible click shield the doc's overlay list misses; same treatment works (detect by layout + pointer-events, Escape to clear).
• Autocorrect is not hypothetical: spaced hyphens become en dashes as you type. Text destined for the editor should be ASCII with no " - ".
• The ribbon's numeric Size fields render lazily, carry duplicate ids, and the Arrange > Align flyout would not open at all in some sessions. A raw vertical mouse drag from a known EMU position (recipe's precision-drawing technique) placed the figure within 0.015 in and was far more reliable.
• The notes panel's innerText contains zero-width spaces; strip U+200B before comparing typed text against it.
• "Change Picture > This Device" swaps an image in place, byte-exact, keeping position and size: the clean way to update an already-placed figure.

--- | Branch claude/issue-94-20260817-1700

[me-madsen]

@claude let's clean up some of these. For this one, let's implement the following:

• bottom legend should just be "time (ms)"
• Side legend should be "acceleration (G)
• Remove the text about jolt going in to bottom of the structure and what arrives at top. I'd like to be able to do some stuff there without it being clogged up.
• Ensure the background color is a white color, not an off tone

[claude]

Claude finished @me-madsen's task in 19m 59s —— View job

---

Done: fig1 cleaned up in the repo and swapped into idetc-2026.pptx, verified against the re-downloaded stored file

• Gather context (figure script, data file, env)
• Edit make_teaching_figures.py: short axis labels, no in-panel callouts, pure white background
• Regenerate and commit the figure
• Plan against the live deck (read-only download and parse)
• Swap the picture on slides 18 and 19 via the web editor (Change Picture > This Device)
• Delete the three now-redundant mask rectangles on slide 19
• Verify against the re-downloaded stored file

The figure, as requested

All four items are in: x-axis label is just "time (ms)", y-axis label is "acceleration (G)", the two callouts ("the jolt going in..." and "what arrives at the top") are gone so the curve area is clear for your own annotations, and the background is pure white (pixel-checked (255,255,255), was #fcfcfb).

Your screenshot turned out to be the picture on slides 18/19 of the deck, which displays fig1 cropped to the left panel. One trap surfaced while applying: Change Picture discards the crop and re-crops the new image to fill the shape, so the first swap on slide 19 showed the middle of the two-panel figure. The fix is fig1_part1_only.png, the panel pre-cropped to exactly the region the shape displays (aspect 1.0131 vs the shape's 1.0132, so the fill-crop becomes a no-op). It's generated by make_teaching_figures.py alongside the full figure.

What changed in the deck (all verified by re-downloading and parsing the stored blob, now v45.0)

• Slide 18: the picture now contains the clean panel, byte-exact (91,056 bytes, SHA-256 match), same position and size. Everything else on that slide is untouched, and your a_top / a_bottom = Transmissibility annotation sits nicely in the cleared space. Note: your earlier workaround shapes are still there (the three white patch rectangles and the "time (ms)" / "acceleration (G)" text boxes). They now cover the figure's own labels, and the off-tone seams still visible on that slide come from those patch rectangles, not the figure. I left them alone because you were live in the deck on that slide while I worked; delete them whenever, or say the word and I'll sweep them.
• Slide 19 (the untitled duplicate): same picture swap, and I deleted the three patch rectangles (each delete confirmed one-by-one via the Selection Pane, then in the re-downloaded file). That slide is now just the title placeholder plus the clean figure showing its own labels.
• Not touched: slide 22's figure is a different, already-clean variant (specimen 7xadt6, built by another work stream), and hidden slide 21. Tell me if you want those aligned too.

Repo commits

• 59404d9: the four figure changes in make_teaching_figures.py + regenerated fig1_one_drop_two_parts.png (fig2 untouched, byte-identical)
• 8a2ca55: fig1_part1_only.png, the pre-cropped deck variant
• 910619e: README note documenting both

The full two-panel figure, for reference (Part 2's annotations were not in scope, so they remain; happy to strip those too):

--- | Branch claude/issue-94-20260817-1700 |

[sgbaird]

@claude any updates required based on the latest decisions about objectives in #102 and related PRs/issues?

[claude]

Claude finished @sgbaird's task in 2m 54s —— View job

---

Yes: four updates, all in the speaker notes and one slide title, none in the figures

• Read PR Add T-3_01 Sobol batch print key (ID-to-spec mapping + as-printed .3mf) #102 and its full comment thread (the objective decisions)
• Trace them back to source: campaign analysis doc (Add drop-test protocol, Edison synthesis, and first-data analysis #86 branch), energy-absorption review (Energy-absorption measurability review + drop-tower metrics primer #97), the BO script on claude/issue-98-20260821-0103
• Diff those decisions against what this PR's slide titles, notes, and figures actually claim
• Report what needs to change (not applied yet, see the last section for why)

What I searched: this branch (ripgrep), the claude/issue-98-20260821-0103 and copilot/add-drop-test-protocol-again branches via a blobless mirror, and the PR discussion on #102, #97, #86 via gh api. gh search issues "objective" also surfaced #59, #85, #94, #99; none of those carries a newer objective decision than #102's thread.

---

The decision that moved

As of #102's 8/21 comments, the campaign is explicitly two objectives, both minimized:

	objective	what it is
1	t180	CFC 180 transmissibility, top peak divided by bottom peak. Deliberately kept a ratio, not mass corrected.
2	e_reb_mJ	absolute rebound energy returned to the payload, e_rebound × m_printed × g × h with each article's weighed mass and the 60 inch height

plus mass_g as a tracking metric. And the campaign analysis doc explicitly demotes ring-down: fits are usable for only 5 of 8 specimens (bag26v, the tallest article, is 0 % usable), so "treat f_n / ζ as opportunistic secondary outputs, not campaign objectives." That is a reversal of where #97 stood on 8/6, when ζ was called "the closest thing we have to an energy-dissipation measurement", and #97 is what these slides were written against.

What that breaks in the current slides

1. Slide B's title says "one score". It reads "Every recording gets the same standard treatment, and each drop boils down to one score." The campaign now ranks each design on two numbers that genuinely trade off, which is the whole reason the optimizer produces a Pareto front rather than a winner. Smallest honest fix that keeps fig2_smoothing_and_score.png as is:

Every recording gets the same standard treatment, and the main score is a simple ratio.

(The bigger option is a third panel showing the rebound hop, so the slide carries both numbers. That means regenerating the figure and re-inserting it.)

2. NOTES_A sells the ring-fade as the energy measure. add_teaching_slides.py:39 currently says "The fade speed is our most direct sign of energy being soaked up. The ring rate is also a free health check on each print." Both claims are now overstated: the fade is a diagnostic, not an objective, and the "free health check" failed outright on the tallest specimen. Suggested replacement for that last paragraph:

So each drop gives us two honest readouts: how much of the jolt reaches the top, and how far the structure bounces back afterward. The fade of the ringing was our first candidate for measuring energy soaked up, and it is still worth watching, but across the nine printed structures it only fits cleanly on about two thirds of them, so we treat it as a diagnostic rather than a score.

3. NOTES_B promises an energy number that now exists. It says "For the official campaign we therefore also log what a real energy number needs (the falling weight and drop height) ... and pair this score with the ring-fade measure from the previous slide." The pairing is wrong (it is the rebound hop, not the fade), and the promise has been kept, so it should be stated as a fact:

We now do have an energy number to go with it. Every printed structure is weighed (they run 18.5 to 22.3 grams), the drop height is fixed at 60 inches, so the height of the bounce converts into the millijoules handed back to the payload. Each design therefore carries two numbers we want small: how much of the jolt gets through, and how much energy comes back out. They pull against each other, so the search returns a trade-off curve rather than a single winner. This is still the rebound share, not total joules absorbed.

4. Slide 10's rig note should mention the scale. Per-print mass is now load bearing for objective 2, and the rig talk track never says the article gets weighed. One clause at the end: "Each structure is weighed before it is tested, because the energy score depends on its mass."

Two smaller things worth knowing

• The score on slide B is objective 1. fig2 computes it from the CFC 180 traces, so it is numerically the same t180 the BO minimizes, and it matches @me-madsen's a_top / a_bottom = Transmissibility annotation on slide 18. Nothing to fix, but the notes could say so in one clause so the audience connects the plain-language slide to the optimization slides later in the deck.
• "about 560 wobbles per second" in fig1 and NOTES_A is that one capture (a felt and cardboard tuning session). Campaign specimens ring at 294 to 468 Hz. The note already hedges with "here", the figure annotation does not; adding "for this drop" to the annotation would make it airtight.

Why I did not apply these yet

Two reasons, and one word from you clears both:

1. The Edison adversarial review of exactly this objective set is still outstanding. 467a4f9 submitted task 3e398131 and the job errored before fetching; no results are committed on that branch. Its section B asks whether e_rebound is a velocity ratio wearing an energy label and whether minimizing it double counts against the mechanism that made 6lhxfy the best attenuator. If that verdict lands against the mJ framing, item 3 above gets rewritten again, and this is audience-facing text.
2. Applying it means retyping notes in the live deck, not just editing this repo. The README's claim that the repo matches the deck exactly is only true if both move together, and note text has to be typed into the web editor in plain ASCII (autocorrect turns spaced hyphens into en dashes).

Say "apply the objective updates" and I will make the repo edits and retype the notes on slides 12/13 and 10 of idetc-2026.pptx, verified against a re-download. Say "apply and add the rebound panel" if you want fig2 rebuilt to show both numbers.
| Branch claude/issue-94-20260817-1700

[me-madsen]

@claude I'd like to create a slide like this:

But with easier to understand graphs. For this I need graphs from two specimens that perform noticeably different during the drop testing, perhaps 6lhxfy and bag26v. Follow the guidelines here #100 (comment) for having a clean image and do NOT title these graphs. Just ensure I know which is for what specimen. Ensure the graphs have already undergone the crash filter we are using if that makes them more visually readable.

Also report the transmissibility values for each as I'll want to show those on the slide.

[claude]

Claude finished @me-madsen's task in 7m 20s —— View job

---

Done: one clean graph per specimen, committed in bb1a1a3, transmissibility values below

• Gather context (reference slide image, existing figure style, where the specimen data lives)
• Locate drop-test recordings for 6lhxfy and bag26v (campaign raw data lives on Box; manifests and metrics are on the copilot/add-drop-test-protocol-again branch)
• Generate one clean graph per specimen (campaign CFC 180 filter, "time (ms)" / "acceleration (G)" labels, no titles or callouts, pure white background)
• Compute and report transmissibility for each, verified against the campaign metrics
• Commit, push, and post the figures here

Transmissibility values for the slide

specimen	transmissibility (this drop)	session mean, 101 drops	reading
6lhxfy	0.89	0.893 (sd 0.004)	softens the jolt on the way up
bag26v	1.06	1.062 (sd 0.005)	top shakes harder than the base

These are the campaign's official t180 numbers (CFC 180 top peak divided by bottom peak, the same a_top / a_bottom = Transmissibility you annotated on slide 18). Each graph shows the stabilized drop whose transmissibility sits closest to that specimen's session mean (6lhxfy Signal 64, bag26v Signal 47), so the single trace honestly represents the whole session, and the peak ratio you can see in the graph equals the reported value.

The graphs

fig3_compare_6lhxfy.png (the attenuator, orange peak below blue):

fig3_compare_bag26v.png (the amplifier, orange peak above blue):

Per your guidelines: no titles (the specimen ID is in the file name only), axis labels are just "time (ms)" and "acceleration (G)", no in-panel callout text, and the background is pure white (pixel-checked). Both graphs share identical axis limits and tick marks, so placed side by side at the same size they compare directly, and the difference between the two orange curves is real, not a scale artifact. On the filter question: yes, both are plotted with the crash filter the campaign scores use (SAE J211 CFC 180), which is why they read much cleaner than the CFC-1000 curves on your reference slide, and it keeps the visible peaks consistent with the transmissibility numbers above. The visible ringing on bag26v's top sensor after the pulse is real signal, not noise: it rings longer and harder than 6lhxfy, which reinforces the story.

Files

• make_comparison_figures.py: builds both graphs. It auto-fetches the two Signal CSVs from Box (using the file IDs from the committed box-ids.json manifests, raw data stays uncommitted per repo convention), replicates the campaign pipeline exactly (tail baseline, pipeline CFC 180, tri-axis resultant top), and asserts each recomputed transmissibility against the per-drop value recorded in campaign_metrics.json, so any drift from the official numbers fails loudly. Both asserts pass.
• fig3_compare_6lhxfy.png, fig3_compare_bag26v.png
• README.md: new section documenting the drop selection, the pipeline match, and the values.

I did not touch the deck, since you said you'll compose the slide. If you'd like, say the word and I can insert a slide into idetc-2026.pptx with the two graphs placed side by side (same size, below the title band) so you only add your own annotations and the two transmissibility numbers.
| Branch claude/issue-94-20260817-1700