That question shaped the second step of Phase 0.

What I Looked At

My research fell into three groups.

Open Source and Community Platforms

I examined tools like Wazuh, Security Onion and the ELK stack.
Each had strengths, but each also had gaps. Some were powerful but heavy. Some flexible but incomplete. Some were simple but lacked depth.
Still, every one of them contributed something to my understanding.

Enterprise Ecosystems and Real Operations

A major part of my learning came from my time at ATOS, where I worked around their internal SIEM ecosystem. I will not describe anything about the platform itself, but the environment around it taught me a lot.

I worked with architecture teams, implementation teams, SOC analysts, threat hunters, production support, big data teams, log onboarding specialists and UI and UX groups.
Seeing how these teams interact in real incidents gave me a strong picture of what enterprise scale looks like and what a SIEM must handle every day.

It showed me that a SIEM is not a single tool. It is a living ecosystem that touches almost everything.

Industry Standards and Frameworks

I also studied frameworks like OCSF, MITRE ATT&CK and more.
They helped me understand what a modern security platform should align with in terms of structure, events and behavior.

What Existing Tools Do Well

Despite their problems, there are many things SIEMs get right.

Parsing and Normalization

Most mature tools handle logs from many different sources with impressive consistency.

Data Handling at Scale

Enterprise SIEMs are designed to handle huge data volumes while keeping correlation and indexing reliable.

Interfaces and Dashboards

Years of iteration and feedback cycles have given these tools polished dashboards, search views and timelines.

Governance and Compliance

Audit views, long term storage, access control and reporting are usually solid and reliable.

These strengths formed the baseline of what Jupiter should eventually grow into.

Where They Struggle

Even with their strengths, SIEMs share a number of common challenges.

Cost

Most SIEM platforms are extremely expensive. Even the open source ones become costly once data volume grows.

Vendor Dependence

Many tools tie you into a specific cloud or ecosystem. Flexibility becomes limited.

Complexity

Running a SIEM often requires several teams. Tuning rules, managing infrastructure, keeping ingestion healthy and handling noise all require constant work.

AI That Does Not Truly Help

Many tools advertise AI features, but most of them do not fundamentally improve triage or analysis. They act more like separate tools, not integrated intelligence.

Limited Self-Hosted Options

There are very few tools that can be installed and used fully on a local machine or home lab. Most require cloud infrastructure or heavy dependencies.

These gaps became the reasons Jupiter should exist at all.

What This Research Taught Me

Looking at all these tools helped me identify the principles that guide Jupiter.

It should run anywhere

Laptop, old hardware, enterprise server, cloud VM or anything in between. The tool should adapt to the environment.

It should be modular

Users should enable or disable components according to their needs. Not everyone requires everything.

OCSF from day one

One schema for all data makes everything more understandable and more future proof.

AI should be integrated correctly

AI should help interpret events, not become another noisy feature.
Local inference when possible, API fallback when needed.

It should be friendly to solo developers and small teams

People should be able to experiment without requiring a dedicated engineering team.

These ideas now act as the foundation for Jupiter’s architecture.

Personal Reflections

What surprised me

Most SIEM tools are far more similar internally than they appear from the outside. The differences tend to be polish, performance and scale, not the underlying logic.

What changed my mind

I initially believed that removing features made a system simpler. I later realized that clarity is what makes a system simple.
Users need to understand why the system produces an alert or a view, not just what it shows.

What Comes Next

The next article in Phase 0 will explore Jupiter’s architecture itself. It will focus on how all these lessons shaped the first structural decisions and why each component exists.

Every complex system starts with a question, not a commit.

Why This Phase Exists

Phase 0 of Project Jupiter is where everything slowed down on purpose.
Before writing production code, I wanted to understand how far a single person could go in building a self-hosted, AI-assisted security and monitoring platform one that could run anywhere, without depending on a single cloud, vendor, or budget.

This phase is less about configuration and more about philosophy, research, and structure.
It’s where ideas harden into architecture.

What I Set Out to Learn

When I began blueprinting, I had a few key questions written in my notebook:

• Could one developer realistically design a vendor-neutral, OCSF-native SIEM?

• How can AI actually reduce noise instead of creating more of it?

• How do you stay flexible enough to work on-prem, in the cloud, or in a hybrid mesh without building parallel systems?

These questions became my compass.

Lessons from the Field

My background helped frame these questions.
Having worked in product support and later as a threat hunter, I saw both ends of the spectrum from the chaos of customer logs to the calm dashboards of analysts.
I learned that every SIEM pipeline eventually wrestles with the same three beasts: data volume, normalization, and fatigue.

The First Conviction

Very early, I made a decision that still defines the project:

Jupiter must run anywhere.

It shouldn’t matter whether it’s a GPU workstation, a cloud VM, or an old laptop in someone’s lab.
This principle shaped every later choice from storage (DuckDB) to orchestration (NiFi) to how AI inference could fall back to API calls when GPU resources aren’t available.

The Early Architecture

At this stage, the design looked simple on paper but ambitious in intent.

This was the first time I saw how all parts might speak the same language, data flowing in OCSF format, AI models helping to summarize and correlate, and dashboards surfacing clarity instead of chaos.

Since this is still in active planning and development, services and technologies might change.

What Changed My Mind

Originally, I believed I could keep everything local, run the AI fully on-prem.
That lasted until I tried inference without a GPU.
Now, Jupiter supports both: local inference for those with hardware, and API-based fallback for community setups.
Scalability starts with empathy for different users.

What’s Next

Phase 0 continues with documenting the research behind this blueprint, exploring how existing SIEM tools work, what they miss, and why Jupiter’s hybrid model matters.

The next article:
“Mapping the Landscape - What Existing SIEMs Teach (and Miss)”

Stay tuned, and if you’ve built or broken your own SIEM before, I’d love to hear what you learned.

I named this project Jupiter for two reasons:

• Just like the planet Jupiter, which is massive and protective in our solar system, I want this platform to act as a shield — absorbing threats before they can do damage.

• The name also reflects scale. A platform that starts small in my hands but has the potential to grow into something vast, resilient, and future-ready.

The Spark

Most cybersecurity tools today live at two extremes:

• Enterprise platforms — powerful but noisy, expensive, and often locked to a single vendor.

• Open-source tools — flexible but fragmented, difficult to set up, and not always future-proof.

I wanted to explore whether one person, with consumer-grade hardware, could build something different:
a self-hosted, privacy-first, AI-assisted security and monitoring platform.

The Vision

Project Jupiter is designed to be:

• Learning-first → a journey of exploration and improvement.

• Privacy-first → all data remains under user control.

• Environment-agnostic → deployable on a laptop, server, cloud, or hybrid setup.

• AI-assisted → using machine learning to reduce noise, spot anomalies, and accelerate response.

• Future-proof → aligned with open standards like OCSF (Open Cybersecurity Schema Framework).

The Problems I’m Tackling

• Alert fatigue → endless false positives overwhelm analysts.

• Vendor lock-in → once you commit, it’s hard to leave.

• Scaling costs → every log line becomes a billing problem.

• Fragmentation → IT, OT, and physical security data live in silos.

The Roadmap

The build is split into clear phases:

1. Foundation → define scope, principles, and risks.

2. Core Infrastructure → flows, caching, and observability.

3. Ingestion & Normalization → parse events, map to OCSF, store efficiently.

4. Intelligence & Automation → threat intelligence, AI summaries, automated playbooks.

5. UX & Dashboards → tenant dashboards, reporting, chatbot copilot.

6. Ops & Recovery → backups, restore drills, resilience testing.

Why Share This?

Because cybersecurity shouldn’t be a black box.
By sharing Project Jupiter openly, I hope to:

• Inspire students and hobbyists who want to learn hands-on security.

• Explore how AI can make monitoring smarter and less noisy.

• Show that meaningful tools don’t always need enterprise budgets.

What’s Next

This is just the prologue.
In the next article, I’ll dive into Phase 0: the blueprinting stage — the research, risks, and first design choices.

Follow along here on Hashnode as I document the journey 🚀