Formatted for 1-inch screen: Part of NewEco (large-screen format)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
General idea:

Suppose there are lots of events that may happen, at times you can't predict, but you want to be notified immediately when something important happens, but if there's a flood of events in a short time-frame you don't want your e-mail or instant-message or Twitter account to be flooded with one message per event. Instead you want events bundled, so that you get a message only when a new event happens that is more important than anything you already know about. When you have time to see details of such new events, you click on one link to take you to one Web page that shows all the events neatly organized by priority and topic/category.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ideas for usage:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Comparison with RSS feeds:
An RSS feed is a poll/pull system. As a subscriber to an RSS feed, you need to run your own software to repeatedly poll every RSS feed that you subscribe to, or poll a RSS aggregation service. Then if the RSS feed shows new last-change date/time, your software needs to download the entire XML file and compare the new version with your previously-downloaded version to see which items are new, or download a list of changes and apply those changes to your local copy. The main problem is that if you want to be notified within a few seconds when something changes, you'll need to poll the remote site(s) every few seconds, which can get quite expensive. Maybe you get a text message every time a RSS update occurs, but then you are likely to be totally flooded with text messages, with no way to tell which are most urgent, resulting in total confusion, never mind the cost of so many text messages.
This Event-Priority-Alert notification system (TinyURL.Com/PriAlSy) is a push system, whereby your local system has a Web server application that accepts connections from any remote process that wishes to notify you of a new status change. The remote system pushes notifications at your receiver, rather than your having to pull status-lists from a remote system.
These two designs can be combined, for example: You subscribe to fifty RSS feeds, all mirrored on a single host, indirectly through a remote RSS-concentration service which is also located on that same host, making it efficient for the RSS-concentration service to poll all those different RSS feeds on a regular basis (once every second or two perhaps) to immediately detect when one of them has changed. A database table on the RSS-concentration service maps which individual RSS feeds are subscribed each user. When a change is detected in any individual RSS feed, the RSS-concentration service updates the merged-RSS-feed for each user subscribed to it, and then sends an event notification to the PriAlSy receiver for each such user. Each such single-subscriber PriAlSy receiver calls back to the RSS-concentration service, telling it the timestamp when the subscriber's personal copy of his merged RSS feed was last updated, and the RSS-concentration service sends the list of changes and a new timestamp. The subscriber's system then edits the local copy to include the new changes, and replaces the local last-updated timestamp. If you would get text messages to alert you of new RSS updates, with this alert system you get just one text message whenever the priority level increases, not for EVERY RSS update regardless of importance.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
How additional components would help:
How a Reverse Tree would help.
How a Truth Futures market would help.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
How reverse-tree would help:

Instead of requiring the end-user to manually set up some set of keywords for filtering incoming alerts, we use crowd-sourcing to either assign priorities manually, or set up keywords for automatic filtering but then use manual crowd-sourced labor to fine-tune the automatic filtering. Filtering is done multi-pass via a reverse tree, with the least skilled people having the burden of first-tier filtering and then more and more skilled people doing later stages of filtering. If early filtering is good most of the time, then later stages simply "rubber stamp" the earlier results most of the time, making corrections only when earlier stages made mistakes.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
How a truth-futures market would help:

If we are using a reverse tree to crowdsource filtering incoming alerts, we use the truth-futures market to reward people who are correct at predicting which topics/items the recipient actually wants to receive and which not, and to penalize those who predict wrongly. Instead of having referrees directly accept or reject individual alerts, the current market value or a particular alert determines its priority in the queue for that recipient. The first referee sets the initial price range (which maps to priority-level for the recipient), then other referees who disagree with that initial pricing have te option to buy at the asked price and ask a new higher price, or sell-short at the offered price and offer the future at a new lower price, thus raising or lowering its market price (priority-level for the recipient) respectively. Since more skilled referrees are later in the reverse tree, those more-skilled referrees can profit whenever earlier less-skilled referrees make mistakes.

.
.
.
.
.
.
.
.
.
.
.
.
.
.