DEV Community: debashismohapatra0021

GHOST.OS: The Machine Remembers — Giving Embedded Systems a Forensic Memory

debashismohapatra0021 — Sat, 31 Oct 2026 11:44:08 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

An embedded system can detect a fault and still lose the most important thing: what happened immediately before it failed.

A sensor freezes. A device experiences an impact. A controller resets. The terminal shows an error, but the sequence leading to it may already be gone.

I wanted to explore a different possibility: what if an embedded device could remember its last few seconds?

That idea became GHOST.OS — The Machine Remembers.

GHOST.OS is a local-first embedded instrumentation and post-mortem forensic platform built around an ESP32-WROOM-32 and an MPU6050 six-axis IMU.

It collects inertial telemetry, detects anomalies using deterministic rules, preserves recent measurements in a circular evidence buffer called Ghost Trace, and provides tools to investigate what happened.

Its guiding idea is simple:

Every machine leaves a last transmission. GHOST.OS remembers.

The word ghost has two meanings here. It represents the machine's remaining telemetry evidence, and the visual experience: when an anomaly is detected, a dormant holographic skull awakens and introduces the forensic investigation.

It isn't a chatbot pretending to be a ghost. It is a visual representation of the machine's recovered memory.

Demo

GHOST.OS runs locally because it needs access to hardware connected to the developer's laptop.

GitHub repository:

https://github.com/debashis-sharingan-21/ghost-os

Working prototype video:

The physical demonstration shows the ESP32 and MPU6050 transmitting real sensor measurements to the GHOST.OS dashboard. The software investigation features can also be demonstrated using repeatable simulator-generated scenarios.

The hosted showcase is read-only. Live hardware communication and local model execution require running the application locally.

Code

GHOST.OS is open source.

debashis-sharingan-21 / ghost-os

Offline-first AI for embedded diagnostics. Investigate ESP32/STM32 telemetry, reconstruct hardware faults, and explain the machine's last transmission using local open-weight models.

GHOST.OS — The Machine Remembers

Real-Time ESP32 Telemetry, Deterministic Anomaly Detection & Forensic AI

"Every machine leaves a last transmission. GHOST.OS reconstructs what happened."

1. Cinematic Introduction & Hero View

When an autonomous rover tumbles down an embankment, a drone drops from the sky, or a robotic joint freezes on a factory floor, ordinary loggers crash or write corrupt partial buffers. The physical state leading up to the impact is permanently lost.

GHOST.OS is a specialized real-time embedded instrumentation and post-mortem forensic platform. Built around the ESP32-WROOM-32 dual-core microcontroller and the MPU6050 6-DOF IMU, GHOST.OS captures high-rate inertial kinematics, detects physical anomalies using deterministic sliding-window rules, locks a 200-frame circular pre-fault evidence ring buffer (Ghost Trace), and synthesizes evidence-grounded hypotheses using local open-weight AI — entirely offline and air-gapped.

2. The Problem: Why the Machine's Last Transmission Matters

In edge computing and embedded robotics:

The Black Box Fallacy…

View on GitHub

Documentation:

How I Built It

The central engineering decision was to separate sensor acquisition, deterministic fault detection, evidence preservation and AI-assisted interpretation.

The architecture has three main execution environments.

1. ESP32 — Hardware and firmware

The ESP32 communicates with the MPU6050 over I²C and transmits structured ghost.v1 JSON Lines over USB serial.

The firmware is written in Arduino C++ and compiled using PlatformIO.

Parameter	Configuration
SDA / SCL	GPIO 21 / GPIO 22
MPU6050 address	`0x68`
Serial baud rate	115200
Target telemetry	10 Hz
Status LED	GPIO 4

The firmware was successfully compiled and flashed to the ESP32-WROOM-32 through COM9.

The MPU6050 initialized successfully, completed stationary calibration and started transmitting physical sensor measurements.

With the board stationary, the measured acceleration magnitude was approximately 9.85 m/s², consistent with the expected gravity baseline.

The laptop's FastAPI backend received actual serial frames with simulated: false and switched into HARDWARE_SERIAL mode.

2. Laptop — Telemetry and forensic processing

The Python FastAPI backend uses pySerial to receive and validate telemetry.

It handles deterministic anomaly detection, maintains the 200-frame Ghost Trace buffer, preserves pre-fault measurements, and manages recording and replay.

GHOST.OS supports scenarios including free fall, high-G impact, tumble/spin, sensor freeze, thermal spike and brownout.

A separate deterministic simulator provides repeatable scenarios for software testing. Physical sensor events and simulator-injected events remain distinguishable.

3. Browser — Visualization and investigation

The browser receives telemetry through WebSockets and displays live waveforms, hardware status, forensic events, reports and recorded sessions.

When an anomaly arrives, the 3D Ghost HUD reacts with a scenario-specific animation.

Its forensic narrative follows three messages:

THE MACHINE HAS LEFT A TRACE.

RECOVERING LAST TRANSMISSION...

I REMEMBER WHAT HAPPENED.

4. AI Interrogation

GHOST.OS has two distinct reasoning paths.

Deterministic forensic provider: An offline fallback that evaluates measurements and produces observations, numerical evidence, ranked hypotheses and suggested engineering checks.

Ollama provider: An optional integration for local open-weight model inference, intended to interpret preserved evidence.

The distinction matters: the deterministic fallback is not a language model.

The Ollama integration is implemented, but successful real model inference has not yet been independently demonstrated. I do not present deterministic fallback output as an open-weight model response.

5. Digital Afterlife

A fault investigation should not disappear when the dashboard closes.

Digital Afterlife records telemetry sessions as JSON Lines files and supports playback, pause, step-by-step inspection and speeds from 0.5× to 4×.

Why Does Open Innovation Matter?

Embedded systems can produce sensitive information about their operating environment and connected equipment.

I wanted an architecture where telemetry acquisition and forensic investigation could happen locally, without requiring a remote proprietary AI service for every operation.

The Ollama provider is designed to support local open-weight inference. This gives developers control over model selection and the ability to experiment without making a hosted inference service mandatory.

The deterministic forensic engine remains available independently when model inference is unavailable.

Sensor measurements and fault detection stay grounded in application logic, while a language model can assist with interpretation.

Open innovation matters because developers should be able to inspect, run, replace and adapt the intelligence behind their tools instead of depending entirely on a closed service.

The goal is not to make AI responsible for every decision. It is to make forensic analysis more accessible while preserving the underlying evidence.

My Agent Session

GHOST.OS was developed using AI-assisted coding and iterative implementation, code inspection and testing.

The Spirit of It

There is something unsettling about a machine failing without leaving enough evidence to explain why.

The system was working. Measurements were flowing. Then something happened, and the last few seconds disappeared.

I wanted to build something that gives those moments a second life.

The 3D skull is the visual symbol. Ghost Trace is the actual memory.

The most satisfying part of this project has been taking it from a simulated telemetry pipeline to a physical ESP32 and MPU6050 transmission appearing in the GHOST.OS dashboard.

A machine may stop responding. Its last transmission should not have to disappear.

Let's Discuss

What would you want an embedded system to remember when something goes wrong: the last few seconds of telemetry, a detailed fault explanation, or a replayable record of the entire session?

I'd love to hear how other embedded and robotics developers approach failures that are difficult to reproduce.

GHOST.OS — THE MACHINE REMEMBERS.

Every machine leaves a last transmission.

I Wanted an iPhone-Style “More Than Usual” Alert for My Money. So I Built Usually.

debashismohapatra0021 — Thu, 22 Oct 2026 16:35:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I was looking at the Battery Usage screen when I noticed something interesting: iOS wasn't showing usage as an isolated number. It was comparing what was happening today with what was usual for me.

By 7:15 PM, one screen told me:
You're using less battery today than you usually do by 7:15 PM.

It showed 21% today, compared with a 91% average.

Then I checked an individual app. WhatsApp showed 13% battery usage and reported that usage was 10% higher than over the previous seven days.

The screens answered two related but different questions: one compared overall battery use with what was usual by that time of day; the other compared one app with its own recent history. They weren't contradictory. They were different views of the same activity.

These were battery figures, not financial data. But the useful part wasn't either percentage on its own. It was the context behind it:

What is happening now, compared with what is usual for me?

I started wondering whether money could offer that same kind of context.

Not another dashboard asking me to interpret ten charts. Not another budgeting app telling me what I'm allowed to spend. And not a system that only becomes useful after I've manually categorized every transaction.

I wanted one small, timely observation that would make me look twice:
“By the 20th, you're spending 28% above your usual pace.”

That sentence became the starting point for Usually — Your Money Has Habits. Usually Knows Them.

Usually is an AI-assisted personal finance companion that works with bank and UPI statement files, looks for recurring financial patterns, compares spending against historical baselines, and helps reduce the repeated work of classifying transactions.

Its guiding principle became:

Automate the routine. Ask about the ambiguous. Remember the answer.

I wanted software that would quietly handle the repetitive work, give me evidence when something looked different, and leave decisions about my money in my hands.

The sloth is more than a decoration for the challenge theme. It represents the kind of software I wanted to build: something that doesn't demand constant attention when the routine can be handled for me.

Usually brings three connected experiences together:

Home Briefing gives me concise observations about recurring activity and financial habits.
Financial Analysis helps me understand cash flow, category patterns, transfers, and spending pace.
Verified Ledger keeps the underlying transactions available to inspect rather than hiding the evidence behind a summary.

The idea is not to generate more financial information. It is to make the information that matters easier to notice.

I also wanted the product to explain itself. When money is involved, a polished observation should never have to stand in for an explanation of where it came from.

Demo

Here's the Week 3 demonstration video.

Try the live application:

usually-tau.vercel.app

Original website walkthrough:

https://youtu.be/1R1HhzmjI7o

The public showcase uses synthetic demo data and deterministic rules. My locally configured Gemma/Ollama setup is separate from that hosted environment; the deployed demonstration should not be mistaken for proof that every screen calls a language model.

Code

The project is open source, and the implementation is available here.

debashis-sharingan-21 / usually

Your money has habits. Usually knows them.

Usually — Your Money Has Habits

A quiet, local-first personal finance companion designed with a warm, editorial notebook aesthetic Themed “Slow and Steady” with a peaceful sloth identity.

Quick Links

Live Web Application: https://usually-tau.vercel.app/
Hacktoberfest Week 3 Submission Video
Website Walkthrough
Live Cloud Backend: https://usually.onrender.com/ (Health: /health)
GitHub Repository: https://github.com/debashis-sharingan-21/usually
Architecture Documentation: docs/architecture-audit.md

The Problem and the Solution

Understanding personal finances usually forces an unwelcome tradeoff:

Tedious manual spreadsheets: High maintenance friction, requiring manual categorization of cryptic bank descriptions and repetitive bookkeeping.
Aggressive cloud aggregators: Demand bank credentials, harvest sensitive transaction logs, and push guilt-inducing notifications.
Overhyped AI financial bots: Hallucinate arithmetic totals, invent psychological spending motives (“retail therapy”), and send financial data to third-party model APIs.

Usually takes a different path: “Automate the routine, ask about the ambiguous, remember the answer.”

What Usually automates: Pure deterministic math calculates income, living expenses, transfers, refunds, and spending-pace benchmarks…

View on GitHub

How I Built It

The most important technical decision was to keep financial calculations separate from language-model interpretation.

I didn't want an AI model inventing balances, estimating totals from prose, or silently deciding how a transaction should be treated. Instead, I gave the model a narrower job and kept financial arithmetic in deterministic application code.
Before getting into the implementation, here's how the pieces fit together. The main financial workflow stays deterministic; local Gemma assists with ambiguous merchant classifications, with a human reviewing the suggestion before it is saved.

Usually end-to-end workflow showing statement import and validation, ledger storage, deterministic financial analysis, human-reviewed Gemma merchant classification, user-facing insights, and local versus hosted deployment.

1. Start with the statement

Usually accepts supported bank and UPI statement files. It normalizes transaction information, maps the available columns, checks for incomplete rows, and identifies duplicates before the transactions become part of the ledger.

I wanted the import process to be understandable rather than a black box. Before committing a file, the interface shows the mapping and gives the user a chance to inspect the parsed records.

Once the import is complete, it reports what happened.

In this example, all 200 synthetic demo transactions were accepted, with no duplicates or rejected rows. This is a demonstration dataset, not a public upload of my personal bank statement.

2. Calculate first, explain second

Cash-flow totals, category aggregates, transfer handling, and spending comparisons are calculated through ordinary application logic.

For spending pace, the important comparison is between cumulative spending so far in the current statement month and the equivalent checkpoint in historical periods. It is not a prediction of the final month-end total.

The synthetic example in this screenshot shows spending at ₹36,389 against a historical baseline of ₹30,409 by day 21 — a difference of 19.7%.

That percentage belongs to this demo view. It is separate from the 28% observation in my personal testing story below.

The principle matters more than any single number: if a financial observation says spending is ahead of the baseline, the underlying transactions and calculation should make it possible to inspect why.

3. Ask for help when a merchant is ambiguous

Some transaction descriptions are obvious. Others are vague, inconsistent, or unfamiliar.

In the local development setup, Gemma 2B runs through Ollama and can suggest a category for an ambiguous merchant. Instead of treating that suggestion as a final decision, Usually asks the user to review it.

A user can accept a suggestion, correct it, choose another category, or leave the transaction unresolved.

Once a classification is confirmed, the application saves the decision. When a matching merchant appears again, the known classification can be reused instead of asking the model to repeat the same work.

That is the learning cycle I wanted:

Unknown merchant → suggestion → human confirmation → saved decision → deterministic reuse.

The model assists with interpretation. It does not get the final say over how a transaction is categorized.

4. Make the operating mode visible

I also wanted a way to inspect the workspace configuration rather than leave it implicit.

This screenshot shows a local development configuration. The shared demo workspace and the local model setup are distinct from the public deployment; the hosted application does not run the Ollama instance on my own machine.

The screenshots in this article were captured in different workspace and demo states. In particular, the 200-row import example and the 82-row shared read-only workspace are not meant to represent the same dataset.

5. Be honest about what is verified

I don't think a finance application should claim that every AI pathway works simply because a screen displays an AI-related label.

In my latest verification run, 100 offline backend tests passed, alongside 22 frontend unit tests. I then ran the three live-Gemma end-to-end tests separately, and all three passed. Here's the evidence.

Backend verification — 100 tests passed

The offline backend suite completed with 100 passing tests, 3 deselected, and 1 deprecation warning in 301.61 seconds.

Live Gemma verification — 3 end-to-end tests passed

I also ran the integration tests with Gemma 2B through Ollama. All three passed, covering merchant classification, the confirmation-and-learning cycle, and spending-pace provenance.

So I am not treating the UI label in a screenshot as independent proof that every spending-pace explanation was produced by the model. The distinction between deterministic calculations and model-backed interpretation is something I want the tests to establish explicitly.

For an application dealing with financial information, knowing where a result came from is part of making it trustworthy.

Why Does Open Innovation Matter?

Transaction histories can reveal more than shopping habits. They can expose salary patterns, rent payments, family transfers, subscriptions, and other parts of a person's routine.

I wanted local model execution to be a real option for merchant interpretation, rather than making a remote, closed-model API a mandatory part of that feature.

In the local setup, Gemma runs through Ollama on the developer's machine. Once the model is installed, inference can run locally without sending merchant descriptions to a remote model-inference service.

That creates a few useful possibilities:

Control over inference. I can run and test the model in my own environment instead of depending on one hosted inference provider.

A narrower AI responsibility. Gemma assists with ambiguous descriptions, while deterministic code remains responsible for the financial calculations.

Human oversight. Suggestions can be reviewed, corrected, or skipped. Confirmed decisions can then be saved and reused.

This is not a blanket claim that every deployment of Usually is completely local or automatically private. Data handling depends on the workspace, storage, and deployment configuration. The public hosted demonstration uses synthetic data and deterministic rules; the local Ollama configuration is a separate development path.

Open innovation matters here because it lets developers inspect, run, adapt, and evaluate the model behind an application. A closed API could also categorize a merchant, but local inference provides a meaningful alternative when I want more control over where that interpretation happens.

I also see this as connected to a broader goal of financial well-being. The Consumer Financial Protection Bureau describes financial well-being in terms of control over day-to-day finances, resilience to financial shocks, progress toward goals, and freedom of choice.

Usually does not claim to measure or guarantee those outcomes. Its smaller goal is to make patterns in a person's own transactions easier to understand, so they have better context for their own decisions.

The Lazy Payoff

I wanted to know whether the idea was useful beyond a nice-looking interface.

When I tested Usually with my own 90-day Google Pay statement, the file took about four seconds to parse. I had around six unfamiliar payees to review, and I worked through the suggestions in under a minute.

The spending-pace comparison showed that I was 28% above my usual pace by the 20th of the month. That made me inspect the transactions more carefully. I had mentally filed a couple of birthday gifts under “fine, one-off expenses.” Looking more closely, I found a duplicate streaming-service charge I hadn't noticed.

Usually didn't make the decision for me. It helped me notice something worth investigating.

That was the payoff I wanted: less time sorting through routine activity, and more attention for the few things that deserve a closer look. The public demo uses synthetic data; my personal statement isn't part of the public demonstration.## The Slow-and-Steady Idea

The payoff isn't a claim that Usually saves a fixed number of minutes every week.

It is the repeated work the app is designed to reduce: classifying the same merchant again, manually connecting individual transactions into a pattern, or trying to understand a spending change without seeing the evidence behind it.

Usually aims to handle the routine, ask when interpretation is uncertain, and remember a choice only after it is confirmed.

That is the part of open-weight AI I wanted to explore. Not AI making every decision, but software becoming more helpful without becoming less accountable.

Prize Categories

Best Use of Gemma (featured category) — Usually uses the open-weight Gemma 2B model through Ollama to suggest categories for ambiguous merchants in the local setup. Suggestions require human review, and confirmed decisions are saved and reused deterministically.

Best Use of Render (featured category) — Usually's FastAPI backend is deployed as a Render web service. The Vercel-hosted frontend routes /api/* requests to the Render backend.

Live backend:

usually.onrender.com

Health endpoint: https://usually.onrender.com/health

Let's Discuss

What is one repetitive task in your life that you wish could quietly take care of itself?

And, when software handles the routine, which decisions would you still want to review yourself?

I'd especially appreciate feedback on the balance between local AI assistance, deterministic financial logic, and human control in an application that works with sensitive information.

Usually — Your Money Has Habits. Usually Knows Them.

Automate the routine. Ask about the ambiguous. Remember the answer.

Slow and steady. 🦥