ProvelyNo. Jira Cloud platform REST API returns a success response when it accepts the request. Provely proves added, created and in_status as separate promises.
| Fact | Value |
|---|---|
| Skill version | 0.1.0 |
| Publisher | Built and signed by Provely. |
| Certification | Provisional |
| 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-05 |
| 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 | 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 | 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 | 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 a Jira Cloud platform REST API state that no source states | 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 definition.
| Level | Contract | Promise | Evidence | Certification |
|---|---|---|---|---|
added | 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 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 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 |
Which ways can a Jira Cloud platform REST API action look done and not be?
| Contract | Case | Verdict |
|---|---|---|
| jira.comment.added | duplicate side effect | CONTRADICTED |
| jira.comment.added | pre existing state | CONTRADICTED |
| jira.comment.added | wrong subject | CONTRADICTED |
| jira.issue.created | duplicate side effect | CONTRADICTED |
| jira.issue.created | pre existing state | CONTRADICTED |
| jira.issue.created | wrong subject | CONTRADICTED |
| jira.issue.in_status | duplicate side effect | CONTRADICTED |
| jira.issue.in_status | wrong subject | CONTRADICTED |
What did the last conformance run show?
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.
| Contract | Certification |
|---|---|
jira.comment.added | Provisional |
jira.issue.created | Provisional |
jira.issue.in_status | Provisional |
The weakest contract is jira.comment.added. It 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.
| 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. 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 | docs | 2026-09-09 | authored |
| jira.docs.issues | docs | 2026-09-09 | authored |
| jira.docs.transitions | docs | 2026-09-09 | authored |
| jira.docs.versions | docs | 2026-09-09 | authored |
| jira.docs.webhooks | docs | 2026-09-09 | authored |
| jira.events | event sample | 2026-09-09 | authored |
| jira.openapi | 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
- Begin the operation.Call
beginwith the contractjira.comment.addedand the input. Keep the operation id. - Make the Jira Cloud platform REST API call you make today.Send the request with the correlation metadata that
beginreturned. - Submit the acknowledgement.Call
action_resultwith the Jira Cloud platform REST API response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime reads the evidence that the contract names, from Jira Cloud platform REST API and not from the agent, and evaluates the contract. - 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 the Jira Cloud platform REST API action is still in progress?
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.