Good advice, thanks. Ironically, it's how I already solved a few other parts. My first schema was much bigger and clumsier than after I took a higher view -- divorcing myself entirely of the initial target case -- to abstract the elements and write a bunch of story cards for the application. I think I dropped about five tables and several redundant, or ass-backwards foreign keys. I'm writing failing tests right now based on the story cards. Really trying to follow best XP for a change and see how the experience differs from some past projects. :)

Last night I realized I had abstracted things apart correctly except for frequency. A single "job" shouldn't own/know its frequency but that's where I had the data living. Moving it out simplifies everything; and allows for smooth higher abstractions if API guts change b/c of shoddy, I mean sub-optimal, early choices.