diff --git a/.gitignore b/.gitignore index ba390c4..6216227 100644 --- a/.gitignore +++ b/.gitignore @@ -56,3 +56,6 @@ scripts/tool_images/ .vscode/ *.swp *.swo + +# Office temp/lock files +~$* diff --git a/docs/isam-2026-demo/DECISIONS.md b/docs/isam-2026-demo/DECISIONS.md new file mode 100644 index 0000000..a0d94f0 --- /dev/null +++ b/docs/isam-2026-demo/DECISIONS.md @@ -0,0 +1,126 @@ +# ISAM 2026 Demo Abstract — Decisions Log + +> Working notes for the extended abstract submission. Source: `abstract-v1.1.html` (mirror: `abstract-v1.1.md`). +> Submission deadline: **10 July 2026**. Final publication version: **15 September 2026**. +> Demo install/session: **Sunday evening, 10 October 2026**, on-site. + +## Version log + +- **V1 — SUBMITTED to ISAM 2026 (2026-05-30). FROZEN — do not edit.** Title: *"The MakerLAB Assistant: + AI to Help Operate, Fix, and Build in Makerspaces."* 2 pages, 3 figures, 3 references (MCP, Claude, + ChatGPT). Files: `abstract-v1.{html,pdf,docx}`, `abstract-v1.md`, + `The MakerLAB Assistant - ISAM 2026 Demo V1.pdf`. This is the record of exactly what was submitted. +- **V1.1 — WORKING copy** for post-submission edits (currently identical to V1). Files: + `abstract-v1.1.{html,pdf,docx}`, `abstract-v1.1.md`, `The MakerLAB Assistant - ISAM 2026 Demo V1.1.pdf`. + Edit `abstract-v1.1.html`, then regenerate: + - PDF: `"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless --disable-gpu --no-pdf-header-footer --print-to-pdf=abstract-v1.1.pdf "file://$PWD/abstract-v1.1.html"` + - DOCX: `pandoc abstract-v1.1.html -o abstract-v1.1.docx --resource-path="$PWD"` + +## Planned for V2 (Isaac, post-submission — there is more time before the final 15 Sep version) + +- **Add the public demo URL:** https://makerlab-tools-v5.vercel.app (the ISAM template even expects a + "Public Demo" line). Pairs with one clause on how a lab adopts it. +- **Data provenance** (answers the recurring "how was the inventory collected?" question): the + catalogue was sourced largely **by hand** — a MakerLAB worker entered each tool via a **Google Form / + manual spreadsheet input**; it then took **substantial data cleaning and restructuring** before the + data could be turned into a usable, normalized catalog. Worth a clause in §1 or §2. +- **Stronger, well-cited answers:** update the assistant's **system prompt** so it *always* cites with + real citations; when it cannot cite a lab source, it must say the info comes from the **model** or a + **website** (not the SOPs) — i.e., grounded and clearly attributed. (Chat UI already strips leaked + `` tags — PR #22.) +- **Demo video:** record a short walkthrough (browse → scope → troubleshoot) for the demo page. + +## Locked decisions + +- **Title:** "The MakerLab Assistant: Conversational AI for Makerspace Operations." + (Earlier drafts led with "MakerBot" and/or "…and Cross-Campus Fabrication Support" — both removed.) +- **Authors (3), confirmed order:** Isaac (primary) → Niti → Miguel. + - Isaac Steinberg — Johnson Cornell Tech MBA '26, Cornell Tech — ies22@cornell.edu + - Niti Parikh — Director, Learning Spaces and MakerLABs, Cornell Tech — ntp27@cornell.edu + - Miguel Ramirez Peraza — Intern, Cornell Tech MakerLAB — ramirezperazamiguel@gmail.com + (built the first Streamlit inventory-search app that framed the problem) +- **System demoed:** v5 (Notion-backed: gallery + tool detail + everywhere-chat overlay), + framed around the §9 long-term vision in `docs/v5-plan.md`. +- **Assistant name:** **the MakerLab Assistant** (matches the live app UI label "MAKERLAB + ASSISTANT"). App/platform = **MakerLab Tools** (matches the header "MAKERLAB TOOLS"). "MakerBot" + was DROPPED per Niti — it is a registered trademark of the MakerBot 3D-printer company + (makerbot.com). Confirm the new name with the user. +- **Framing:** "activation energy" pedagogical spine (A) + bring-your-own-AI via MCP as the + novelty moment (C) + a discussion paragraph of the digital-twin vision (B). +- **Headline contribution:** lowering the barrier to **use**, **debug**, and **scope across** + machines for non-traditional makers. +- **Results:** forward-looking — early Cornell Tech deployment + planned data collection + (issue resolution, throughput, maintenance surfaced, uptime, access breadth/languages). + Not a finished study. +- **Future work called out:** (i) student-projects gallery linked to the devices that + produced them (hardware ↔ output provenance); (ii) digital twin + lab-wide AI agent that + routes print/fab jobs and helps coordinate machines, schedules, and trainings. + +## Accuracy flags (must stay honest in the prose) + +- **MCP endpoint: SHIPPED** (merged from main, PR #19). `v5/src/app/api/mcp/route.ts` — + standards-based MCP server (official SDK, streamable HTTP, server name `makerlab`) exposing + `list_tools`, `search_tools`, `get_tool_details`, `get_unit_details`, + `get_maintenance_history`. Abstract states it as live — accurate. +- **`/projects` route already scaffolded** in v5 — the student-projects future-work item is + partly underway; phrase as "extending" not "net-new." +- **LLM disclosure required** by ISAM policy (Claude used to draft prose) → Acknowledgements. + +## Newly landed on main (merged 2026-05-29, commits up to af419464) + +- **MCP HTTP endpoint** (#19) — see above. The "bring your own AI" demo thread is now real. +- **i18n / 12-language UI** (#15) — cookie-based locale, selector, RTL support. Languages + (`v5/src/i18n/config.ts`): English, Simplified Chinese, Spanish, Hindi, Korean, Arabic (RTL), + French, Brazilian Portuguese, Russian, Turkish, Japanese, Hebrew (RTL). Elevated the + localization story in §2 from "chat answers in any language" to full UI localization. +- **Gallery fuzzy ranked search + material/location facets** (#17) — reflected in §2. +- **Server-side PDF/manual fetch as base64** (#14) — "manuals and SOPs pulled server-side and + read in full" in §2. +- **Env-driven white-label site config** (#18) — `NEXT_PUBLIC_SITE_NAME / _INSTITUTION / + _CHAT_ASSISTANT_NAME`; the app's default assistant label is "MakerLab Assistant" (we brand + it "MakerBot" in the abstract). Reflected in §2 white-label sentence. +- **Rate limiting on API routes** (#16) — production-hardening; not called out in the abstract. + +## Live-system facts (from makerlab-tools-v5.vercel.app, captured 2026-05-28) + +- 100 tools across 9 categories: 3D Printing, CNC & Digital Fabrication, Electronics, + Laser Cutting, Printing & Large Format, Safety & Infrastructure, Scanning & VR, + Sewing & Textiles, Woodworking. +- Real machines incl. Bambu Lab X1-Carbon, Formlabs Form 4, Trotec Speedy 400, Epilog + Helix 24, Roland CAMM-1 vinyl cutter, ShopBot Buddy, WAZER waterjet, Ultimaker S5. +- Tool detail shows: training level, PPE, use restrictions, emergency-stop guidance, + SOP/doc links, spec table, and a per-unit Physical Machines table (status/condition/serial). +- Assistant overlay ("MAKERLAB ASSISTANT") has starter chips ("Find a machine for a + project", "Check training requirements", "Ask about safety or policy") + photo attach (vision). +- Stack: Next.js / React, Notion source-of-truth, Claude API tool-calling + web search + + doc fetch + vision, hosted on Vercel. + +## Figures (captured, in this folder) + +- `fig-gallery.png` — Fig 1: gallery (light), now showing material/location facets + 12-language selector. +- `fig-assistant.png` — Fig 2: **real live exchange** on the Bambu Lab X1-Carbon page — first PLA + print / bed adhesion → SOP-grounded pre-print checklist (glue, plate, bed leveling, filament). + (Switched from a Trotec laser example per Niti's preference for a 3D-printer example.) + NOTE: the chat UI leaked raw `` markup on grounded answers (an app rendering bug); + stripped from the DOM before screenshotting. **TODO (app): parse/strip `` tags in chat output.** +- `fig-project.png` — Fig 3: **real live exchange** — "wooden box for my phone, hinged lid" → + start-to-finish, training-aware multi-machine build plan (project scoping). +- `fig-tool-detail.png` — captured earlier (Bambu detail); **no longer used** in the abstract. + +## Dark-mode fix (v5 app code) — DONE + verified + +`v5/src/styles/globals.css`: the `.tool-detail` page had a private, light-only `--td-*` palette and +hardcoded literals, so dark mode rendered light. Fix: routed ~40 scattered literals through the +`--td-*` palette and added a dark override (under both `[data-theme="dark"]` and the +`prefers-color-scheme: dark` media query). Light mode unchanged. Verified by prototyping on the live +page (`.context/isam-demo/darkmode-toolpage-*.png`). **Local change — not yet committed/deployed.** +Gallery/main page dark mode was already correct. + +## Open TODOs before submission + +- [x] Capture a real MakerBot conversation screenshot for Fig 2. +- [x] Confirm MCP endpoint will be live by October — yes; abstract states it as live. +- [x] Ship the MCP endpoint PR — done on main (#19); abstract's "live MCP server" claim holds. +- [ ] Fill the ISAM "Demonstration Information" Google Form (link TBD, "COMING SOON"). +- [ ] Format into the ISAM two-column Word template; export PDF. +- [ ] Add 2–3 real references (makerspace access/pedagogy) to the IEEE list. diff --git a/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.1.pdf b/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.1.pdf new file mode 100644 index 0000000..d8a39d9 Binary files /dev/null and b/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.1.pdf differ diff --git a/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.pdf b/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.pdf new file mode 100644 index 0000000..d8a39d9 Binary files /dev/null and b/docs/isam-2026-demo/The MakerLAB Assistant - ISAM 2026 Demo V1.pdf differ diff --git a/docs/isam-2026-demo/abstract-v1.1.docx b/docs/isam-2026-demo/abstract-v1.1.docx new file mode 100644 index 0000000..c84d5a2 Binary files /dev/null and b/docs/isam-2026-demo/abstract-v1.1.docx differ diff --git a/docs/isam-2026-demo/abstract-v1.1.html b/docs/isam-2026-demo/abstract-v1.1.html new file mode 100644 index 0000000..9ac4447 --- /dev/null +++ b/docs/isam-2026-demo/abstract-v1.1.html @@ -0,0 +1,219 @@ + + + + +The MakerLAB Assistant — ISAM 2026 Demo Extended Abstract + + + + + +
+

International Symposium on Academic Makerspaces — ISAM 2026

+

The MakerLAB Assistant: AI to Help Operate, Fix, and Build in Makerspaces

+

Isaac Steinberg1, Niti Parikh2, and Miguel Ramirez Peraza3

+

1Isaac Steinberg; MBA ’26, Johnson Cornell Tech; ies22@cornell.edu

+

2Niti Parikh; Director, Learning Spaces & MakerLABs, Cornell Tech; ntp27@cornell.edu

+

3Miguel Ramirez Peraza; MakerLAB Intern, Cornell Tech; ramirezperazamiguel@gmail.com

+
+ +
+ + +
+

Abstract—Academic makerspaces accumulate substantial + operational knowledge: machine documentation, setup procedures, safety rules, materials, inventory, + and fabrication know-how. That knowledge is scattered across shared drives, URLs, videos, + institutional memory, staff, and repair vendors rather than centralized, and it is mostly in + English. At a lab like the Cornell Tech MakerLAB—seven-day access, lean staff, students at + every skill level—access to this knowledge ends up unevenly distributed, and the learning + curve is steep: students must ideate, find the right hardware, recall procedures, and run complex + multi-machine setups. We demonstrate the + MakerLAB Assistant, a conversational AI layered over a structured operational database + (hosted in Notion) within the MakerLAB Tools app. It gives students instant, anytime access + to the inventory and the lab’s specifications in plain language and many languages: find the + right tool, follow manual-grounded setup and troubleshooting, log a maintenance ticket, and scope + multi-machine projects. The same database is exposed as a live Model Context Protocol (MCP) server, + so attendees can query the lab from an LLM client such as Claude or ChatGPT. The demonstration is interactive: + visitors browse the catalog, scope a project, and troubleshoot an example issue on a 3D printer. The + app is already deployed at the Cornell Tech MakerLAB over an initial catalogue of 100 machines, and + we frame this as an ongoing R&D initiative whose long-term goal is a shared operational framework + across Cornell’s campuses while preserving each lab’s local identity.

+
+ + +

1. Background and Motivation

+

The project began on the floor of the Cornell Tech MakerLAB. An intern (a co-author) built the + first inventory app in Streamlit to search the lab’s hardware—work that organized the + data and framed the problem. A second co-author, volunteering as a “SuperMaker,” kept + hitting the same friction: looking up a manual whenever something broke, or digging for a laser + cutter’s specs just to design a case that would fit. He added an AI layer over the inventory. + The director then posed the guiding question: could a student describe a project and have it + decomposed against the tools the lab actually has? Pairing the inventory with each + machine’s manual and setup procedures turns a static list into something generative—a + step-by-step account of the tooling and workflow a project requires. (An early version produced + how-to infographics and renders; today the system generates grounded text that can seed an image on + demand.)

+ +

The lab runs on lean staff and offers open access, and staff are often busy fabricating for + classes and projects. When no one is on the floor, the knowledge of what each machine does, who may + use it, and how to set it up is distributed, imperfect, and mostly in English—so access falls + unevenly across students.

+ +

Three needs recur, and each routes today to a human bottleneck. Students need to operate a + machine (where is it, how do I start, what training and PPE does it require?); to debug a + machine and log a maintenance ticket when it throws an error mid-job; and to scope a + project spanning several machines. The MakerLAB Assistant lowers all three at once—shared + context for operating, planning, and creating in the lab.

+ +

2. System Overview

+

MakerLAB Tools treats the lab’s operational knowledge as structured, typed data + rather than a static list. The schema is normalized—tools, categories, locations, individual + units, resources, setup/safety procedures, and maintenance logs—and hosted in Notion, keeping + staff editing in a tool they already use. The web application (Next.js / React, deployed on Vercel) + presents two surfaces: a gallery with fuzzy ranked search and category, material, training, + and location facets across every published machine (Fig. 1), and a tool detail page + showing description, location, required training, PPE and use restrictions, emergency-stop guidance, + linked SOPs and manuals, and a live table of individual units with status, condition, and serial.

+ +
+ MakerLAB Tools gallery +
Fig. 1: The gallery—fuzzy search with category, training, material, and location + facets across ~100 machines; the language selector sits top-right.
+
+ +

Overlaying both surfaces is the MakerLAB Assistant—a single unified assistant rather + than a handful of separate tools (Fig. 2). From any page it answers questions, walks through + setups, and logs maintenance tickets; near-term, it will also help create and manage inventory and + schedule trainings. Rather than baking the catalog into a prompt, it reasons over the data through + tool-calling, augmented with web search, document fetch (manuals and SOPs are pulled server-side and + read in full), and vision (a photo of a machine or an error screen). Its context scales with place: + from the gallery it carries a lightweight index of every tool and its resources; opened from a tool + page it loads that machine’s full detail and linked manuals, becoming a domain expert on the + machine in front of you. It answers in the language it is asked. The app is lightweight and + white-label—a new lab connects its own Notion workspace through environment variables + and hosts on serverless infrastructure—so other labs can adopt it.

+ +
+ The MakerLAB Assistant scoping a project across machines +
Fig. 2: Project scoping. The assistant decomposes a phone-and-tablet stand into + laser-cut Baltic-birch parts (including a living hinge) and 3D-printed parts, each mapped to the + right machine.
+
+ +

3. The Demonstration

+

The demonstration is interactive: visitors drive the live app.

+ +

3.1 Browse and scope.

+

Visitors browse the catalog, then ask the assistant to scope a project—e.g., “I + want to make a wooden stand for my phone and tablet with 3D-printed parts; which machines and steps + would I need?” It returns a start-to-finish, training-aware plan that decomposes the build + into laser-cut plywood parts and 3D-printed parts, each mapped to the right machine and grounded in + the lab’s actual inventory (Fig. 2)—turning a vague idea into an executable plan.

+ +

3.2 Troubleshoot and log a ticket.

+

On a machine page, visitors ask a hands-on question—say, how to replace the filament on the + Bambu Lab X1-Carbon. The assistant pulls the printer’s SOP and walks through it step by step on + the touchscreen (Fig. 3), in any language. And when a machine actually faults, the same chat + files a maintenance ticket on the spot—so the machine stays online and the issue is captured + rather than lost.

+ +
+ The MakerLAB Assistant answering a 3D-printer question +
Fig. 3: A live exchange on the Bambu Lab X1-Carbon page—“how do I replace the + filament?”—answered step by step from the printer’s SOP (unload the old, load the + new).
+
+ +

3.3 Bring your own AI (MCP).

+

The database is also a live, standards-based MCP server [1] (streamable HTTP) with tools to list, + search, and inspect machines, units, and maintenance history. Attendees connect an LLM + client—such as Claude [2] or ChatGPT [3]—and query the lab from a tool they already + use—reaching the linked manuals and grounding + a 3D print or laser-cut SVG in the lab’s actual build and bed dimensions, coupling design files + to the hardware that will make them.

+ +

3.4 Feedback and requirements.

+

We gather visitor feedback throughout. Requirements are light—the footprint of a standard + table, plus power, reliable Wi-Fi, a couple of tablets, and a monitor.

+ +

4. Why a Demonstration

+

This work is best experienced, not read. The point is what the assistant takes off a + student’s plate—planning a build, recalling a setup, fixing a jam, filing a + ticket—normally a hunt through manuals or a wait for staff. By simplifying these + workflows, it lets students take on more ambitious projects, finish them faster, and learn the tools + sooner—raising the number, complexity, and quality of what gets made. A demo is the best way to + show this, gather feedback from students and other labs, and let those labs adopt it; the code will + be openly accessible to read and run. As AI makes these labs easier to use and to teach, we expect + more of them—and tools like this to help.

+ +

5. Early Deployment and Planned Evaluation

+

With the app live over the lab’s real inventory, we are in a data-collection phase to assess + whether it helps students. Early signals we will watch: whether more issues get surfaced and fixed + (more uptime, less downtime), and whether students use the machines more because the lab is easier to + navigate. We frame this as an in-progress study.

+ +

6. Discussion and Future Direction

+

This is an ongoing R&D initiative, not a finished product. Two near-term directions add the + most value. First, a student-projects gallery linked to the devices that made each + project—an archive and portfolio of student work and an institutional record of it. Second, + AI-assisted inventory creation through the chat: a student uploads a few + photos of tools or hardware and a short description, and the assistant fetches the manuals and drafts + a catalog row for each—making inventory far faster to add and maintain. Farther out: a + digital twin with a lab-wide agent that routes fabrication jobs and coordinates schedules and + trainings; and, longest horizon, a shared operational framework across Cornell’s campuses, so + students move fluidly between labs while each keeps its identity.

+ +

Acknowledgements

+
+

We thank the staff and interns who helped build the MakerLAB; Cornell Tech and Cornell University; + and all the students who have helped make it such an exciting, generative place. Isaac Steinberg + designed the system architecture and wrote all application code for v5 and the current version, + developed with the AI coding assistants Claude Code and Codex.

+

In accordance with ISAM policy, we disclose that a large language model (Anthropic’s Claude) + assisted in drafting and editing this abstract; all technical claims, design decisions, and the + system itself are the authors’ own.

+
+ +

References

+
+

[1] Anthropic, “Model Context Protocol,” 2024. [Online]. Available: + https://modelcontextprotocol.io. [Accessed: May 30, 2026].

+

[2] Anthropic, “Claude,” 2023. [Online]. Available: https://www.anthropic.com/claude. + [Accessed: May 30, 2026].

+

[3] OpenAI, “ChatGPT,” 2022. [Online]. Available: https://openai.com/chatgpt. + [Accessed: May 30, 2026].

+
+ +
+ + diff --git a/docs/isam-2026-demo/abstract-v1.1.md b/docs/isam-2026-demo/abstract-v1.1.md new file mode 100644 index 0000000..2bd365e --- /dev/null +++ b/docs/isam-2026-demo/abstract-v1.1.md @@ -0,0 +1,162 @@ +# The MakerLAB Assistant: AI to Help Operate, Fix, and Build in Makerspaces + +**ISAM 2026 — Demo Extended Abstract (draft)** + +> This Markdown mirrors the typeset version. The submission artifact is **`abstract.pdf`** +> (ISAM two-column format); regenerate it from `abstract.html` with the Chrome command in `DECISIONS.md`. + +**Isaac Steinberg¹, Niti Parikh², and Miguel Ramirez Peraza³** + +¹ Isaac Steinberg; MBA '26, Johnson Cornell Tech; ies22@cornell.edu +² Niti Parikh; Director, Learning Spaces & MakerLABs, Cornell Tech; ntp27@cornell.edu +³ Miguel Ramirez Peraza; MakerLAB Intern, Cornell Tech; ramirezperazamiguel@gmail.com + +--- + +## Abstract + +Academic makerspaces accumulate substantial operational knowledge: machine documentation, setup +procedures, safety rules, materials, inventory, and fabrication know-how. That knowledge is scattered +across shared drives, URLs, videos, institutional memory, staff, and repair vendors rather than +centralized, and it is mostly in English. At a lab like the Cornell Tech MakerLAB — seven-day access, +lean staff, students at every skill level — access to this knowledge ends up unevenly distributed, and +the learning curve is steep: students must ideate, +find the right hardware, recall procedures, and run complex multi-machine setups. We demonstrate the +**MakerLAB Assistant**, a conversational AI layered over a structured operational database (hosted in +Notion) within the *MakerLAB Tools* app. It gives students instant, anytime access to the inventory +and the lab's specifications in plain language and many languages: find the right tool, follow +manual-grounded setup and troubleshooting, log a maintenance ticket, and scope multi-machine projects. +The same database is exposed as a live Model Context Protocol (MCP) server, so attendees can query the +lab from an LLM client such as Claude or ChatGPT. The demonstration is interactive: visitors browse the catalog, +scope a project, and troubleshoot an example issue on a 3D printer. The app is already deployed at the +Cornell Tech MakerLAB over an initial catalogue of 100 machines, and we frame this as an ongoing R&D +initiative whose long-term goal is a shared operational framework across Cornell's campuses while +preserving each lab's local identity. + +## 1. Background and Motivation + +The project began on the floor of the Cornell Tech MakerLAB. An intern (a co-author) built the first +inventory app in Streamlit to search the lab's hardware — work that organized the data and framed the +problem. A second co-author, volunteering as a "SuperMaker," kept hitting the same friction: looking +up a manual whenever something broke, or digging for a laser cutter's specs just to design a case that +would fit. He added an AI layer over the inventory. The director then posed the guiding question: +could a student *describe a project* and have it **decomposed against the tools the lab actually +has**? Pairing the inventory with each machine's manual and setup procedures turns a static list into +something generative — a step-by-step account of the tooling and workflow a project requires. (An +early version produced how-to infographics and renders; today the system generates grounded text that +can seed an image on demand.) + +The lab runs on lean staff and offers open access, and staff are often busy fabricating for classes +and projects. When no one is on the floor, the knowledge of what each machine does, who may use it, +and how to set it up is distributed, imperfect, and mostly in English — so access falls unevenly +across students. + +Three needs recur, and each routes today to a human bottleneck. Students need to **operate** a machine +(where is it, how do I start, what training and PPE does it require?); to **debug** a machine and +**log a maintenance ticket** when it throws an error mid-job; and to **scope** a project spanning +several machines. The MakerLAB Assistant lowers all three at once — shared context for operating, +planning, and creating in the lab. + +## 2. System Overview + +*MakerLAB Tools* treats the lab's operational knowledge as structured, typed data rather than a static +list. The schema is normalized — tools, categories, locations, individual units, resources, +setup/safety procedures, and maintenance logs — and hosted in Notion, keeping staff editing in a tool +they already use. The web application (Next.js / React, deployed on Vercel) presents two surfaces: a +**gallery** with fuzzy ranked search and category, material, training, and location facets across +every published machine (Fig. 1), and a **tool detail** page showing description, location, required +training, PPE and use restrictions, emergency-stop guidance, linked SOPs and manuals, and a live table +of individual units with status, condition, and serial. + +Overlaying both surfaces is the **MakerLAB Assistant** — a single unified assistant rather than a +handful of separate tools (Fig. 2). From any page it answers questions, walks through setups, and logs +maintenance tickets; near-term, it will also help create and manage inventory and schedule trainings. +Rather than baking the catalog into a prompt, it reasons over the data through tool-calling, augmented +with web search, document fetch (manuals and SOPs are pulled server-side and read in full), and vision +(a photo of a machine or an error screen). Its context scales with place: from the gallery it carries +a lightweight index of every tool and its resources; opened from a tool page it loads that machine's +full detail and linked manuals, becoming a domain expert on the machine in front of you. It answers in +the language it is asked. The app is lightweight and **white-label** — a new lab connects its own +Notion workspace through environment variables and hosts on serverless infrastructure — so other labs +can adopt it. + +## 3. The Demonstration + +The demonstration is interactive: visitors drive the live app. + +**3.1 Browse and scope.** Visitors browse the catalog, then ask the assistant to scope a project — +e.g., *"I want to make a wooden stand for my phone and tablet with 3D-printed parts; which machines +and steps would I need?"* It returns a start-to-finish, training-aware plan that decomposes the build +into laser-cut plywood parts and 3D-printed parts, each mapped to the right machine and grounded in +the lab's actual inventory (Fig. 2) — turning a vague idea into an executable plan. + +**3.2 Troubleshoot and log a ticket.** On a machine page, visitors ask a hands-on question — say, how +to replace the filament on the Bambu Lab X1-Carbon. The assistant pulls the printer's SOP and walks +through it step by step on the touchscreen (Fig. 3), in any language. And when a machine actually +faults, the same chat files a maintenance ticket on the spot — so the machine stays online and the +issue is captured rather than lost. + +**3.3 Bring your own AI (MCP).** The database is also a live, standards-based MCP server [1] +(streamable HTTP) with tools to list, search, and inspect machines, units, and maintenance history. +Attendees connect an LLM client — such as Claude [2] or ChatGPT [3] — and query the lab from a tool +they already use — reaching the linked manuals and grounding a 3D print or laser-cut SVG in the lab's +actual build and bed dimensions, coupling design files to the hardware that will make them. + +**3.4 Feedback and requirements.** We gather visitor feedback throughout. Requirements are light — the +footprint of a standard table, plus power, reliable Wi-Fi, a couple of tablets, and a monitor. + +## 4. Why a Demonstration + +This work is best experienced, not read. The point is what the assistant takes off a student's plate — +planning a build, recalling a setup, fixing a jam, filing a ticket — normally a hunt through manuals +or a wait for staff. By simplifying these workflows, it lets students take on more +ambitious projects, finish them faster, and learn the tools sooner — raising the number, complexity, +and quality of what gets made. A demo is the best way to show this, gather feedback from students and +other labs, and let those labs adopt it; the code will be openly accessible to read and run. As AI +makes these labs easier to use and to teach, we expect more of them — and tools like this to help. + +## 5. Early Deployment and Planned Evaluation + +With the app live over the lab's real inventory, we are in a data-collection phase to assess whether +it helps students. Early signals we will watch: whether more issues get surfaced and fixed (more +uptime, less downtime), and whether students use the machines more because the lab is easier to +navigate. We frame this as an in-progress study. + +## 6. Discussion and Future Direction + +This is an ongoing R&D initiative, not a finished product. Two near-term directions add the most +value. First, a **student-projects gallery** linked to the devices that made each project — an archive +and portfolio of student work and an institutional record of it. Second, **AI-assisted inventory +creation** through the chat: a student uploads a few photos of tools or hardware and a short +description, and the assistant fetches the manuals and drafts a catalog row for each — making +inventory far faster to add and maintain. Farther out: a **digital twin** with a lab-wide agent that +routes fabrication jobs and coordinates schedules and trainings; and, longest horizon, a shared +operational framework across Cornell's campuses, so students move fluidly between labs while each keeps +its identity. + +## Acknowledgements + +We thank the staff and interns who helped build the MakerLAB; Cornell Tech and Cornell University; and +all the students who have helped make it such an exciting, generative place. Isaac Steinberg designed +the system architecture and wrote all application code for v5 and the current version, developed with +the AI coding assistants Claude Code and Codex. + +In accordance with ISAM policy, we disclose that a large language model (Anthropic's Claude) assisted +in drafting and editing this abstract; all technical claims, design decisions, and the system itself +are the authors' own. + +## References + +[1] Anthropic, "Model Context Protocol," 2024. [Online]. Available: https://modelcontextprotocol.io. [Accessed: May 30, 2026]. + +[2] Anthropic, "Claude," 2023. [Online]. Available: https://www.anthropic.com/claude. [Accessed: May 30, 2026]. + +[3] OpenAI, "ChatGPT," 2022. [Online]. Available: https://openai.com/chatgpt. [Accessed: May 30, 2026]. + +--- + +### Figures + +- **Fig. 1** `fig-gallery.png` — gallery: fuzzy search + category/training/material/location facets across ~100 machines; language selector top-right. +- **Fig. 2** `fig-project.png` — live project scoping: a phone-and-tablet stand decomposed into laser-cut Baltic-birch parts (with a living hinge) + 3D-printed parts. +- **Fig. 3** `fig-assistant.png` — live exchange on the Bambu Lab X1-Carbon: "how do I replace the filament?" → SOP-grounded step-by-step (unload old, load new). diff --git a/docs/isam-2026-demo/abstract-v1.1.pdf b/docs/isam-2026-demo/abstract-v1.1.pdf new file mode 100644 index 0000000..d8a39d9 Binary files /dev/null and b/docs/isam-2026-demo/abstract-v1.1.pdf differ diff --git a/docs/isam-2026-demo/abstract-v1.docx b/docs/isam-2026-demo/abstract-v1.docx new file mode 100644 index 0000000..c84d5a2 Binary files /dev/null and b/docs/isam-2026-demo/abstract-v1.docx differ diff --git a/docs/isam-2026-demo/abstract-v1.html b/docs/isam-2026-demo/abstract-v1.html new file mode 100644 index 0000000..9ac4447 --- /dev/null +++ b/docs/isam-2026-demo/abstract-v1.html @@ -0,0 +1,219 @@ + + + + +The MakerLAB Assistant — ISAM 2026 Demo Extended Abstract + + + + + +
+

International Symposium on Academic Makerspaces — ISAM 2026

+

The MakerLAB Assistant: AI to Help Operate, Fix, and Build in Makerspaces

+

Isaac Steinberg1, Niti Parikh2, and Miguel Ramirez Peraza3

+

1Isaac Steinberg; MBA ’26, Johnson Cornell Tech; ies22@cornell.edu

+

2Niti Parikh; Director, Learning Spaces & MakerLABs, Cornell Tech; ntp27@cornell.edu

+

3Miguel Ramirez Peraza; MakerLAB Intern, Cornell Tech; ramirezperazamiguel@gmail.com

+
+ +
+ + +
+

Abstract—Academic makerspaces accumulate substantial + operational knowledge: machine documentation, setup procedures, safety rules, materials, inventory, + and fabrication know-how. That knowledge is scattered across shared drives, URLs, videos, + institutional memory, staff, and repair vendors rather than centralized, and it is mostly in + English. At a lab like the Cornell Tech MakerLAB—seven-day access, lean staff, students at + every skill level—access to this knowledge ends up unevenly distributed, and the learning + curve is steep: students must ideate, find the right hardware, recall procedures, and run complex + multi-machine setups. We demonstrate the + MakerLAB Assistant, a conversational AI layered over a structured operational database + (hosted in Notion) within the MakerLAB Tools app. It gives students instant, anytime access + to the inventory and the lab’s specifications in plain language and many languages: find the + right tool, follow manual-grounded setup and troubleshooting, log a maintenance ticket, and scope + multi-machine projects. The same database is exposed as a live Model Context Protocol (MCP) server, + so attendees can query the lab from an LLM client such as Claude or ChatGPT. The demonstration is interactive: + visitors browse the catalog, scope a project, and troubleshoot an example issue on a 3D printer. The + app is already deployed at the Cornell Tech MakerLAB over an initial catalogue of 100 machines, and + we frame this as an ongoing R&D initiative whose long-term goal is a shared operational framework + across Cornell’s campuses while preserving each lab’s local identity.

+
+ + +

1. Background and Motivation

+

The project began on the floor of the Cornell Tech MakerLAB. An intern (a co-author) built the + first inventory app in Streamlit to search the lab’s hardware—work that organized the + data and framed the problem. A second co-author, volunteering as a “SuperMaker,” kept + hitting the same friction: looking up a manual whenever something broke, or digging for a laser + cutter’s specs just to design a case that would fit. He added an AI layer over the inventory. + The director then posed the guiding question: could a student describe a project and have it + decomposed against the tools the lab actually has? Pairing the inventory with each + machine’s manual and setup procedures turns a static list into something generative—a + step-by-step account of the tooling and workflow a project requires. (An early version produced + how-to infographics and renders; today the system generates grounded text that can seed an image on + demand.)

+ +

The lab runs on lean staff and offers open access, and staff are often busy fabricating for + classes and projects. When no one is on the floor, the knowledge of what each machine does, who may + use it, and how to set it up is distributed, imperfect, and mostly in English—so access falls + unevenly across students.

+ +

Three needs recur, and each routes today to a human bottleneck. Students need to operate a + machine (where is it, how do I start, what training and PPE does it require?); to debug a + machine and log a maintenance ticket when it throws an error mid-job; and to scope a + project spanning several machines. The MakerLAB Assistant lowers all three at once—shared + context for operating, planning, and creating in the lab.

+ +

2. System Overview

+

MakerLAB Tools treats the lab’s operational knowledge as structured, typed data + rather than a static list. The schema is normalized—tools, categories, locations, individual + units, resources, setup/safety procedures, and maintenance logs—and hosted in Notion, keeping + staff editing in a tool they already use. The web application (Next.js / React, deployed on Vercel) + presents two surfaces: a gallery with fuzzy ranked search and category, material, training, + and location facets across every published machine (Fig. 1), and a tool detail page + showing description, location, required training, PPE and use restrictions, emergency-stop guidance, + linked SOPs and manuals, and a live table of individual units with status, condition, and serial.

+ +
+ MakerLAB Tools gallery +
Fig. 1: The gallery—fuzzy search with category, training, material, and location + facets across ~100 machines; the language selector sits top-right.
+
+ +

Overlaying both surfaces is the MakerLAB Assistant—a single unified assistant rather + than a handful of separate tools (Fig. 2). From any page it answers questions, walks through + setups, and logs maintenance tickets; near-term, it will also help create and manage inventory and + schedule trainings. Rather than baking the catalog into a prompt, it reasons over the data through + tool-calling, augmented with web search, document fetch (manuals and SOPs are pulled server-side and + read in full), and vision (a photo of a machine or an error screen). Its context scales with place: + from the gallery it carries a lightweight index of every tool and its resources; opened from a tool + page it loads that machine’s full detail and linked manuals, becoming a domain expert on the + machine in front of you. It answers in the language it is asked. The app is lightweight and + white-label—a new lab connects its own Notion workspace through environment variables + and hosts on serverless infrastructure—so other labs can adopt it.

+ +
+ The MakerLAB Assistant scoping a project across machines +
Fig. 2: Project scoping. The assistant decomposes a phone-and-tablet stand into + laser-cut Baltic-birch parts (including a living hinge) and 3D-printed parts, each mapped to the + right machine.
+
+ +

3. The Demonstration

+

The demonstration is interactive: visitors drive the live app.

+ +

3.1 Browse and scope.

+

Visitors browse the catalog, then ask the assistant to scope a project—e.g., “I + want to make a wooden stand for my phone and tablet with 3D-printed parts; which machines and steps + would I need?” It returns a start-to-finish, training-aware plan that decomposes the build + into laser-cut plywood parts and 3D-printed parts, each mapped to the right machine and grounded in + the lab’s actual inventory (Fig. 2)—turning a vague idea into an executable plan.

+ +

3.2 Troubleshoot and log a ticket.

+

On a machine page, visitors ask a hands-on question—say, how to replace the filament on the + Bambu Lab X1-Carbon. The assistant pulls the printer’s SOP and walks through it step by step on + the touchscreen (Fig. 3), in any language. And when a machine actually faults, the same chat + files a maintenance ticket on the spot—so the machine stays online and the issue is captured + rather than lost.

+ +
+ The MakerLAB Assistant answering a 3D-printer question +
Fig. 3: A live exchange on the Bambu Lab X1-Carbon page—“how do I replace the + filament?”—answered step by step from the printer’s SOP (unload the old, load the + new).
+
+ +

3.3 Bring your own AI (MCP).

+

The database is also a live, standards-based MCP server [1] (streamable HTTP) with tools to list, + search, and inspect machines, units, and maintenance history. Attendees connect an LLM + client—such as Claude [2] or ChatGPT [3]—and query the lab from a tool they already + use—reaching the linked manuals and grounding + a 3D print or laser-cut SVG in the lab’s actual build and bed dimensions, coupling design files + to the hardware that will make them.

+ +

3.4 Feedback and requirements.

+

We gather visitor feedback throughout. Requirements are light—the footprint of a standard + table, plus power, reliable Wi-Fi, a couple of tablets, and a monitor.

+ +

4. Why a Demonstration

+

This work is best experienced, not read. The point is what the assistant takes off a + student’s plate—planning a build, recalling a setup, fixing a jam, filing a + ticket—normally a hunt through manuals or a wait for staff. By simplifying these + workflows, it lets students take on more ambitious projects, finish them faster, and learn the tools + sooner—raising the number, complexity, and quality of what gets made. A demo is the best way to + show this, gather feedback from students and other labs, and let those labs adopt it; the code will + be openly accessible to read and run. As AI makes these labs easier to use and to teach, we expect + more of them—and tools like this to help.

+ +

5. Early Deployment and Planned Evaluation

+

With the app live over the lab’s real inventory, we are in a data-collection phase to assess + whether it helps students. Early signals we will watch: whether more issues get surfaced and fixed + (more uptime, less downtime), and whether students use the machines more because the lab is easier to + navigate. We frame this as an in-progress study.

+ +

6. Discussion and Future Direction

+

This is an ongoing R&D initiative, not a finished product. Two near-term directions add the + most value. First, a student-projects gallery linked to the devices that made each + project—an archive and portfolio of student work and an institutional record of it. Second, + AI-assisted inventory creation through the chat: a student uploads a few + photos of tools or hardware and a short description, and the assistant fetches the manuals and drafts + a catalog row for each—making inventory far faster to add and maintain. Farther out: a + digital twin with a lab-wide agent that routes fabrication jobs and coordinates schedules and + trainings; and, longest horizon, a shared operational framework across Cornell’s campuses, so + students move fluidly between labs while each keeps its identity.

+ +

Acknowledgements

+
+

We thank the staff and interns who helped build the MakerLAB; Cornell Tech and Cornell University; + and all the students who have helped make it such an exciting, generative place. Isaac Steinberg + designed the system architecture and wrote all application code for v5 and the current version, + developed with the AI coding assistants Claude Code and Codex.

+

In accordance with ISAM policy, we disclose that a large language model (Anthropic’s Claude) + assisted in drafting and editing this abstract; all technical claims, design decisions, and the + system itself are the authors’ own.

+
+ +

References

+
+

[1] Anthropic, “Model Context Protocol,” 2024. [Online]. Available: + https://modelcontextprotocol.io. [Accessed: May 30, 2026].

+

[2] Anthropic, “Claude,” 2023. [Online]. Available: https://www.anthropic.com/claude. + [Accessed: May 30, 2026].

+

[3] OpenAI, “ChatGPT,” 2022. [Online]. Available: https://openai.com/chatgpt. + [Accessed: May 30, 2026].

+
+ +
+ + diff --git a/docs/isam-2026-demo/abstract-v1.md b/docs/isam-2026-demo/abstract-v1.md new file mode 100644 index 0000000..2bd365e --- /dev/null +++ b/docs/isam-2026-demo/abstract-v1.md @@ -0,0 +1,162 @@ +# The MakerLAB Assistant: AI to Help Operate, Fix, and Build in Makerspaces + +**ISAM 2026 — Demo Extended Abstract (draft)** + +> This Markdown mirrors the typeset version. The submission artifact is **`abstract.pdf`** +> (ISAM two-column format); regenerate it from `abstract.html` with the Chrome command in `DECISIONS.md`. + +**Isaac Steinberg¹, Niti Parikh², and Miguel Ramirez Peraza³** + +¹ Isaac Steinberg; MBA '26, Johnson Cornell Tech; ies22@cornell.edu +² Niti Parikh; Director, Learning Spaces & MakerLABs, Cornell Tech; ntp27@cornell.edu +³ Miguel Ramirez Peraza; MakerLAB Intern, Cornell Tech; ramirezperazamiguel@gmail.com + +--- + +## Abstract + +Academic makerspaces accumulate substantial operational knowledge: machine documentation, setup +procedures, safety rules, materials, inventory, and fabrication know-how. That knowledge is scattered +across shared drives, URLs, videos, institutional memory, staff, and repair vendors rather than +centralized, and it is mostly in English. At a lab like the Cornell Tech MakerLAB — seven-day access, +lean staff, students at every skill level — access to this knowledge ends up unevenly distributed, and +the learning curve is steep: students must ideate, +find the right hardware, recall procedures, and run complex multi-machine setups. We demonstrate the +**MakerLAB Assistant**, a conversational AI layered over a structured operational database (hosted in +Notion) within the *MakerLAB Tools* app. It gives students instant, anytime access to the inventory +and the lab's specifications in plain language and many languages: find the right tool, follow +manual-grounded setup and troubleshooting, log a maintenance ticket, and scope multi-machine projects. +The same database is exposed as a live Model Context Protocol (MCP) server, so attendees can query the +lab from an LLM client such as Claude or ChatGPT. The demonstration is interactive: visitors browse the catalog, +scope a project, and troubleshoot an example issue on a 3D printer. The app is already deployed at the +Cornell Tech MakerLAB over an initial catalogue of 100 machines, and we frame this as an ongoing R&D +initiative whose long-term goal is a shared operational framework across Cornell's campuses while +preserving each lab's local identity. + +## 1. Background and Motivation + +The project began on the floor of the Cornell Tech MakerLAB. An intern (a co-author) built the first +inventory app in Streamlit to search the lab's hardware — work that organized the data and framed the +problem. A second co-author, volunteering as a "SuperMaker," kept hitting the same friction: looking +up a manual whenever something broke, or digging for a laser cutter's specs just to design a case that +would fit. He added an AI layer over the inventory. The director then posed the guiding question: +could a student *describe a project* and have it **decomposed against the tools the lab actually +has**? Pairing the inventory with each machine's manual and setup procedures turns a static list into +something generative — a step-by-step account of the tooling and workflow a project requires. (An +early version produced how-to infographics and renders; today the system generates grounded text that +can seed an image on demand.) + +The lab runs on lean staff and offers open access, and staff are often busy fabricating for classes +and projects. When no one is on the floor, the knowledge of what each machine does, who may use it, +and how to set it up is distributed, imperfect, and mostly in English — so access falls unevenly +across students. + +Three needs recur, and each routes today to a human bottleneck. Students need to **operate** a machine +(where is it, how do I start, what training and PPE does it require?); to **debug** a machine and +**log a maintenance ticket** when it throws an error mid-job; and to **scope** a project spanning +several machines. The MakerLAB Assistant lowers all three at once — shared context for operating, +planning, and creating in the lab. + +## 2. System Overview + +*MakerLAB Tools* treats the lab's operational knowledge as structured, typed data rather than a static +list. The schema is normalized — tools, categories, locations, individual units, resources, +setup/safety procedures, and maintenance logs — and hosted in Notion, keeping staff editing in a tool +they already use. The web application (Next.js / React, deployed on Vercel) presents two surfaces: a +**gallery** with fuzzy ranked search and category, material, training, and location facets across +every published machine (Fig. 1), and a **tool detail** page showing description, location, required +training, PPE and use restrictions, emergency-stop guidance, linked SOPs and manuals, and a live table +of individual units with status, condition, and serial. + +Overlaying both surfaces is the **MakerLAB Assistant** — a single unified assistant rather than a +handful of separate tools (Fig. 2). From any page it answers questions, walks through setups, and logs +maintenance tickets; near-term, it will also help create and manage inventory and schedule trainings. +Rather than baking the catalog into a prompt, it reasons over the data through tool-calling, augmented +with web search, document fetch (manuals and SOPs are pulled server-side and read in full), and vision +(a photo of a machine or an error screen). Its context scales with place: from the gallery it carries +a lightweight index of every tool and its resources; opened from a tool page it loads that machine's +full detail and linked manuals, becoming a domain expert on the machine in front of you. It answers in +the language it is asked. The app is lightweight and **white-label** — a new lab connects its own +Notion workspace through environment variables and hosts on serverless infrastructure — so other labs +can adopt it. + +## 3. The Demonstration + +The demonstration is interactive: visitors drive the live app. + +**3.1 Browse and scope.** Visitors browse the catalog, then ask the assistant to scope a project — +e.g., *"I want to make a wooden stand for my phone and tablet with 3D-printed parts; which machines +and steps would I need?"* It returns a start-to-finish, training-aware plan that decomposes the build +into laser-cut plywood parts and 3D-printed parts, each mapped to the right machine and grounded in +the lab's actual inventory (Fig. 2) — turning a vague idea into an executable plan. + +**3.2 Troubleshoot and log a ticket.** On a machine page, visitors ask a hands-on question — say, how +to replace the filament on the Bambu Lab X1-Carbon. The assistant pulls the printer's SOP and walks +through it step by step on the touchscreen (Fig. 3), in any language. And when a machine actually +faults, the same chat files a maintenance ticket on the spot — so the machine stays online and the +issue is captured rather than lost. + +**3.3 Bring your own AI (MCP).** The database is also a live, standards-based MCP server [1] +(streamable HTTP) with tools to list, search, and inspect machines, units, and maintenance history. +Attendees connect an LLM client — such as Claude [2] or ChatGPT [3] — and query the lab from a tool +they already use — reaching the linked manuals and grounding a 3D print or laser-cut SVG in the lab's +actual build and bed dimensions, coupling design files to the hardware that will make them. + +**3.4 Feedback and requirements.** We gather visitor feedback throughout. Requirements are light — the +footprint of a standard table, plus power, reliable Wi-Fi, a couple of tablets, and a monitor. + +## 4. Why a Demonstration + +This work is best experienced, not read. The point is what the assistant takes off a student's plate — +planning a build, recalling a setup, fixing a jam, filing a ticket — normally a hunt through manuals +or a wait for staff. By simplifying these workflows, it lets students take on more +ambitious projects, finish them faster, and learn the tools sooner — raising the number, complexity, +and quality of what gets made. A demo is the best way to show this, gather feedback from students and +other labs, and let those labs adopt it; the code will be openly accessible to read and run. As AI +makes these labs easier to use and to teach, we expect more of them — and tools like this to help. + +## 5. Early Deployment and Planned Evaluation + +With the app live over the lab's real inventory, we are in a data-collection phase to assess whether +it helps students. Early signals we will watch: whether more issues get surfaced and fixed (more +uptime, less downtime), and whether students use the machines more because the lab is easier to +navigate. We frame this as an in-progress study. + +## 6. Discussion and Future Direction + +This is an ongoing R&D initiative, not a finished product. Two near-term directions add the most +value. First, a **student-projects gallery** linked to the devices that made each project — an archive +and portfolio of student work and an institutional record of it. Second, **AI-assisted inventory +creation** through the chat: a student uploads a few photos of tools or hardware and a short +description, and the assistant fetches the manuals and drafts a catalog row for each — making +inventory far faster to add and maintain. Farther out: a **digital twin** with a lab-wide agent that +routes fabrication jobs and coordinates schedules and trainings; and, longest horizon, a shared +operational framework across Cornell's campuses, so students move fluidly between labs while each keeps +its identity. + +## Acknowledgements + +We thank the staff and interns who helped build the MakerLAB; Cornell Tech and Cornell University; and +all the students who have helped make it such an exciting, generative place. Isaac Steinberg designed +the system architecture and wrote all application code for v5 and the current version, developed with +the AI coding assistants Claude Code and Codex. + +In accordance with ISAM policy, we disclose that a large language model (Anthropic's Claude) assisted +in drafting and editing this abstract; all technical claims, design decisions, and the system itself +are the authors' own. + +## References + +[1] Anthropic, "Model Context Protocol," 2024. [Online]. Available: https://modelcontextprotocol.io. [Accessed: May 30, 2026]. + +[2] Anthropic, "Claude," 2023. [Online]. Available: https://www.anthropic.com/claude. [Accessed: May 30, 2026]. + +[3] OpenAI, "ChatGPT," 2022. [Online]. Available: https://openai.com/chatgpt. [Accessed: May 30, 2026]. + +--- + +### Figures + +- **Fig. 1** `fig-gallery.png` — gallery: fuzzy search + category/training/material/location facets across ~100 machines; language selector top-right. +- **Fig. 2** `fig-project.png` — live project scoping: a phone-and-tablet stand decomposed into laser-cut Baltic-birch parts (with a living hinge) + 3D-printed parts. +- **Fig. 3** `fig-assistant.png` — live exchange on the Bambu Lab X1-Carbon: "how do I replace the filament?" → SOP-grounded step-by-step (unload old, load new). diff --git a/docs/isam-2026-demo/abstract-v1.pdf b/docs/isam-2026-demo/abstract-v1.pdf new file mode 100644 index 0000000..d8a39d9 Binary files /dev/null and b/docs/isam-2026-demo/abstract-v1.pdf differ diff --git a/docs/isam-2026-demo/fig-assistant.png b/docs/isam-2026-demo/fig-assistant.png new file mode 100644 index 0000000..fa92a0a Binary files /dev/null and b/docs/isam-2026-demo/fig-assistant.png differ diff --git a/docs/isam-2026-demo/fig-gallery.png b/docs/isam-2026-demo/fig-gallery.png new file mode 100644 index 0000000..736ca4c Binary files /dev/null and b/docs/isam-2026-demo/fig-gallery.png differ diff --git a/docs/isam-2026-demo/fig-project.png b/docs/isam-2026-demo/fig-project.png new file mode 100644 index 0000000..436508c Binary files /dev/null and b/docs/isam-2026-demo/fig-project.png differ diff --git a/docs/isam-2026-demo/fig-tool-detail.png b/docs/isam-2026-demo/fig-tool-detail.png new file mode 100644 index 0000000..a85a585 Binary files /dev/null and b/docs/isam-2026-demo/fig-tool-detail.png differ