Abstract
"Technology is neither good nor bad; nor is it neutral."
— Melvin Kranzberg
Institutions now hand their decisions to AI systems because those systems are fast and cheap, but the same systems can quietly work against the people they serve. My technical project builds a semantic search engine to help UVA students find courses, where the aim is to serve the user. My STS research studies real-time algorithmic pricing, where firms use AI and data collection to charge each shopper the most they will pay for every sale. Both systems stand between an institution and the people who use it, and both can help those people or take advantage of them depending on how they are built and who can see how they work. The engineers who build these systems are making ethical choices along with technical ones, because the design shapes how people are treated.
The technical portion of my thesis produced a design proposal for a semantic search engine layered over UVA's Student Information System. Today a student who types "courses about wartime history" has to guess the right keywords and dig through several department catalogs by hand. My design lets students search the catalog in plain language instead of exact-match terms. The system reads each course record with a sentence transformer model and stores it as a vector embedding. Following Van Deventer et al. (2024), it also has a language model write an "ideal" course description for each entry, so courses with thin catalog text still get matched well. When a student searches, the system embeds the query, finds the closest courses by cosine similarity, and applies a keyword-weighted filter from Malo and Al-zebari (2025) to drop matches that look related but are wrong for the context. The engine sits on top of SIS as a discovery layer and changes nothing in the enrollment system underneath. If UVA adopts it, students should spend less time searching and find more courses across departments they would have missed.
In my STS research, I studied how the groups fighting over real-time algorithmic pricing push their agendas in public. I used the social construction of technology framework and gathered the public documents each side produces, including corporate marketing pages, trade association posts, federal lawsuits and studies, and advocacy campaigns. My analysis found that the groups are not even arguing about the same thing. Industry defends time-based pricing that shifts with demand, antitrust regulators attack algorithms that coordinate prices across competing firms, and consumer advocates attack person-based pricing built from personal data. Each group ties its definition to a different piece of a split research record, so more studies simply add to the fight instead of ending it. Each group also chases the kind of closure its own institution allows, firms by redefining the problem, agencies by enforcement, and advocates by publicity and law, because whichever definition is used decides who governs the technology. The one case where the dispute closed came from public visibility, when Consumer Reports documented up to 23 percent price variances on the same grocery items and Instacart dropped the practice. My main finding is that transparency, not a blanket ban, is the remedy most likely to achieve closure, because the opacity surrounding the technology is the condition that keeps the fight open.
Doing the STS research changed how I understood my technical proposal. While designing the engine, I asked whether it would return relevant courses in a quick and useful manner, the technical questions any engineer would ask. The pricing research showed me those are not the only questions worth asking, because the same technical parts, historical data, embeddings, and optimization, treat people well or badly depending on whose ends the system serves and how transparent the technology is. My approach had been narrowly technical, and I have since considered my design's further consequences. Students from different cultures may semantically associate concepts and courses differently than the engine predicts, changing the quality of the results for different users. Students might also become reliant on the system, waiting until the last minute to build their schedules or considering fewer classes by only looking at the top recommendations. Seeing these effects meant looking at the engine, the university that would run it, and the students subject to it as one system rather than a technical problem on its own. That is what STS adds to engineering practice, and an engineer who can see these consequences is the one who can take responsibility for them.
