Even if there's not necessarily a formal workflow for how to handle alert escalation, we could allow users to specify their own ack states as a simple but effective interim solution.

Some suggested acknowledgement-status states from the community: "false", "recovered", "ignore", "todo", "maintenance".  These could be configured an administrative page (whether static or driven through a server-side plugin), which then drives the options that are rendered in the list and details view for alert history.

The data model change would be minimal, as we'd only need to change the boolean acknowledged bit to a string (or int or enum) representing the current state.  The acknowledgedBy field remains the same, and represents the user that most recently modified the ackState of the alert.