How the work
came together.

Problem

Creating assembly work instructions manually required repetitive formatting, image placement, revision work, and quality checks. The process took engineering time without adding technical value.

Constraints

• Fit the company's existing Excel and PowerPoint workflow
• Preserve revision history
• Support varied assembly complexity and image counts
• Flag missing information before output

Engineering approach

I separated structured content from presentation. Engineers enter parts, equipment, steps, hazards, PPE, and revision information in Excel; Python validates the inputs, processes images, and assembles the presentation.

Key decisions

• Selectable 2-, 4-, or 8-step page layouts
• Custom PPE by assembly
• Revision history retained rather than overwritten
• Validation focused on actionable missing fields
• Standardized parent and subassembly references

Implementation & measurement

The application builds PowerPoint work instructions from structured worksheets and organized image folders. Multiple shorter instructions that normally took about six hours were rebuilt with the generator in roughly one hour — an 80–90% reduction. Longer instructions were expected to save a greater percentage but were not formally benchmarked.

What I learned

Useful automation must fit the engineer's real workflow. The biggest gains came from making the system flexible enough for different assemblies while keeping output predictable for operators.

Problem

Work instructions live on the shop floor as printed documents, but revisions are issued continuously in engineering. That gap is a quality and audit exposure: an operator can be working from a printout superseded months ago with no indication anything is wrong.

Moving every work instruction online was under consideration, but the floor's established workflow is paper-based, and digital-only access would have slowed the people doing the actual assembly work. Both positions were correct — the revision risk was real, and so was the workflow cost.

I built the option that satisfied both. Operators keep working from paper exactly as before; every printed cover carries a QR code that resolves to the current revision for that assembly. Traceability is guaranteed without changing how anyone works.

The decision the system hinges on

The URL encoded in each QR code is derived from the assembly number alone. The revision never appears in it.

This is what makes the system work on physical paper. A code printed on revision C is byte-identical to one printed on revision D — same image, same URL — and only the page behind it changes. An operator holding an outdated printout scans their own code and is told the current revision, which is precisely the failure the system exists to catch.

Keying URLs to revisions instead inverts the behavior into something actively dangerous: a stale printout would resolve to its own matching stale page and confidently report itself as current. Because these codes are printed onto paper distributed across a facility, the choice is effectively irreversible once documents are in circulation — changing the scheme later would mean reprinting the entire catalog.

Constraints

• Printed codes must stay valid across all future revisions, with no reprinting
• The floor's existing paper workflow must not change
• Integrate into the existing Python work-instruction generator rather than replacing it
• Fail safe: never present an invented or stale revision as authoritative
• Survive personnel turnover without invalidating printed documents

Failure-mode design

Ordering and failure handling were treated as first-class design concerns rather than error handling:

• Publishing happens only after the document saves successfully, so a failed save can never leave a live page advertising a revision that was never released
• The system refuses to publish when no revision can be determined rather than substituting a default — an invented revision on a shop-floor-facing page is worse than no page at all
• Status pages refresh on every generator run regardless of whether that document carries a code, because codes printed on earlier revisions remain in circulation
• A fallback page handles any unpublished or mistyped URL, explicitly telling the operator that the absence of a record does not imply their copy is current, and directing them to verify through engineering records

Automated revision cross-checking

Document parsing extracts revision data from released work-instruction PDFs and from controlled engineering drawings on network storage, compares the two, and renders a status banner flagging documents that have fallen behind their drawing — surfacing revision drift that previously went undetected. Multi-variant instructions carrying a revision matrix rather than a single revision are detected and handled separately, with the relevant matrix rendered inline for manual verification.

Continuity and credential hygiene

Because every QR code encodes a hostname derived from the hosting account, that account name is permanently embedded in printed documents. The inherited system was hosted on an individual employee's personal account — an arrangement that would have invalidated every printed code the moment that person left, with no remedy short of reprinting the catalog. I migrated it to an organization-owned account with institutional credentials and documented recovery procedures, then republished the full catalog to the new location.

I also remediated a hardcoded API token found in the inherited source, moving authentication to an environment variable with a controlled fallback, and produced a formal IT provisioning request covering credential storage, token scoping, and rotation.

What I learned

The strongest technical decision here was not the implementation — it was recognizing which choice was irreversible and reasoning about it before any paper was printed. The alternative URL scheme looks reasonable at first glance and fails in exactly the case the system exists to protect against. Physical artifacts make software decisions permanent in a way deployment does not, and that changes how much analysis a decision deserves up front.

Problem

Create a portable stand that lets an operator rotate a long square-ended key against deliberate resistance while keeping the mechanism stable, safe, and visually understandable for demonstrations.

Constraints

• Approximately 30 ft-lb target resistance
• Operator controls the top while the stand remains self-supporting
• Foldable or transportable frame
• Machinable parts and commonly available hardware
• Access for bearing service and preload adjustment

Bearing strategy

Two tapered roller bearings are arranged back-to-back so controlled axial preload can create resistive torque while supporting radial and moment loads. The cartridge includes shoulders for the cups and removable end retention.

Shaft & retention

The center shaft carries the rotating square interface and uses a threaded lower end for preload retention. The design work considers weldability, thread selection, locking hardware, and access after assembly.

Structure & ergonomics

An 80/20 aluminum-extrusion frame supports a separate standing platform and central torque cartridge. Custom joints, leg geometry, material choices, and trip hazards were evaluated together rather than independently.

Validation the design still required

The design was handed over before fabrication. Turning it into a working stand would still require measuring the tripod interface and purchased components, then tolerance confirmation, preload-to-torque testing, structural checks, and an operator stability trial. No build or performance result is claimed.

Problem

A newly introduced assembly needed a repeatable throttle test. A one-time PASS/FAIL indication was not enough; engineers also needed a useful record when failures recurred.

Constraints

• Offline Raspberry Pi operation
• Simple operator interaction
• Reliable electrical measurement
• Clear PASS/FAIL communication
• Persistent records without exposing test limits publicly

Test workflow

The interface guides login and test preparation, displays timed instructions, acquires measurements through the ADC, evaluates the captured range, and presents a clear result before optional label printing.

Traceability

Each test records timestamp, operator initials, result, measurement summary, and diagnostic fields in monthly CSV data. The purpose is not just record keeping—it is to make patterns easier to investigate.

Operator design

The testing view shows only the instructions and countdown needed at that moment. After the run, it transitions to result actions so the operator is not asked to interpret a cluttered screen.

What I learned

Production test systems sit between hardware, software, and human behavior. A technically correct measurement still fails if the operator sequence and engineering record are unclear.

Problem

Evaluate whether an autonomous mobile system could support environmental monitoring in cleanroom settings without compromising the requirements of the controlled environment.

Constraints

• Sterility-assurance and microbiology practices
• Cross-functional laboratory coordination
• Proof-of-concept hardware
• Clear, repeatable protocols
• Employer confidentiality

Protocol development

I helped convert broad technical questions into four defined studies covering particulate behavior, disinfection, robustness, and mobility. Each needed a repeatable method and a clear connection to project risk.

Execution & analysis

The first three protocols were executed and analyzed during the internship. Work required rapidly learning laboratory practices, coordinating resources, recording observations, and interpreting evidence at a proof-of-concept level.

Communication

The project included technical presentations and demonstrations for stakeholders with different backgrounds. Communicating the purpose, limitations, and next questions was as important as running the studies.

What I learned

Validation is a design activity. A strong protocol does more than generate data—it isolates the question, respects constraints, and gives the team a defensible basis for the next decision.

Problem

Advance a student nanofiber research effort for the Global Air Quality Trekkers team while preserving enough experimental context for each week's work to build on the last.

Archivist system

During Spring 2025, I documented weekly testing, summarized findings, and recorded recommendations for subsequent trials. This turned the archive into a research-planning tool rather than a passive log.

Technical work

I trained to operate the electrospinning equipment independently and supported the team's testing and material-production work while following laboratory safety procedures.

Leadership transition

As team lead in Fall 2025, I organized research areas, member training, experiment coordination, and preparation for technical design reviews. The team expanded from about three to six members and testing increased from 1–2 to 4–5 trials per week.

Result & limit

The team successfully produced a sheet of nanofibers. It did not reach a completed air-quality product, so the value of the project is the research progress, documentation, and team capability—not a finished-device claim.

What I learned

Research teams move faster when results, unsuccessful trials, assumptions, and next questions are all preserved. Leadership often means building that system of continuity.