ProvelyProve that the issue sits in the workflow state that the person named. The issue sits in the state that the person authorised, and that state belongs to the intended team.
| Fact | Value |
|---|---|
| Contract id | linear.issue.in_state |
| Version | 1.0.0 |
| Hash | 95967bbb661df54d |
| Completion level | in_state |
| Publisher | Built and signed by Provely. |
| Certification | Provisional |
| Skill | Linear GraphQL API 0.1.0 |
| Valid for provider API versions | fp_2026_09 |
What is the intent?
Get the issue into this workflow state of this team.
What is the subject and the action?
| Member | Value |
|---|---|
| Subject type | linear.issue |
| Canonical effect | work.issue_create |
| Provider operation | mutation issueCreate |
| Idempotency | none, retry is not safe |
Which false successes give CONTRADICTED?
- duplicate side effect
- pre existing state
- wrong subject
The signed contract states the exact conditions, the evidence and the timing. The runtime reads them. The page states the promise.
Where do these rules come from?
linear.graphql#/mutations/issueUpdate: linear.graphql, retrieved 2026-09-09linear.graphql#/inputs/IssueUpdateInput/fields/stateId: linear.graphql, retrieved 2026-09-09linear.graphql#/types/Issue/fields/state: linear.graphql, retrieved 2026-09-09linear.docs.states#workflow-states/a-workflow-state-belongs-to-one-team: linear.docs.states, retrieved 2026-09-09linear.docs.issues#issues-in-the-linear-graphql-api/update-an-issue: linear.docs.issues, retrieved 2026-09-09linear.docs.issues#issues-in-the-linear-graphql-api/error-handling: linear.docs.issues, retrieved 2026-09-09linear.docs.issues#issues-in-the-linear-graphql-api/error-handling/p2: linear.docs.issues, retrieved 2026-09-09linear.docs.issues#issues-in-the-linear-graphql-api/the-endpoint: linear.docs.issues, retrieved 2026-09-09linear.graphql#/queries/issue: linear.graphql, retrieved 2026-09-09linear.graphql#/types/Issue/fields/id: linear.graphql, retrieved 2026-09-09linear.graphql#/types/IssuePayload/fields/issue: linear.graphql, retrieved 2026-09-09linear.graphql#/types/Issue/fields/team: linear.graphql, retrieved 2026-09-09linear.graphql#/inputs/IssueCreateInput/fields/teamId: linear.graphql, retrieved 2026-09-09linear.graphql#/types/Issue/fields/createdAt: linear.graphql, retrieved 2026-09-09linear.graphql#/types/WorkflowState/fields/team: linear.graphql, retrieved 2026-09-09linear.graphql#/types/WorkflowState/fields/name: linear.graphql, retrieved 2026-09-09linear.docs.states#workflow-states/the-name-and-the-position-of-a-workflow-state: linear.docs.states, retrieved 2026-09-09linear.graphql#/types/WorkflowState/fields/id: linear.graphql, retrieved 2026-09-09linear.events#/events/Issue.update: linear.events, retrieved 2026-09-09linear.webhooks.graphql#/types/IssueWebhookPayload/fields/stateId: linear.webhooks.graphql, retrieved 2026-09-09linear.docs.webhooks#linear-webhooks/the-fields-of-a-data-change-event: linear.docs.webhooks, retrieved 2026-09-09
Can linear.issue.in_state return VERIFIED from the action response alone?
No. The action response is E1, and an acknowledgement is never terminal success. The contract needs evidence of level E2 or higher from Linear GraphQL API.
What happens after the timeout?
The verdict is UNVERIFIABLE. The operation goes to a person for review.