# What does jira.issue.created prove?

> Prove that Jira holds an issue record for this request. Version 1.0.0, certification Provisional.

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

**Prove that Jira holds an issue record for this request. 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.**

*Contract identity.*

| Fact | Value |
| --- | --- |
| Contract id | `jira.issue.created` |
| Version | `1.0.0` |
| Hash | `fb9d65ecb5f8d30b` |
| Completion level | `created` |
| 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?

Create an issue in this project.

## What is the subject and the action?

| Member | Value |
| --- | --- |
| Subject type | `jira.issue_bean` |
| Subject identity | issue_id = `$action.result.id` |
| Canonical effect | `work_tracking.issue_create` |
| Provider operation | `POST /rest/api/3/issue` |
| Idempotency | none, retry is not safe |

## How does the evidence correlate with this operation?

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

## Which evidence does the contract require?

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

| Channel | Level | Independence | Verifier | Description |
| --- | --- | --- | --- | --- |
| `issue_readback` | E2 | provider readback | `http` | Read the issue that the create call named. A condition path is $observed.issue_readback.fields.summary. The published description states the member fields as an untyped map, so the shape of fields.status comes from StatusDetails and from prose. |
| `issue_creation_events` | E3 | provider event | `webhook` | The jira:issue_created callbacks of this issue. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A condition reads $observed.issue_creation_events.count. |
| `issue_creation_events_in_project` | E3 | provider event | `webhook` | The jira:issue_created callbacks of the project since the operation started. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A count above one shows a second issue, and Jira states no idempotency key to stop it. |

## Which conditions must all hold for VERIFIED?

| Condition | Meaning | Path | Operator | Expected | Evidence |
| --- | --- | --- | --- | --- | --- |
| `issue_present` | The provider holds the issue with the identifier of the answer. | `$observed.issue_readback.id` | `eq` | `$action.result.id` | `issue_readback` |
| `issue_summary_matches` | The summary of the issue equals the requested summary. | `$observed.issue_readback.fields.summary` | `eq` | `$input.summary` | `issue_readback` |
| `issue_project_matches` | The project of the issue equals the requested project. | `$observed.issue_readback.fields.project.key` | `eq` | `$input.project_key` | `issue_readback` |
| `issue_type_matches` | The issue type of the issue equals the requested issue type. | `$observed.issue_readback.fields.issuetype.id` | `eq` | `$input.issuetype_id` | `issue_readback` |
| `issue_created_in_window` | The provider created the issue after the operation started. | `$observed.issue_readback.fields.created` | `time_after` | `$operation.created_at` | `issue_readback` |
| `issue_creation_event` | At least one jira:issue_created callback names this issue. The duplicate guard reads the project channel, so a site with no webhook cannot verify and cannot miss a second issue either. | `$observed.issue_creation_events.count` | `gte` | `1` | `issue_creation_events` |

## Which conditions give CONTRADICTED?

| Condition | Class | Reason | Path | Operator | Expected |
| --- | --- | --- | --- | --- | --- |
| `issue_in_another_project` | wrong subject | The issue sits in a different project than the intent named. | `$observed.issue_readback.fields.project.key` | `ne` | `$input.project_key` |
| `issue_with_another_summary` | wrong subject | The issue carries a different summary than the intent named. | `$observed.issue_readback.fields.summary` | `ne` | `$input.summary` |
| `issue_of_another_type` | wrong subject | The issue carries a different issue type than the intent named. | `$observed.issue_readback.fields.issuetype.id` | `ne` | `$input.issuetype_id` |
| `issue_predates_operation` | pre existing state | The issue is older than the operation. It proves nothing. | `$observed.issue_readback.fields.created` | `time_before` | `$operation.created_at` |
| `duplicate_issue_present` | duplicate side effect | Jira created more than one issue in the project since the operation started. Do not retry. | `$observed.issue_creation_events_in_project.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/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/post/responses/201`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.docs.issues#issues/create-an-issue`: [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/), retrieved 2026-09-09
- `jira.docs.issues#issues/the-states-of-an-issue`: [jira.docs.issues](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#/components/schemas/CreatedIssue/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.openapi#/components/schemas/IssueBean/properties/fields`: [jira.openapi](https://developer.atlassian.com/cloud/jira/platform/swagger-v3.v3.json), retrieved 2026-09-09
- `jira.docs.issues#issues/a-status-belongs-to-a-project`: [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/), retrieved 2026-09-09
- `jira.docs.issues#issues/the-time-members-of-an-issue`: [jira.docs.issues](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/), retrieved 2026-09-09
- `jira.events#/events/jira:issue_created`: [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.created return VERIFIED from the action response alone?

No. The minimum evidence level is E2. The action response is E1. The completion conditions read `issue_readback` and `issue_creation_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.in_status contract](https://provely.sh/verify/jira/jira.issue.in_status)
- [Read what a completion contract contains](https://provely.sh/contracts)
- [Read what a receipt proves](https://provely.sh/docs/receipts)