Last reviewed 2026-09-05Skill version 0.1.0Provisional
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.
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
Provely