When the check cannot run

Intake Standards never holds back a requester because of a fault of its own. When the model, Atlassian-hosted AI (Forge LLMs), cannot give a verdict, the request goes through and reaches the desk flagged for review.

The unverified result

Each check gets two attempts at the model. A check ends unverified when both fail:

A form whose configuration could not be resolved, for example because the standard could not be read, gives the same result without a model call.

The requester sees "We couldn't run the check" and "You can still send the request. The support team will review it manually." The rows stay at Not checked yet, and on the customer portal the request can be sent as it is. A word count under the minimum is not a fault: it fails at once, before any model call, and never ends unverified.

When the work item is created, Intake Standards adds the label intake-unverified and an internal note, because the value is not a verified pass. On the work item the field shows Unverified, and the intake-gate issue property records the result for reporting. Unverified requests reach the same review queue as requests that did not meet every check, so a fault at the model never costs you a request.

If every check on your site comes back unverified, tell Sientus Solutions support. Requests keep arriving during such a fault, so no requester reports being blocked. Watch for a run of unverified requests instead.

A work type with no enabled standard

When no version is enabled for a work type, there is nothing to check against. The field is a plain required box labelled "Describe your request", with no checklist and no Check button, and no call goes to the model. The value is saved with the status Not checked, and when the work item is created the text is copied into Description if that is empty. A Not checked request gets no label and no note.

Limits on the model

Forge LLMs allows each installation 100 model requests a minute, and each model 500,000 tokens a minute. One run is one request and a retry is a second, so about 100 runs a minute is the ceiling. Requesters' checks and the Evaluate tab share that allowance. A run with six checks used about 1,900 tokens in testing, so the request limit is the one a busy desk would reach first.

A check that runs into a limit fails like any other model error: one retry, then unverified. The requester can still send the request, and it reaches the desk flagged.

Advisory mode

Advisory mode is the incident switch for the whole app. While it is on, the checklist stays, every check still runs and its status is still recorded, but nothing blocks on the customer portal. A requester whose text fails sees "You can still send the request, but reviewers will probably come back with questions about the checks marked Not met." A text under a minimum of 40 words, on a standard with six checks, reads "Write at least 40 words so the check can run. You can still send the request, but covering the 6 checks next to the box speeds up the review."

Advisory mode applies to every site where the app is installed, not to yours alone, so it is not something to request for one site. We switch it on with a deploy during a fault on our side, such as the model failing, and off again once it is fixed. For a problem with one work type on your site, disable its standard instead; it needs no deploy.

Finding the requests affected

Unverified requests carry the label intake-unverified like any request that did not pass. Reviewing requests shows the queue filter and the JQL that finds only the unverified ones. The Run log tab shows when unverified results from the model began; a form that could not load its standard leaves no run log row.