Posted on

Team Status Report for 2/14

This week, after the meeting on Wednesday with faculty and TA, the team thought that defining the right use-case example and requirement are still the main issue.

The team decided to refine SPARK’s core use-case requirements, which include four primary action categories: Synthesis, Text Reformatting, Keyword/Phrase Searching, and Response Drafting. Each use case was rewritten to include measurable behavior and concrete examples to better define expected functionality.

The team also worked together on making the block diagram for the SPARK system and discussed and prepared the design review slides for the presentation next week.

=======================================================

Part A (Sida) with respect to considerations of public health, safety or welfare:

Regarding public health, some people have developed a psychological attachment/affinity to their chatbots. Although our project’s features don’t include chatting with the LLM, we still need to be cautious about the longevity of our project. Our usage of locally hosted and open-source LLMs ensures that users won’t suddenly lose access to the model.

Part B (Leonard) with consideration of social factors:

On the topic of social factors, there are many concerns about AI replacing the human workforce. Our project’s scope is to increase the user’s work efficiency, not to replace any human effort. It remains to be determined what AI’s impact on society will be, but our goal is to empower each user.

Part C (Tatyana) with consideration of economic factors:

The cost of using AI poses an economic barrier to people with different financial statuses. Large businesses can afford to pay hundreds of thousands of dollars to self-host SOTA models or use API services. Individuals can pay monthly subscriptions to use less-capable models at slower rates. Self-hosting a decent model for everyday tasks isn’t financially reasonable yet, but our project can show that smaller models can be used to perform specific tasks and can meaningfully empower users with a one-time investment.

Posted on

Leonard’s Status Report for 2/14

This week I focused on the hardware architecture for SPARK and finalized several key component decisions, including the Raspberry Pi Pico (RP2040) as the MCU and the Waveshare 2.4” SPI LCD module as the display.

For user input, there are four pushbuttons for core interactions, a three-position slide switch for different mode selections, and a rotary encoder option for future UI expansions.

For future weeks, I plan to assemble the full system on a breadboard to verify functionality and stability. The goal is to validate hardware behavior before committing to schematic capture and custom PCB layout design.

Posted on

Leonard’s Status Report for 2/7

This week, I focused on defining the testing, verification, and metrics framework for SPARK. I helped formalize how we will verify core design requirements and validate use-case requirements. For each requirement, there is at least one concrete test and associated quantitative metric. This will provides a clear basis for evaluating performance beyond a simple functional demo.

In addition, I began planning a standardized testing sample for SPARK. The goal is to create a consistent set of writing tasks so that feedback from different users is comparable and not overly influenced by individual writing styles or habits. This will allow us to collect more meaningful and repeatable evaluation data.