Inspiration
AI, technology, business, and education news move too quickly for ambitious builders to follow properly.
Most feeds optimise for volume and engagement. They show users more information, but they do not help answer the more important questions:
- What actually matters to me?
- Why does it matter?
- What should I do next?
I built SignalOS to solve that problem for myself.
SignalOS is a personal intelligence operating system that turns a noisy stream of articles into four ranked, actionable signals aligned with my goals as a student-builder working on AI, software engineering, local models, data science, and education technology.
What it does
SignalOS collects articles from trusted RSS sources across AI, software engineering, business, education, and technology.
It then:
- normalises and deduplicates the incoming articles
- filters stale or previously seen content
- balances candidates across different sources
- limits the ranking input to control API cost
- uses GPT-5.6 to rank the most strategically useful articles
- selects four final daily signals
- explains why each signal matters
- provides a concrete action takeaway
- delivers the briefing through Discord
- displays the latest intelligence in a FastAPI dashboard
- generates a weekly intelligence summary
- stores article feedback for future ranking improvements
The goal is not to summarise everything. The goal is to decide what deserves attention and turn information into action.
How I built it
SignalOS is built primarily with Python.
The daily pipeline uses RSS feeds as its information source. Articles are converted into typed Python data models, filtered locally, deduplicated through URL and title normalisation, and reduced through a source-balanced candidate budget.
GPT-5.6 then receives a compact article representation and returns ranked article indexes, scores, reasons, and action takeaways. SignalOS maps those indexes back to the original articles, which prevents the model from inventing article titles, URLs, sources, or publication details.
The final four signals are:
- written into local state
- delivered through a Discord webhook
- displayed in a FastAPI dashboard
- included in the article history used by the weekly intelligence process
The dashboard uses server-rendered HTML and CSS with small vanilla JavaScript enhancements. Feedback forms still work without JavaScript, but JavaScript allows ratings to save instantly without reloading the full page.
Local JSON state is protected through atomic writes, file locking, backups, and corruption detection.
GitHub Actions runs the daily and weekly pipelines on a schedule, with concurrency and timeout controls to reduce accidental duplicate runs and API spend.
How GPT-5.6 is used
GPT-5.6 is used as the strategic ranking layer.
It does not fetch articles or control the source data. Instead, it evaluates a locally filtered set of candidates and determines:
- relevance to the user profile
- information quality
- strategic importance
- why the article matters
- the most useful next action
The system retains control of the original article metadata and only accepts ranked indexes and analysis from the model.
This separation reduces hallucination risk and keeps the model focused on judgement rather than data reconstruction.
How Codex was used
Codex was used throughout the development process as an engineering collaborator.
It helped with:
- implementing the FastAPI dashboard
- adding progressive-enhancement JavaScript
- building weekly intelligence rendering
- creating feedback persistence
- performing a repository-wide security and reliability audit
- identifying a model-configuration loading bug
- reducing ranking input cost
- hardening GitHub Actions
- sanitising delivery errors
- implementing atomic and locked JSON storage
- reviewing edge cases and validating syntax
I did not treat Codex output as automatically correct. I constrained its file access, reviewed diffs, tested behaviour locally, checked Git status, and committed each stable improvement separately.
Challenges
Controlling hallucination
An early design risk was allowing the model to return complete article objects. That could lead to invented titles, links, sources, or dates.
I solved this by sending indexed source articles and requiring the model to return only article indexes plus analysis. Python then reconstructs the ranked output from the original trusted article objects.
Controlling API cost
A first run could collect more than one hundred articles. Sending all of them to the ranking model would waste tokens.
I added:
- local filtering
- URL and title deduplication
- source-balanced preselection
- a global candidate cap
- shorter summaries
- compact serialisation
- configurable cheaper models
- scheduled workflow guardrails
Reliable local state
The project originally rewrote JSON files directly. A crash during writing could corrupt the application state.
I added a shared state-storage layer using:
- temporary files in the same directory
- file flushing and
fsync - atomic replacement
- file locks
- backups
- corruption detection
Making the dashboard feel responsive
The original feedback flow reloaded the entire page.
I added vanilla JavaScript using FormData, fetch, DOM updates, and fallback form submission. The interface now updates instantly while preserving non-JavaScript behaviour.
What I learned
This project taught me that building an AI product is not mainly about calling a model.
The difficult parts are:
- choosing what work belongs to the model
- controlling cost
- preserving trusted source data
- designing failure handling
- managing state safely
- making the interface feel coherent
- being honest about what the system currently does
I also learned how powerful AI-assisted development becomes when the human remains responsible for architecture, testing, security boundaries, and product direction.
Build Week development
SignalOS existed before Build Week as an early command-line and Discord intelligence prototype.
During OpenAI Build Week, it was meaningfully extended with:
- a FastAPI intelligence dashboard
- weekly intelligence reports
- persistent article feedback
- progressive-enhancement JavaScript
- source-balanced candidate preselection
- model token and cost controls
- configurable model selection
- GitHub Actions concurrency safeguards
- sanitised delivery failures
- atomic and locked JSON state storage
- repository-wide security and reliability auditing
The Git history and Codex development sessions document these additions.
What's next
The next stage is to turn feedback into a transparent preference layer.
Planned improvements include:
- editable and undoable feedback
- loved, useful, irrelevant, and saved actions
- article history navigation
- search and filters
- a saved build-ideas board
- feedback-informed ranking
- a public multi-user version with authentication and database-backed storage
SignalOS is designed to move from information overload to focused action: four signals, every day, with a clear reason to care and a clear next step.
Log in or sign up for Devpost to join the conversation.