# What does jira.issue.in_status prove?

> Prove that the issue sits in the status that the person authorised. Version 1.0.0, certification Provisional.

Canonical: https://provely.sh/verify/jira/jira.issue.in_status  
Last reviewed: 2026-09-05  
Skill version: 0.1.0  
Certification: provisional  

**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](/verify/jira) |
| 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](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.openapi#/paths/~1rest~1api~13~1issue~1{issueIdOrKey}~1transitions/post/responses/204`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.docs.transitions#transitions/perform-a-transition`: [jira.docs.transitions](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/), retrieved 2026-09-09
- `jira.docs.transitions#transitions/a-successful-transition-does-not-prove-a-status`: [jira.docs.transitions](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/), retrieved 2026-09-09
- `jira.openapi#/components/schemas/IssueBean/properties/id`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.openapi#/paths/~1rest~1api~13~1issue~1{issueIdOrKey}/get/responses/200`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.events#/events/jira:issue_updated`: [jira.events](https://developer.atlassian.com/cloud/jira/platform/webhooks/), retrieved 2026-09-09
- `jira.docs.webhooks#webhooks/the-event-names`: [jira.docs.webhooks](https://developer.atlassian.com/cloud/jira/platform/webhooks/), retrieved 2026-09-09
- `jira.openapi#/components/schemas/Webhook/properties/events`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), 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.

## Read next

- [Read the Jira Cloud platform REST API verification page](https://provely.sh/verify/jira)
- [Read the jira.comment.added contract](https://provely.sh/verify/jira/jira.comment.added)
- [Read the jira.issue.created contract](https://provely.sh/verify/jira/jira.issue.created)
- [Read what a completion contract contains](https://provely.sh/contracts)
- [Read what a receipt proves](https://provely.sh/docs/receipts)