Build blueprint
Notification Interruptibility Engine
A macOS/iOS layer that decides deliver, batch, summarize-later, or suppress for every event.
- Problem
- Notification systems use crude per-app settings and interrupt at the wrong moment.
- Why Jev
- Continuous, private context requires cheap decisions per notification.
- Architecture
- Notification + focus/calendar/device state → delivery Choice and urgency Score → OS action.
- Current alternative
- Focus modes, keyword filters, or cloud LLM summaries.
- Jev advantage
- Thousands of tiny judgments can shape attention without generating content.
- Unknowns
- Platform interception limits and privacy expectations for notification content.
Why this confidence: Compelling high-frequency use case, but OS APIs may constrain the product.
This is an authored hypothesis derived from the research corpus. Nothing here demonstrates product demand, or that Jev performs well on this particular workload. Run the validation experiment before building past the MVP.
Sources
Limitations
- Platform interception limits and privacy expectations for notification content.
- This is a research hypothesis, not evidence of product demand or Jev performance in this workflow.
Supporting research
- Probabilistic predicate + deterministic action PlausibleJev supplies fuzzy predicates while TypeScript, policies, and workflows execute constrained actions.
- HA-Jev ObservedA Home Assistant custom integration exposing Jev evaluations as sensors and automation actions.
- Cheap decision calls could make tens or hundreds of semantic judgments per event economical. SpeculativeThe product design follows from published pricing and parallel question primitives, not independent production evidence.
- Parallel decision matrix PlausibleOne state is evaluated against many named questions, replacing repeated prompt/parse cycles.