ProvelyNo. Linear GraphQL API returns a success response when it accepts the request. The issue then holds one of 7 states. Only completed is terminal success. Provely proves assigned, created and in_state as separate promises.
| Fact | Value |
|---|---|
| Skill version | 0.1.0 |
| Publisher | Built and signed by Provely. |
| Certification | Provisional (score 49 of 100) |
| Last conformance run | 2026-09-05T12:00:00Z: 41 of 41 cases passed, 0 critical false VERIFIED |
| Provider API versions | fp_2026_09 |
| Default provider API version | fp_2026_09 |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | f2d5d5872a103491 |
| 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 |
|---|---|---|---|
| The issue carries the intended user as its assignee. It does not prove that the user did the work. | linear.issue.assigned | E2 + E3 | proven |
| The record exists with the intended title. It does not prove the workflow state, and it does not prove the assignee. | linear.issue.created | E2 + E3 | proven |
| The issue sits in the state that the person authorised, and that state belongs to the intended team. | linear.issue.in_state | E2 + E3 | proven |
| An outcome outside Linear GraphQL API, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
| The agent report that the action worked | never counts | E0 | not proven |
Which completion levels does the Linear GraphQL 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 |
|---|---|---|---|---|
assigned | linear.issue.assigned v1.0.0 | The issue carries the intended user as its assignee. It does not prove that the user did the work. | E2 + E3 | Provisional |
created | linear.issue.created v1.0.0 | The record exists with the intended title. It does not prove the workflow state, and it does not prove the assignee. | E2 + E3 | Provisional |
in_state | linear.issue.in_state v1.0.0 | The issue sits in the state that the person authorised, and that state belongs to the intended team. | E2 + E3 | Provisional |
What is the Linear GraphQL API lifecycle?
Which states can a linear.issue be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
triage | transitional | PENDING | The issue waits in the triage state of its team. A team that enabled triage puts an issue of a person outside the team there. | linear.graphql |
backlog | transitional | PENDING | The issue sits in a backlog state of its team. Linear puts an issue that a caller created without a stateId there. | linear.graphql |
unstarted | transitional | PENDING | The issue sits in an unstarted state of its team. Nobody started the work. | linear.graphql |
started | transitional | PENDING | The issue sits in a started state of its team. The member startedAt states the time of the move. | linear.graphql |
completed | terminal success | VERIFIED | The issue sits in a completed state of its team. The member completedAt states the time of the move. | linear.graphql |
canceled | terminal neutral | FAILED | A person or an agent moved the issue into a canceled state. The work did not happen. | linear.graphql |
duplicate | terminal neutral | FAILED | A person or an agent marked the issue as a duplicate of another issue. The work moved elsewhere. | linear.graphql |
In linear.issue under provider API version fp_2026_09, completed is the only state that means terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE.
Source: linear.graphql · retrieved 2026-09-09
How does Provely tie the evidence to this exact operation?
A matching state that already existed must not verify. Every contract names the correlation keys that bind the evidence to the operation, and the idempotency key that stops a duplicate side effect.
| Strategy | Assurance | Keys | Required | Window |
|---|---|---|---|---|
resource_id | strong | issue_id from $action.result.issueCreate.issue.id | yes | none |
fingerprint | weak | team_id from $input.team_id; title from $input.title | no | 600000 ms |
In words
- E0 agent assertion: never sufficient.
- E1 action response: the provider acknowledged the request.
- E2 provider readback: the runtime read the resource back.
- E3 provider event: the provider reported the change.
- E4 independent system: a system outside the action path agrees.
- E5 external outcome: the result is observable in the world.
Which evidence channels does the skill read?
The runtime prefers the channel that is more independent from the action path. Read the evidence level definition. An acknowledgement from Linear GraphQL API is E1 and never terminal success.
| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
|---|---|---|---|---|---|
issue_action_response | E1 | same response | action_result | yes | not stated |
issue_assignee_events | E3 | provider event | webhook | no | 2000 ms |
issue_created_events | E3 | provider event | webhook | no | 2000 ms |
issue_readback | E2 | provider readback | http | yes | 400 ms |
issue_state_events | E3 | provider event | webhook | no | 2000 ms |
workflow_state_readback | E2 | provider readback | http | yes | 400 ms |
Which ways can a Linear GraphQL API action look done and not be?
| Contract | Case | Rule | Verdict |
|---|---|---|---|
| linear.issue.assigned | wrong subject | The issue belongs to a different team than the intent named. | CONTRADICTED |
| linear.issue.assigned | pre existing state | The issue is older than the operation. It proves nothing. | CONTRADICTED |
| linear.issue.assigned | duplicate side effect | Linear created more than one issue with this title since the operation started. Do not retry. | CONTRADICTED |
| linear.issue.assigned | wrong subject | The issue carries another assignee than the intent named. | CONTRADICTED |
| linear.issue.assigned | observed state | Linear answered the read with the status code 200 and an errors array. The answer is a refusal and it is no evidence. | UNVERIFIABLE |
| linear.issue.assigned | observed state | A person or an agent closed the issue, and it never carried the intended assignee. Ask a person. | CONTRADICTED |
| linear.issue.created | wrong subject | The issue belongs to a different team than the intent named. | CONTRADICTED |
| linear.issue.created | wrong subject | The issue carries a different title than the intent named. | CONTRADICTED |
| linear.issue.created | pre existing state | The issue is older than the operation. It proves nothing. | CONTRADICTED |
| linear.issue.created | duplicate side effect | Linear created more than one issue with this title since the operation started. Do not retry. | CONTRADICTED |
| linear.issue.created | observed state | Linear answered the read with the status code 200 and an errors array. The answer is a refusal and it is no evidence. | UNVERIFIABLE |
| linear.issue.in_state | wrong subject | The issue belongs to a different team than the intent named. | CONTRADICTED |
| linear.issue.in_state | wrong subject | The issue carries a different title than the intent named. | CONTRADICTED |
| linear.issue.in_state | pre existing state | The issue is older than the operation. It proves nothing. | CONTRADICTED |
| linear.issue.in_state | duplicate side effect | Linear created more than one issue with this title since the operation started. Do not retry. | CONTRADICTED |
| linear.issue.in_state | wrong subject | The workflow state of the issue belongs to another team than the intent named. Stop and ask a person. | CONTRADICTED |
| linear.issue.in_state | observed state | Linear answered the read with the status code 200 and an errors array. The answer is a refusal and it is no evidence. | UNVERIFIABLE |
| linear.issue.in_state | observed state | A person or an agent moved the issue into a canceled state or a duplicate state. The issue can never reach the promised state. Ask a person. | CONTRADICTED |
| linear.issue.in_state | observed state | The identifier of the intent names a workflow state with another name than the person named. Ask a person. | CONTRADICTED |
| linear.issue.in_state | observed state | The issue has not reached the promised workflow state. The runtime observes again. | PENDING |
What did the last conformance run show?
| Dimension | Score | Maximum |
|---|---|---|
| Documentation | 14 | 20 |
| Schema alignment | 0 | 15 |
| Lifecycle certainty | 20 | 20 |
| Evidence strength | 16 | 20 |
| Causal correlation | 15 | 15 |
| Sandbox conformance | 10 | 10 |
| Raw score | 75 | 100 |
| Score after the caps | 49 | 100 |
The raw score is 75. 2 hard caps apply, so the score is 49 and the level is Provisional.
| Reason | Highest score it allows |
|---|---|
| 13 uncertainty records are open. The lowest cap is 49. | 49 |
| 3 mandatory cases are missing. Example: linear.issue.assigned:terminal_failure. | 74 |
| Contract | Raw score | Score after the caps | Certification |
|---|---|---|---|
linear.issue.assigned | 75 | 49 | Provisional |
linear.issue.created | 75 | 49 | Provisional |
linear.issue.in_state | 75 | 49 | Provisional |
The weakest contract is linear.issue.assigned. It scores 49 and 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.
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.
| Case class | Passed | Total |
|---|---|---|
| duplicate side effect | 3 | 3 |
| 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 | 3 | 3 |
| timeout after commit | 3 | 3 |
| version mismatch | 3 | 3 |
| webhook duplicate | 3 | 3 |
| webhook out of order | 3 | 3 |
| wrong subject | 3 | 3 |
| wrong terminal state | 2 | 2 |
The conformance artifact digest is f20ff4a33af4f874. 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. 13 uncertainty records are open. The lowest cap is 49. 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 |
|---|---|---|---|
| linear.docs.issues | docs | 2026-09-09 | authored |
| linear.docs.states | docs | 2026-09-09 | authored |
| linear.docs.versions | docs | 2026-09-09 | authored |
| linear.docs.webhooks | docs | 2026-09-09 | authored |
| linear.events | event sample | 2026-09-09 | authored |
| linear.graphql | graphql | 2026-09-09 | trimmed |
| linear.webhooks.graphql | graphql | 2026-09-09 | trimmed |
How do I verify a Linear GraphQL API action?
Verify a Linear GraphQL API action with Provely
- Begin the operation.Call
beginwith the contractlinear.issue.assignedand the input. Keep the operation id. - Make the Linear GraphQL API call you make today.Send the request with the correlation metadata that
beginreturned. - Submit the acknowledgement.Call
action_resultwith the Linear GraphQL API response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readsissue_action_response,issue_assignee_events,issue_created_events,issue_readback,issue_state_eventsandworkflow_state_readbackand 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 assigned level prove the in_state level?
No. The issue carries the intended user as its assignee. It does not prove that the user did the work. The issue sits in the state that the person authorised, and that state belongs to the intended team. Use linear.issue.in_state to prove in_state.
What does the agent say while Linear GraphQL API reports triage, backlog, unstarted and started?
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 Linear GraphQL API API versions does the skill support?
fp_2026_09. An operation on another version returns UNVERIFIABLE with the reason version_unsupported. The runtime never guesses.
Does Provely need write access to Linear GraphQL API?
No. The agent keeps its write key. The verifier reads with a separate read-only credential where Linear GraphQL API permits it, and it never shares that credential with the agent.