This fictional operational workflow starts when a service owner reports intermittent access failures in a business application.
Pūnaha captures the observed symptoms, affected service, time window and declared impact, while reminding the operator not to add data outside the approved incident process.
The workflow enriches the report through developer-configured connections.
A generic REST step requests approved service status, and a read-only data step obtains permitted configuration context.
If either dependency is unavailable, the run continues with a visible incomplete-context flag.
Three branches now work in parallel.
One retrieves the relevant runbook, another finds related resolved incidents, and a configured model prepares a preliminary impact summary from the information available.
Pūnaha merges the branch results into one triage package.
Sources, missing evidence and conflicting signals remain visible rather than being flattened into a confident answer.
A condition evaluates the declared impact and completeness.
This representative run follows the high-risk route because a critical service is affected and part of the live context is unavailable.
The incident lead reviews the package, corrects the summary if needed and chooses the accountable handover path.
The illustrative decision is to escalate with the missing-context warning preserved.
The approved handover can continue through a configured connection to the surrounding incident service.
Pūnaha retains the workflow version, dependency state, branch results and human decision, giving the next team a clear record of how the handover was formed.