Carnegie Mellon ECE Capstone, Spring 2026 – Sida Cheng, Tatyana Cruz, Jinghan(Leonard) Cheng
This week, the main focus is on the ethical considerations associated with the SPARK system. Worst-case scenario is considered as well as red teaming from other teams.
On the hardware side, additional components have now arrived. However, the PCB has been delayed and is now expected to arrive next week.
In the upcoming week, hardware assembly should begin once the PCB arrives. In parallel, focus should be shifted toward improving the software and testing framework. The plan is to organize smaller group meetings with Tatyana that is dedicated to discuss and develop the code testbenches required for system testing and verification.
This week, the team focused on reviewing the feedback received during the design review and identifying areas for improvement in the testing and verification plan for the SPARK system. Based on the comments from the reviewers, the team discussed ways to make the validation process more systematic and measurable.
For upcoming week, the team will work to clarify how system performance will be measured, including accuracy of generated outputs and the effectiveness of the system in supporting user interaction scenarios.
The team will also have a ethics discussion related to the SPARK system. As part of this process, the team will hold a short discussion session to consider potential ethical implications of the product if it were widely used or misused. The results of this discussion will be summarized and shared within the team communication channel, and the ideas will later be refined and incorporated into the ethics section of the final project report.
This week, the hardware development of the SPARK system progressed from the design stage to the implementation stage. The final Gerber files for the PCB were generated using the CAM processor. These files were reviewed and successfully submitted to the PCB manufacturer JCLPCB, and the PCB boards have now been ordered. In parallel with the PCB order, most of the required hardware components for the prototype have already been purchased and delivered. Some remaining components are still in transit and are expected to arrive soon.
The focus for the upcoming week will be to refine the testing and verification plan for the SPARK system based on the feedback received for the design review report. The idea is to use another LLM to judge whether the results can be considered correct or not.
This past week I focused on two main things: integration testing and cleaning up the page scraping application.
For integration testing, I worked on connecting the host-side pipeline to the Jetson by adding the calles to the the model and verifying that SparkDB is correctly handling reads and writes. Getting the model api call up was a solid step forward since it’s is closer to the mvp and the product offering og our sysetem, and confirming SparkDB behavior gave us more confidence that context is being stored and retrieved the way we expect. That said, there are still some open issues going into next week, so integration is very much still in progress rather than wrapped up.
On the page scraping side, I did a round of cleanup that was overdue. The main things I tackled were fixing some broken selectors and parsing logic that were causing the scraper to miss or misread certain page content, and refactoring the code structure to make it easier to work with going forward. The scraper feeds directly into the context capture pipeline, so having the parsing logic actually reliable matters a lot once real pages start flowing through during integration. The refactor also just made the code more efficient and easier to explain to the rest of the team.
Progress is on schedule overall. Next week I plan to keep pushing on the integration side, specifically resolving the open issues from this week and working toward a more stable end-to-end run of the full pipeline.
This week my primary focus was on the design report, both in terms of writing and visual documentation. On the writing side, I took ownership of restructuring how we frame SPARK’s story in the report. I rewrote the introduction and use-case sections to first build the case for why on-device AI is a necessity in professional environments, making every performance requirement feel motivated rather than arbitrary. I also wrote and revised the design requirements section, working through the context acquisition, privacy filtering, and signal bridging requirements in detail. This included identifying that the extraction pipeline bottleneck sits on the host CPU rather than the transport layer, and reworking the latency model to use a Time-to-First-Token constraint to better account for multi-window summarisation, our heaviest task.
On the visual side, I created the host-side architecture diagram showing the full UI and context extraction pipeline, including the Hotkey Listener, UI Panel, Text Scraper, Browser Tab Reader, and Privacy Filter subsystems. I also produced the intelligence node diagram documenting the Control Script, WindowContextTracker, SparkDB persistent storage, and llama-server inference engine. These diagrams were a direct response to feedback from the design presentation, where reviewers noted the architecture needed clearer visual documentation.
.
Progress is on schedule. Window Selection Logic is at 80% complete per the project Gantt chart, which aligns with where we expected to be this week. Integration Testing is scheduled to begin March 5, which is the focus for next week.
Next week I am focused on beginning integration testing alongside Sida, specifically connecting the host-side context capture pipeline to the Jetson inference stack over UART and verifying that SparkDB is correctly receiving and writing snapshots. I also plan to begin work on the Touch Screen UI, which is scheduled to start March 5 per the project timeline. The goal for integration is not a fully working system but a first end-to-end run of the Capture-Distill-Infer cycle so we can identify where the bugs are early.
This week the team finished and submitted the design report. The biggest change from the draft was how we tell SPARK’s story. Rather than jumping straight into architecture, the report now opens by building the case for why on-device AI is a hard requirement in legal, healthcare, and compliance settings, not just a nice-to-have. That framing ended up making the use-case requirements feel a lot more motivated, since every performance target is now tied to a specific reason the product would fail without it.
On the technical side, we finalized a number of specs that were still estimates going into the week. UART baud rate is set at 921,600, which keeps bridge latency to ~13 ms per packet and takes it completely off the critical path. We also reworked the latency model to use a Time-to-First-Token constraint instead of a hard round-trip budget, which is more honest about how multi-window summarisation actually behaves, since it’s the heaviest task in the system and shouldn’t be held to the same deadline as a single autocomplete call. For the LLM, we settled on Phi-3 Mini running via llama.cpp on the Jetson AGX Xavier, with benchmark data showing 25 tokens/s output speed which satisfies our 20 tokens/s requirement.
We also added detailed diagrams for all five subsystems following feedback from the design presentation. That was probably the most concrete deliverable this week, since the architecture is now fully documented with dedicated figures rather than described in prose alone.
Next Week: The goal is first integration between the host-side Python app and the Jetson inference stack, connecting the context capture pipeline over UART, confirming SparkDB is writing snapshots correctly, and getting the full Capture-Distill-Infer cycle running end-to-end. We’re expecting to find bugs, not a working system. Formal integration testing starts the week of March 17 per the schedule.
Biggest open risk: Whether the 500 ms TTFT target holds under real workloads once the full context retrieval pipeline is active, rather than the isolated benchmark conditions we’ve been testing against. Our early integration should give us time to identify and address any gaps before the evaluation phase.
A was written by Leonard, B was written by Tatyana and C was written by Sida.
Part A: SPARK is designed to be useful far beyond the academic environment in which it was built. For a non-technical user, the barrier to AI assistance has never really been access to the technology itself, it has been the trust and setup cost that comes with it. A small business owner, a community health worker, or a local journalist does not have an IT department to configure a local LLM, and they are unlikely to read a privacy policy carefully enough to understand what a cloud tool does with their data. SPARK removes both of those barriers: it is a plug-in USB device that works without configuration, and its privacy guarantee is physical rather than contractual, the data never leaves the machine by design. This matters most for users in contexts where a data breach or regulatory violation is not an abstract risk but a concrete one, such as a clinic in a rural area handling patient records, a small law firm without enterprise-grade cloud security, or a freelance professional working with confidential client material. These users exist everywhere and share the same underlying need: powerful writing assistance that does not require them to be technically sophisticated or to place trust in a company they have never heard o
Part B: .Different cultures carry different expectations around privacy, data ownership, and trust in technology, and SPARK’s design accommodates that variation by default. In cultures where institutional trust is low or where government surveillance is a lived concern, the premise of a productivity tool that requires work to pass through a third-party server is not favorable regardless of capability. SPARK’s local-only architecture removes that barrier entirely. There is also a meaningful economic dimension: because SPARK is built on open-source models and infrastructure, it avoids the subscription costs that make cloud AI tools inaccessible in lower-income contexts. In professional cultures where confidentiality is not just a legal requirement but a deeply held ethical norm, such as attorney-client relationships or doctor-patient communication, SPARK’s design aligns with the values of the user rather than asking them to compromise those values for convenience.
Part C:The environmental footprint of AI is increasingly a point of concern, and SPARK’s architecture takes a meaningfully different position than cloud-based alternatives. Every query sent to a cloud AI provider is processed in a large data center, consuming significant energy and water for cooling at scale. SPARK performs all inference locally using small, quantized models on the Jetson AGX Xavier, which are substantially more energy-efficient than the large models running in cloud data centers. Smaller models require fewer computational resources per query, which translates directly to lower power draw and a reduced carbon footprint per interaction. The system is also designed for longevity: by running on existing hardware rather than requiring a continuously updated cloud subscription, SPARK reduces pressure to frequently upgrade devices, which in turn reduces electronic waste. The Jetson AGX Xavier was deliberately selected from existing ECE inventory, which aligns with a reuse ethos rather than driving demand for new hardware manufacturing.
In this week, the hardware design for the SPARK system reached a major milestone. I finalized the schematic and PCB layout using Autodesk Eagle. The hardware design portion of the project is considered complete and ready for fabrication.
For the design report, I mainly contributed in the hardware aspects of design requirements, principles, and design trade sections, testing and validation, bills of materials and budget, and risk mitigation.
The primary focus for the upcoming week is hardware assembly and testing. After the parts arrived, I will assemble the parts onto a breadboard for initial testing of the functions. After the system is validated, I will then solder the parts onto the PCB
. 
