Chad, my recollection of the following is fuzzy because it's been a year and a half since I was editor of the Star Tribune's Web site, I didn't do the data modeling or the coding for the production system, and my role was supervisory and not production-centered. Also, the system was designed in 1995.
But what I recall is that we stored in the story table a priority ranking that was prepopulated by the database loader (using rulesets that made a "best guess" based on pagination info, etc.) Since the data inherited from Atex and wire sources tended to be dirty, it was all run through a forms-based screening process before it was marked as "live." During that process, editors could fine-tune the priority rankings.
The Web editorial interface would then do the equivalent of "select * fron stories date=whatever, section=whatever, status='publish' order by priority" to generate a short list of choosable items for highlights pages.
They were presented in a Web form that allowed a finite number of major and minor stories.
We used Javascript to reorder the Web form dynamically. If you chose an item as #2, it would "push down" any preexisting 3, 4, and 5.
Major stories would get headlines + summaries. Since the database didn't necessarily have summaries for stories, the summary field would be loaded with the first couple of paragraphs if necessary. Editors could rewrite headlines and summaries while working on the page ordering.
Submitting the results would post the selections back to the database. This is important -- store your results, don't just push HTML out to the server farm -- because highlights pages might be revised half a dozen times throughout the day, and because it makes it easier to develop alternative products from the same data set.
I don't know if any of this is helpful, though, because I'm not entirely sure where you're getting stuck.
