jira.issue.in_status: the in

Prove that the issue sits in the status that the person authorised. A transition is not a status. Jira answers 204 with no body, and a post function can move the issue again. Only a read states the outcome.

Contract identity.
Fact	Value
Contract id	`jira.issue.in_status`
Version	`1.0.0`
Hash	`d334936da73afbc5`
Completion level	`in_status`
Publisher	Built and signed by Provely.
Certification	Provisional
Skill	Jira Cloud platform REST API 0.1.0
Valid for provider API versions	`3`

What is the intent?

Move this issue into the status that I name.

What is the subject and the action?

Member	Value
Subject type	`jira.issue_bean`
Subject identity	issue_id = `$input.issue_id`
Canonical effect	`work_tracking.issue_transition`
Provider operation	`POST /rest/api/3/issue/{issueIdOrKey}/transitions`
Idempotency	none, retry is not safe

How does the evidence correlate with this operation?

Strategy	Assurance	Keys	Required
`resource_id`	strong	issue_id from `$input.issue_id`	yes

Which evidence does the contract require?

Minimum evidence level E2. An independent channel is required. Minimum channels: 1.

Channel	Level	Independence	Verifier	Description
`transitioned_issue_readback`	E2	provider readback	`http`	Read the issue and its recent changes. A condition path is $observed.transitioned_issue_readback.fields.status.id. The 204 answer states no status. The expand option changelog puts the newest change first, and no member of an issue dates the current status.
`issue_update_events`	E3	provider event	`webhook`	The jira:issue_updated callbacks of this issue since the operation started. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A count above one shows a second change after the transition, which a workflow post function can make.

Which conditions must all hold for VERIFIED?

Condition	Meaning	Path	Operator	Expected	Evidence
`transitioned_issue_present`	The provider holds the issue that the request named.	`$observed.transitioned_issue_readback.id`	`eq`	`$input.issue_id`	`transitioned_issue_readback`
`issue_in_the_authorised_status`	The issue sits in the requested status of the requested project, and the change happened inside this operation.	—	`all_of`	The rows below state the members.	`transitioned_issue_readback`
`issue_status_matches`	The status identifier of the issue equals the requested identifier.	`$observed.transitioned_issue_readback.fields.status.id`	`eq`	`$input.target_status_id`	`transitioned_issue_readback`
`issue_status_project_matches`	The status belongs to the requested project.	`$observed.transitioned_issue_readback.fields.project.key`	`eq`	`$input.project_key`	`transitioned_issue_readback`
`issue_changed_in_window`	The newest change of the issue happened after the operation started. No member of an issue states when the current status came into being, so the changelog states the time.	`$observed.transitioned_issue_readback.changelog.histories[0].created`	`time_after`	`$operation.created_at`	`transitioned_issue_readback`
`issue_update_event`	At least one jira:issue_updated callback names this issue since the operation started.	`$observed.issue_update_events.count`	`gte`	`1`	`issue_update_events`

Which conditions give CONTRADICTED?

Condition	Class	Reason	Path	Operator	Expected
`issue_in_another_status`	wrong subject	Jira changed the issue and it did not reach the status that the person authorised. The transition answered 204 and the issue landed somewhere else. Stop and ask a person.	`$observed.transitioned_issue_readback.fields.status.id`	`ne`	`$input.target_status_id`
`transitioned_issue_in_another_project`	wrong subject	The agent transitioned an issue of a different project than the intent named.	`$observed.transitioned_issue_readback.fields.project.key`	`ne`	`$input.project_key`
`duplicate_status_change_present`	duplicate side effect	Jira changed the issue more than once since the operation started. A second change moved it after the transition. Ask a person.	`$observed.issue_update_events.count`	`gt`	`1`

Which observed states map to a verdict before completion?

The contract declares no verdict map. The completion block decides.

How long does the runtime observe?

Timing member	Value
Initial delay	1000 ms
Poll interval	5000 ms
Backoff	exponential factor 2, max 60000 ms
Maximum attempts	40
Timeout	900000 ms
Stale read window	20000 ms
On timeout	UNVERIFIABLE (`evidence_unavailable_before_timeout`), escalated to a person

Where do these rules come from?

jira.openapi#/paths/~1rest~1api~13~1issue~1{issueIdOrKey}~1transitions/post: jira.openapi, retrieved 2026-09-09
jira.openapi#/paths/~1rest~1api~13~1issue~1{issueIdOrKey}~1transitions/post/responses/204: jira.openapi, retrieved 2026-09-09
jira.docs.transitions#transitions/perform-a-transition: jira.docs.transitions, retrieved 2026-09-09
jira.docs.transitions#transitions/a-successful-transition-does-not-prove-a-status: jira.docs.transitions, retrieved 2026-09-09
jira.openapi#/components/schemas/IssueBean/properties/id: jira.openapi, retrieved 2026-09-09
jira.openapi#/paths/~1rest~1api~13~1issue~1{issueIdOrKey}/get/responses/200: jira.openapi, retrieved 2026-09-09
jira.events#/events/jira:issue_updated: jira.events, retrieved 2026-09-09
jira.docs.webhooks#webhooks/the-event-names: jira.docs.webhooks, retrieved 2026-09-09
jira.openapi#/components/schemas/Webhook/properties/events: jira.openapi, retrieved 2026-09-09

Can jira.issue.in_status return VERIFIED from the action response alone?

No. The minimum evidence level is E2. The action response is E1. The completion conditions read transitioned_issue_readback and issue_update_events.

What happens after the timeout?

The verdict is UNVERIFIABLE with the reason evidence_unavailable_before_timeout. The operation goes to a person for review.