# What does linear.issue.assigned prove?

> Prove that the issue is assigned to the user that the person named. Version 1.0.0, certification Provisional.

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

**Prove that the issue is assigned to the user that the person named. The issue carries the intended user as its assignee. It does not prove that the user did the work.**

*Contract identity.*

| Fact | Value |
| --- | --- |
| Contract id | `linear.issue.assigned` |
| Version | `1.0.0` |
| Hash | `d35d1265e2f4b2ee` |
| Completion level | `assigned` |
| Publisher | Built and signed by Provely. |
| Certification | Provisional |
| Skill | [Linear GraphQL API 0.1.0](/verify/linear) |
| Valid for provider API versions | `fp_2026_09` |

## What is the intent?

Assign the issue to this user.

## What is the subject and the action?

| Member | Value |
| --- | --- |
| Subject type | `linear.issue` |
| Subject identity | issue_id = `$action.result.issueCreate.issue.id` |
| Canonical effect | `work.issue_create` |
| Provider operation | `mutation issueCreate` |
| 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.issueCreate.issue.id` | yes |
| `fingerprint` | weak | team_id from `$input.team_id`; title from `$input.title` | 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 with its team, its workflow state, and its assignee. The http verifier returns the parsed GraphQL body. A path starts with $observed.<channel>.data, and $observed.<channel>.errors states a refusal. |
| `issue_assignee_events` | E3 | provider event | `webhook` | The Issue.update events of this issue that carry the user identifier of the intent as the assignee. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. |
| `issue_created_events` | E3 | provider event | `webhook` | The Issue.create events for the intended title since the operation started. The webhook verifier returns {events, count, latest, earliest, types, duplicates_dropped}. A count above one shows a second issue, and the API has no idempotency key to stop it. |

## Which conditions must all hold for VERIFIED?

| Condition | Meaning | Path | Operator | Expected | Evidence |
| --- | --- | --- | --- | --- | --- |
| `issue_readback_carries_no_errors` | The answer carries no errors array. Linear answers the status code 200 for an operation that succeeded in part, so the status code states nothing. | `$observed.issue_readback.errors` | `absent` | `undefined` | `issue_readback` |
| `issue_present` | The provider holds the issue with the returned identifier. | `$observed.issue_readback.data.issue.id` | `eq` | `$action.result.issueCreate.issue.id` | `issue_readback` |
| `issue_team_matches` | The issue belongs to the team that the intent named. | `$observed.issue_readback.data.issue.team.id` | `eq` | `$input.team_id` | `issue_readback` |
| `issue_created_in_window` | The provider created the issue after the operation started. | `$observed.issue_readback.data.issue.createdAt` | `time_after` | `$operation.created_at` | `issue_readback` |
| `issue_assignee_matches` | The assignee of the issue is the user that the intent named. | `$observed.issue_readback.data.issue.assignee.id` | `eq` | `$input.assignee_id` | `issue_readback` |
| `issue_assignee_event` | At least one Issue.update event of this issue carries the user identifier of the intent as the assignee. | `$observed.issue_assignee_events.count` | `gte` | `1` | `issue_assignee_events` |

## Which conditions give CONTRADICTED?

| Condition | Class | Reason | Path | Operator | Expected |
| --- | --- | --- | --- | --- | --- |
| `issue_on_wrong_team` | wrong subject | The issue belongs to a different team than the intent named. | `$observed.issue_readback.data.issue.team.id` | `ne` | `$input.team_id` |
| `issue_predates_operation` | pre existing state | The issue is older than the operation. It proves nothing. | `$observed.issue_readback.data.issue.createdAt` | `time_before` | `$operation.created_at` |
| `duplicate_issue_present` | duplicate side effect | Linear created more than one issue with this title since the operation started. Do not retry. | `$observed.issue_created_events.count` | `gt` | `1` |
| `issue_assigned_to_another_user` | wrong subject | The issue carries another assignee than the intent named. | `$observed.issue_readback.data.issue.assignee.id` | `ne` | `$input.assignee_id` |

## Which observed states map to a verdict before completion?

| Rule | Match | Verdict | Reason |
| --- | --- | --- | --- |
| `issue_readback_refused` | `$observed.issue_readback.errors` exists `undefined` | UNVERIFIABLE | Linear answered the read with the status code 200 and an errors array. The answer is a refusal and it is no evidence. |
| `issue_left_the_workflow_unassigned` | (`$observed.issue_readback.data.issue.state.type` in `["canceled","duplicate"]`) and (not (`$observed.issue_readback.data.issue.assignee.id` eq `"$input.assignee_id"`)) | CONTRADICTED | A person or an agent closed the issue, and it never carried the intended assignee. Ask a person. |

## 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 | 604800000 ms |
| Stale read window | 20000 ms |
| On timeout | UNVERIFIABLE (`evidence_unavailable_before_timeout`), escalated to a person |

## Where do these rules come from?

- `linear.graphql#/mutations/issueUpdate`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/inputs/IssueUpdateInput/fields/assigneeId`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/Issue/fields/assignee`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.docs.issues#issues-in-the-linear-graphql-api/update-an-issue`: [linear.docs.issues](https://linear.app/developers/graphql), retrieved 2026-09-09
- `linear.docs.issues#issues-in-the-linear-graphql-api/error-handling`: [linear.docs.issues](https://linear.app/developers/graphql), retrieved 2026-09-09
- `linear.docs.issues#issues-in-the-linear-graphql-api/error-handling/p2`: [linear.docs.issues](https://linear.app/developers/graphql), retrieved 2026-09-09
- `linear.docs.issues#issues-in-the-linear-graphql-api/the-endpoint`: [linear.docs.issues](https://linear.app/developers/graphql), retrieved 2026-09-09
- `linear.graphql#/queries/issue`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/Issue/fields/id`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/IssuePayload/fields/issue`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/Issue/fields/team`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/inputs/IssueCreateInput/fields/teamId`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/Issue/fields/createdAt`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.graphql#/types/User/fields/id`: [linear.graphql](https://api.linear.app/graphql), retrieved 2026-09-09
- `linear.events#/events/Issue.update`: [linear.events](https://linear.app/developers/webhooks), retrieved 2026-09-09
- `linear.webhooks.graphql#/types/IssueWebhookPayload/fields/assigneeId`: [linear.webhooks.graphql](https://studio.apollographql.com/public/Linear-Webhooks/variant/current/schema/reference/objects), retrieved 2026-09-09
- `linear.docs.webhooks#linear-webhooks/the-fields-of-a-data-change-event`: [linear.docs.webhooks](https://linear.app/developers/webhooks), retrieved 2026-09-09

### Can linear.issue.assigned 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_assignee_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 Linear GraphQL API verification page](https://provely.sh/verify/linear)
- [Read the linear.issue.created contract](https://provely.sh/verify/linear/linear.issue.created)
- [Read the linear.issue.in_state contract](https://provely.sh/verify/linear/linear.issue.in_state)
- [Read what a completion contract contains](https://provely.sh/contracts)
- [Read what a receipt proves](https://provely.sh/docs/receipts)