# Does a Jira Cloud platform REST API success response mean the outcome happened?

> Does a Jira Cloud platform REST API success response mean the outcome happened? Certification Provisional.

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

**No. Jira Cloud platform REST API returns a success response when it accepts the request. The comment then holds one of 2 states. Provely proves `added`, `created` and `in_status` as separate promises.**

*Skill facts from the signed manifest.*

| Fact | Value |
| --- | --- |
| Skill version | `0.1.0` |
| Publisher | Built and signed by Provely. |
| Certification | Provisional (score 49 of 100) |
| Last conformance run | 2026-09-05T12:00:00Z: 41 of 41 cases passed, 0 critical false VERIFIED |
| Provider API versions | `3` |
| Default provider API version | `3` |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | `937b97ad1aff6c8f` |
| Manifest hash check | the document hashes to the value the manifest states |
| Signature | valid, key `provely-skill-2026-09`, trusted by this build |

## What does this page prove?

| Claim | Proven by | Evidence | Status |
| --- | --- | --- | --- |
| A comment that exists is not a comment on the right issue. The level reads the comment through the issue that the person named. | [jira.comment.added](/verify/jira/jira.comment.added) | E2 + E3 | proven |
| The record exists in the intended project with the intended summary and issue type. It does not prove the status. Read the level in_status for that. | [jira.issue.created](/verify/jira/jira.issue.created) | E2 + E3 | proven |
| 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. | [jira.issue.in_status](/verify/jira/jira.issue.in_status) | E2 + E3 | proven |
| An outcome outside Jira Cloud platform REST API, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
| The meaning of the `in_workflow_status` state of `jira.issue_bean` | not proven | no source states it | not proven |
| The agent report that the action worked | never counts | E0 | not proven |

## Which completion levels does the Jira Cloud platform REST API skill expose?

Each level is one promise with one contract. An agent picks the level that matches the promise it makes. It cannot upgrade a level. Read the [completion level](/glossary/completion-level) definition.

| Level | Contract | Promise | Evidence | Certification |
| --- | --- | --- | --- | --- |
| `added` | [jira.comment.added](/verify/jira/jira.comment.added) v1.0.0 | A comment that exists is not a comment on the right issue. The level reads the comment through the issue that the person named. | E2 + E3 | Provisional |
| `created` | [jira.issue.created](/verify/jira/jira.issue.created) v1.0.0 | The record exists in the intended project with the intended summary and issue type. It does not prove the status. Read the level in_status for that. | E2 + E3 | Provisional |
| `in_status` | [jira.issue.in_status](/verify/jira/jira.issue.in_status) v1.0.0 | 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. | E2 + E3 | Provisional |

## What is the Jira Cloud platform REST API lifecycle?

### Which states can a `jira.comment` be in?

| State | Class | Verdict | Meaning | Source |
| --- | --- | --- | --- | --- |
| `present` | transitional | PENDING | The comment sits on the issue. The member created states the time of the write. Jira states no further state for a comment. | [jira.docs.comments](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) |
| `edited` | transitional | PENDING | A person changed the comment. The member updated then differs from the member created. | [jira.docs.comments](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) |

### Which states can a `jira.issue_bean` be in?

| State | Class | Verdict | Meaning | Source |
| --- | --- | --- | --- | --- |
| `in_workflow_status` | unknown | UNVERIFIABLE | The issue sits in a status of the workflow of the project. The published pages enumerate no status identifier and state no meaning for one, because a project defines its own workflow. | [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) |
| `deleted` | terminal neutral | FAILED | A person or an agent deleted the issue. A read of the issue then answers 404. No member of an issue states this state. | [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) |

## How does Provely tie the evidence to this exact operation?

A matching state that already existed must not verify. Every contract names the [correlation](/glossary/correlation) keys that bind the evidence to the operation, and the [idempotency](/glossary/idempotency) key that stops a duplicate side effect.

| Strategy | Assurance | Keys | Required | Window |
| --- | --- | --- | --- | --- |
| `resource_id` | strong | comment_id from `$action.result.id` | yes | none |
| `fingerprint` | weak | issue_id from `$input.issue_id`; body_text from `$input.body_text` | no | 600000 ms |
| `resource_id` | strong | issue_id from `$action.result.id` | yes | none |
| `fingerprint` | weak | project_key from `$input.project_key`; summary from `$input.summary` | no | 600000 ms |
| `resource_id` | strong | issue_id from `$input.issue_id` | yes | none |

*Figure: The skill reads the channels below. It prefers the ones furthest from the action.*

- E0 agent assertion: never sufficient.
- E1 action response: the provider acknowledged the request.
- E2 provider readback: the runtime read the resource back.
- E3 provider event: the provider reported the change.
- E4 independent system: a system outside the action path agrees.
- E5 external outcome: the result is observable in the world.

## Which evidence channels does the skill read?

The runtime prefers the channel that is more independent from the action path. Read the [evidence level](/glossary/evidence-level) definition. An [acknowledgement](/glossary/acknowledgement) from Jira Cloud platform REST API is E1 and never terminal success.

| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
| --- | --- | --- | --- | --- | --- |
| `comment_creation_events_on_issue` | E3 | provider event | `webhook` | no | 5000 ms |
| `comment_readback` | E2 | provider readback | `http` | yes | 400 ms |
| `issue_action_response` | E1 | same response | `action_result` | yes | not stated |
| `issue_creation_events` | E3 | provider event | `webhook` | no | 5000 ms |
| `issue_creation_events_in_project` | E3 | provider event | `webhook` | no | 5000 ms |
| `issue_readback` | E2 | provider readback | `http` | yes | 400 ms |
| `transitioned_issue_readback` | E2 | provider readback | `http` | yes | 400 ms |
| `issue_update_events` | E3 | provider event | `webhook` | no | 5000 ms |

## Which ways can a Jira Cloud platform REST API action look done and not be?

| Contract | Case | Rule | Verdict |
| --- | --- | --- | --- |
| [jira.comment.added](/verify/jira/jira.comment.added) | wrong subject | The comment carries a different text than the intent stated. | CONTRADICTED |
| [jira.comment.added](/verify/jira/jira.comment.added) | pre existing state | The comment is older than the operation. It proves nothing. | CONTRADICTED |
| [jira.comment.added](/verify/jira/jira.comment.added) | duplicate side effect | Jira wrote more than one comment on the issue since the operation started. Do not retry. | CONTRADICTED |
| [jira.issue.created](/verify/jira/jira.issue.created) | wrong subject | The issue sits in a different project than the intent named. | CONTRADICTED |
| [jira.issue.created](/verify/jira/jira.issue.created) | wrong subject | The issue carries a different summary than the intent named. | CONTRADICTED |
| [jira.issue.created](/verify/jira/jira.issue.created) | wrong subject | The issue carries a different issue type than the intent named. | CONTRADICTED |
| [jira.issue.created](/verify/jira/jira.issue.created) | pre existing state | The issue is older than the operation. It proves nothing. | CONTRADICTED |
| [jira.issue.created](/verify/jira/jira.issue.created) | duplicate side effect | Jira created more than one issue in the project since the operation started. Do not retry. | CONTRADICTED |
| [jira.issue.in_status](/verify/jira/jira.issue.in_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. | CONTRADICTED |
| [jira.issue.in_status](/verify/jira/jira.issue.in_status) | wrong subject | The agent transitioned an issue of a different project than the intent named. | CONTRADICTED |
| [jira.issue.in_status](/verify/jira/jira.issue.in_status) | 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. | CONTRADICTED |

## What did the last conformance run show?

*The six confidence dimensions of the signed manifest.*

| Dimension | Score | Maximum |
| --- | --- | --- |
| Documentation | 14 | 20 |
| Schema alignment | 11.67 | 15 |
| Lifecycle certainty | 15 | 20 |
| Evidence strength | 16 | 20 |
| Causal correlation | 15 | 15 |
| Sandbox conformance | 10 | 10 |
| Raw score | 81.67 | 100 |
| Score after the caps | 49 | 100 |

The raw score is 81.67. 3 hard caps apply, so the score is 49 and the level is Provisional.

*Why the score is capped.*

| Reason | Highest score it allows |
| --- | --- |
| A lifecycle state has unknown semantics. The compiler cannot prove the end state. | 49 |
| 21 uncertainty records are open. The lowest cap is 49. | 49 |
| 4 mandatory cases are missing. Example: jira.comment.added:terminal_failure. | 74 |

*The score and the level of each contract.*

| Contract | Raw score | Score after the caps | Certification |
| --- | --- | --- | --- |
| `jira.comment.added` | 86.25 | 49 | Provisional |
| `jira.issue.created` | 77.27 | 49 | Provisional |
| `jira.issue.in_status` | 76.25 | 49 | Provisional |

> The weakest contract is jira.comment.added. It scores 49 and reaches Provisional. The package level is Provisional, because a package level never rises above its weakest contract. Read the level of the contract you use.

The last conformance run on 2026-09-05T12:00:00Z passed 41 of 41 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill.

*The conformance result by case class.*

| Case class | Passed | Total |
| --- | --- | --- |
| duplicate side effect | 2 | 2 |
| error after execution | 3 | 3 |
| error before execution | 3 | 3 |
| evidence unavailable | 3 | 3 |
| pre existing state | 3 | 3 |
| stale readback | 3 | 3 |
| still transitional | 3 | 3 |
| terminal success | 4 | 4 |
| timeout after commit | 3 | 3 |
| version mismatch | 3 | 3 |
| webhook duplicate | 3 | 3 |
| webhook out of order | 3 | 3 |
| wrong subject | 4 | 4 |
| wrong terminal state | 1 | 1 |

The conformance artifact digest is `e33a28b3cd53ea6c`. The harness signs the run, so a reader can check that these numbers come from that run.

## What remains uncertain?

> The level is Provisional because of it. A lifecycle state has unknown semantics. The compiler cannot prove the end state. 21 uncertainty records are open. The lowest cap is 49. Provely does not guess a rule that a source does not state.

## Where do these facts come from?

Every claim above cites a source assertion in the skill provenance. The compiler records the source, its hash, and the retrieval date. A page never states a provider rule without one.

| Source | Kind | Retrieved | Excerpt |
| --- | --- | --- | --- |
| [jira.docs.comments](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/) | docs | 2026-09-09 | authored |
| [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) | docs | 2026-09-09 | authored |
| [jira.docs.transitions](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/) | docs | 2026-09-09 | authored |
| [jira.docs.versions](https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/) | docs | 2026-09-09 | authored |
| [jira.docs.webhooks](https://developer.atlassian.com/cloud/jira/platform/webhooks/) | docs | 2026-09-09 | authored |
| [jira.events](https://developer.atlassian.com/cloud/jira/platform/webhooks/) | event sample | 2026-09-09 | authored |
| [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json) | openapi | 2026-09-09 | trimmed |

## How do I verify a Jira Cloud platform REST API action?

### Verify a Jira Cloud platform REST API action with Provely

1. **Begin the operation.** Call `begin` with the contract `jira.comment.added` and the input. Keep the operation id.
2. **Make the Jira Cloud platform REST API call you make today.** Send the request with the correlation metadata that `begin` returned.
3. **Submit the acknowledgement.** Call `action_result` with the Jira Cloud platform REST API response. This is evidence level E1. It is not completion.
4. **Verify.** Call `verify`. The runtime reads `comment_creation_events_on_issue`, `comment_readback`, `issue_action_response`, `issue_creation_events`, `issue_creation_events_in_project`, `issue_readback`, `transitioned_issue_readback` and `issue_update_events` and evaluates the contract.
5. **Report the verdict exactly as returned.** VERIFIED comes with a signed receipt. PENDING comes with the operation id. CONTRADICTED and UNVERIFIABLE are not success.

## Questions developers ask

### Does the `added` level prove the `in_status` level?

No. A comment that exists is not a comment on the right issue. The level reads the comment through the issue that the person named. 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. Use `jira.issue.in_status` to prove `in_status`.

### What does the agent say while Jira Cloud platform REST API reports `present` and `edited`?

It says: "The action is accepted but not yet verified. Operation: <id>." The verdict is PENDING. The runtime observes again on the contract timing policy.

### Which Jira Cloud platform REST API API versions does the skill support?

`3`. An operation on another version returns UNVERIFIABLE with the reason `version_unsupported`. The runtime never guesses.

### Does Provely need write access to Jira Cloud platform REST API?

No. The agent keeps its write key. The verifier reads with a separate read-only credential where Jira Cloud platform REST API permits it, and it never shares that credential with the agent.

## Read next

- [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 the jira.issue.in_status contract](https://provely.sh/verify/jira/jira.issue.in_status)
- [Read the Anthropic Claude API verification page](https://provely.sh/verify/anthropic)
- [Read the GitHub REST API verification page](https://provely.sh/verify/github)
- [See every integration](https://provely.sh/verify)
- [Verify Jira Cloud platform REST API actions from Claude Code](https://provely.sh/agents/claude-code)
- [Verify Jira Cloud platform REST API actions from Cursor](https://provely.sh/agents/cursor)
- [See every agent integration](https://provely.sh/agents)
- [Open the quick start](https://provely.sh/docs/quick-start)
- [Read how Provely records integration uptime](https://provely.sh/docs/uptime)
- [Read the completion level definition](https://provely.sh/glossary/completion-level)