This is a submission for the Notion MCP Challenge
Exception OS came from a simple frustration. Teams already have enough dashboards, alerts, and summaries. What they usually do not have is a clean way to notice the few situations that actually need judgment, turn those moments into a usable brief, and preserve the final decision somewhere the team will revisit later.
The live demo is here: https://exception-os.vercel.app
The GitHub repository is here:
aniruddhaadak80
/
exception-os
Exception-first operations dashboard with live GitHub signals and real Notion MCP publishing workflows.
Exception OS
Exception OS is a deployed SaaS-style operating system for teams that need fewer dashboards and faster decisions. It ingests live operational signals, detects exceptions that require human judgment, generates structured decision briefs, and routes them into a Notion-centered workflow.
Live Demo · GitHub Repository · DEV Submission Draft
Status
Exception OS is complete as a deployable challenge app and SaaS-style product foundation.
- Production deployment is live on Vercel.
- The dashboard is responsive and verified on desktop and mobile layouts.
- Lint, tests, and production build are passing.
- Real Notion MCP OAuth, workspace sync, and Notion publishing are implemented server-side.
- Other users can use the deployed app by connecting their own Notion workspace.
- Live GitHub activity now feeds the dashboard without seeded incident templates.
The only runtime step that still depends on the user is approving Notion OAuth for a specific workspace, which cannot be done automatically on someone else’s…
What I Built
I built Exception OS, an exception first operating system for teams dealing with operational noise.
Most AI productivity tools try to summarize everything. Exception OS takes the opposite approach. It watches incoming signals, narrows attention to the smaller set of situations that actually require human judgment, and turns those moments into structured decision briefs.
This challenge build is already deployed as a public web app. Other users can open it, connect their own Notion workspace, save a publishing target, and use the live Notion workflow right away.
The app includes a live operations dashboard for signals, exceptions, and decision briefs. It pulls live GitHub activity into the system, uses a real Notion MCP integration with OAuth, PKCE, token refresh, and server side MCP calls, and lets a connected user publish decision briefs directly into Notion pages, databases, or data sources. It also syncs workspace context back from Notion search so the next decision has more useful surrounding context.
In short, Exception OS treats Notion as the operational memory and approval layer for critical decisions.
The desktop view is where the product story starts. It shows the exception queue, the active decision brief, and the live signal layer in a single operating surface.
What Is Real Today
Everything in the core workflow is live today. The app is publicly deployed on Vercel. Each user can connect their own Notion workspace through OAuth. The MCP client is real and runs server side. Workspace search is live. Publishing is live. GitHub repository activity is also live and feeds the upstream operational layer. This is not a mock front end with a pretend integration behind it.
The current limitation is connector breadth. GitHub and Notion are live today, while systems like Stripe, dedicated support tooling, and calendar platforms are still future connectors.
The mobile layout matters here because the workflow is still usable when reduced to its essentials. The same live signal, exception, and brief flow holds together on a small screen.
Video Demo
I am using production screenshots in this submission and the live deployed app for verification. The product can be reviewed directly at the deployed URL, which makes the behavior easier to judge than a prerecorded walkthrough alone.
Live demo: https://exception-os.vercel.app
How I Used Notion MCP
Notion MCP is not decorative in this project. It is the core runtime integration.
I used a real server side Notion MCP client to authenticate users with OAuth 2.0 and PKCE, discover Notion MCP OAuth metadata dynamically, connect to https://mcp.notion.com/mcp over Streamable HTTP, inspect the authenticated workspace, publish decision briefs into Notion as durable operating records, and search the workspace for contextual material that can inform the next decision.
That means the app does not just mention Notion. It actually reads from and writes to Notion through MCP.
It also means different users can connect different Notion workspaces, which makes the deployed app usable beyond my own environment.
In this view, the important part is the Notion MCP panel. That is where a user connects a workspace, saves a publish target, syncs context, and pushes the selected brief into Notion.
Why I Built It
Teams do not usually fail because they lacked dashboards. They fail because critical exceptions get buried across tools, owners, and conversations.
Exception OS is designed around a simple idea:
AI should interrupt humans only when judgment is required.
When a real exception appears, Exception OS creates a decision brief that explains what happened, why it matters now, what the likely cause is, who should own it, what actions should happen next, and what evidence supports the recommendation.
From there, the brief can be pushed into Notion, where the team can review, approve, and preserve the decision as organizational memory.
App Architecture
The app is built with Next.js App Router and React 19 on the front end, plus a server side Notion MCP client powered by @modelcontextprotocol/sdk. Session state is stored in secure encrypted cookies. The signal layer combines live GitHub activity with connected Notion workspace ingestion.
The architecture separates signal generation, decision synthesis, Notion publishing, and workspace context sync. That gives the product a real end to end loop today while keeping the path to broader connector coverage obvious.
I am using the desktop screen here as an architecture reference. The top of the interface establishes live inputs, the center focuses human attention on the current exception, and the lower sections show the normalized signal stream and system structure.
Challenges I Ran Into
The hardest part was treating Notion MCP like a real application integration rather than a prompt only connector.
That meant handling RFC 9470 protected resource discovery, RFC 8414 authorization server discovery, correct PKCE behavior, server side session and token storage, token refresh and reconnect scenarios, and a UI that still works when a workspace is not yet connected.
That extra work was worth it because it turned the project from a mock into a real integration.
The second challenge was turning the upstream feed into something real without depending on private customer infrastructure. I solved that by using live GitHub activity as a public operational signal source and live Notion workspace context as the operator memory layer.
What’s Next
The current version focuses on the decision layer and Notion MCP integration. The next step is to broaden the connector layer so the same workflow can ingest support, revenue, and calendar systems beyond GitHub and Notion. After that, I want to store exceptions in a dedicated Notion data source schema, add approval analytics and learning from human edits, and introduce first party app accounts plus shared team workspaces.
Repo
GitHub repository: https://github.com/aniruddhaadak80/exception-os
Try It
Open the live app, connect your Notion workspace, save a Notion page as the publish target, and start publishing operational decisions directly into Notion. If you want to run it locally, clone the repo, add the environment variables, and start the Next.js app.
This is the quickest way to understand the product. Open the app, connect Notion, save a target page, and the workflow is ready to use from the same screen.
Top comments (0)