NOTE: Demo visuals use either blurred real data or synthetic placeholders to protect customer privacy.

Everyone knows the incident is not really “over” when systems recover. The hard part starts after: Five Whys, root cause, and then the long tail of urgent and non-urgent action items that should land as real engineering work.

Ivan pointed out three common failure modes:

1. Action items are hard to write well after the fire: teams are tired, and the incident context is already fading.

2. Tickets become empty shells: Jira issues get created with little detail, leaving the next engineer guessing how to implement the fix.

3. Follow-through drifts: even when tickets exist, they are easy to forget, delaying prevention work for days or weeks.

The result is predictable: post-mortems may document what happened, but they do not consistently produce work that ships.

Post Incident Ops tackles this by generating what Ivan called “creating what we call agent-ready action items.” Instead of a high-level title and a vague note, each action item is produced with the technical depth required to execute or hand off.

At a practical level, the feature does a few things end-to-end:

• Generates action items with implementation details, incident context, success criteria, and supporting technical notes

• Outputs those action items as JSON so they can be used deterministically, not copied from a paragraph

• Creates Jira tickets from the JSON in one command, with consistent formatting and the right detail level

• Links those tickets back into the post-mortem and publishes the final page to Confluence

• Enables a downstream path into NoraPlan and NoraPR, so teams can turn an action item into a plan or a PR flow when appropriate

Ivan’s demo showed the workflow in motion: paste a raw incident context dump (bad PR, S3/blob data, Slack conversations, and related queries), generate the post-mortem Markdown, and then produce action-item JSON files that can be promoted into Jira issues. The key is that the “ticket” is no longer a placeholder. It is a runnable starting point.

The goal is not just better documentation. It is faster execution with clearer ownership. Post Incident Ops makes the post-mortem the source of truth for prevention work, with each root cause tied to a tracked, detailed action item.

Value shows up for multiple audiences:

• On-call and incident leads: less time spent translating learnings into tickets after an exhausting response

• Owning teams and future implementers: fewer ambiguous handoffs because tickets include success criteria and implementation direction

• Engineering leadership: clearer visibility into whether follow-up work is moving, since the Confluence page links directly to Jira

Ivan framed the upside in cycle-time terms: if the action items are correct, the path from “we learned something” to “we started fixing it” can compress from days or weeks to minutes by quickly spinning up the next artifacts. Next step: tighten the quality bar for action-item generation and track completion rates of linked tickets to confirm the loop is actually closing.