PulseOS

Extension
Pipeline Checks
Youtube API

Inspiration

PulseOS is a systems-style project built as a real-time telemetry and detection pipeline for healthier social media use.

PulseOS was inspired by a simple question: if social platforms can optimize endlessly for attention, why can’t we build systems that optimize for healthier usage too? We wanted to treat short-form content consumption like a real-time systems problem, where risky behavior patterns such as doomscrolling, compulsive loops, and low-quality engagement can be detected before they become invisible habits.

What it does

PulseOS monitors how an average user interacts with short-form content like YouTube Shorts and turns that behavior into live risk signals. It captures events such as scrolls, likes, comments, and session duration, then scores patterns related to wellness risk, amplification-style loops, privacy pressure, and meaningful engagement.

How we built it

We built PulseOS as a small end-to-end systems pipeline. A Chrome extension acts as the edge collector and captures live interaction signals from Shorts. Those events are sent to a local backend, normalized into an event stream, and processed by a detection engine written in C with a lightweight backend bridge. The frontend dashboard in Next.js acts as a control plane, showing live scores, alerts, runtime state, and recommended interventions.

At a high level, the system computes behavior signals such as:

$$ \text{session health} \approx 100 - (w_1 \cdot \text{wellness risk} + w_2 \cdot \text{privacy risk} + w_3 \cdot \text{amplification risk}) $$

Challenges we ran into

One of the biggest challenges was data access. We initially explored official platform APIs, but we learned that viewer-side behavior is much harder to access than creator-side analytics. That forced us to rethink the architecture and pivot to a browser-extension-based telemetry approach. We also ran into challenges with reliable event capture, extension injection, backend delivery, and keeping the project hackathon-friendly without overengineering it.

Accomplishments that we're proud of

We’re proud that PulseOS feels like more than just a dashboard. It works as a real pipeline with an edge collector, ingestion bridge, detection engine, and control-plane interface. We also successfully shifted the project toward the average user, which made the product vision more meaningful and the systems design more coherent.

What we learned

We learned that the “right” data source changes completely depending on who the user is. Building for an average user required a very different approach from building for creators. We also learned how important it is to keep heuristics explainable, especially in a project about trust, safety, and wellness.

What's next for PulseOS

Next, we want to improve the viewer-side behavior model with richer signals like dwell time, skip rate, and repeated exposure patterns. We’d also like to strengthen the systems side further by using the C engine more directly at runtime, improving event buffering, and expanding PulseOS into a broader real-time wellness observability platform for social media.

311 EXTRA CREDIT

The systems-related pieces in PulseOS are the parts that make it behave like a small real-time telemetry pipeline rather than just a website.

Here’s the full systems story:

Edge Collection The Chrome extension acts like a client-side collector. It watches YouTube Shorts and emits low-level events such as scroll, like, comment, and session_tick.

Event Ingestion The backend receives those events through HTTP endpoints, validates them, normalizes them, and appends them into the local event stream. This is the ingest layer of the system.

Structured Event Stream Events are stored in a consistent schema with fields like timestamp, content ID, session length, and metadata counters. That schema is what lets different parts of the system communicate reliably.

Detection Engine The C engine is the low-level processing layer. It parses events, maintains rolling context, computes heuristic risk scores, and emits alerts. That is the core processing component.

Rolling Windows PulseOS now computes short runtime windows like 1m, 5m, and 30m. This is a common systems pattern for stream processing and real-time monitoring.

Buffer Model The project now includes a ring-buffer style model with capacity, utilization, and dropped-event tracking. That is a classic systems concept for bounded streaming workloads.

Runtime Telemetry PulseOS tracks operational stats such as:

buffer size buffer utilization dropped events events per minute events per second last processed timestamp Control Plane The dashboard is not just a UI, it acts like a control plane. It visualizes runtime state, risk signals, rolling windows, and intervention recommendations, similar to an observability dashboard.

Process Separation The project is split into distinct roles:

extension as collector backend as ingestion/API bridge engine as processing runtime frontend as monitoring/control plane Fallback Engine Path Even the JS fallback reflects systems thinking, because it preserves the same pipeline contract and output format when the compiled C runtime is unavailable.