CogniRunner
A Jira application built on the Atlassian Forge platform that provides a workflow validator. It supports project-level pinning of AI providers, allowing AI validation requests for a given project to be routed to a designated provider.
Timeline (last 90 days)
CogniRunner's pin feature supports project-level AI provider binding, meaning that within a single Jira Cloud site, one project's AI calls can be directed to a specified provider (such as a local LM Studio), while other projects continue to use the site's default cloud provider.
CogniRunner runs on the Atlassian Forge platform, and through a validator (workflow validator) it reads request fields and looks up project configuration during Jira status transitions; if the project is pinned it calls the targeted address, otherwise it goes to the site's default provider.
In a test on October 14, 2026, an HR request text containing information about a colleague's sick leave after back surgery was rejected by the local model all 8 times it was sent (HTTP 400), while all 8 sends not containing that information passed (HTTP 204), and no two of the 8 rejection reasons given were exactly the same.
When a project binding has saved an incorrect token, LM Studio rejects the call with a 401 before the model ever sees the content, and CogniRunner's validator by default fails open and lets it through, causing the request to enter In review via HTTP 204 without being checked.
CogniRunner's default fail-open behavior is silent: there is no alerting, no counting metric, and no visibility into the number of fail-open occurrences, so operators cannot perceive that validation has been bypassed.
Across three broken-pin scenarios (project bound to Anthropic but with no key, bound to LM Studio but with no token, and with an incorrect token saved), all three requests in total passed without being checked.
The inherent pressure on a Jira workflow validator is that it is synchronously blocking—if the validator does not respond for a long time, the status transition gets stuck and thereby freezes the entire approval queue, so CogniRunner defaulting to letting things through when the AI service is abnormal is an understandable engineering trade-off.
Local deployment does not equal data never leaving the premises: LM Studio server logs are kept on the Mac and fully store every answer from the model; CogniRunner execution logs store the first 300 characters of fields for each record and retain them for up to 30 days.
All Facts (8)
Local deployment does not equal data never leaving the premises: LM Studio server logs are kept on the Mac and fully store every answer from the model; CogniRunner execution logs store the first 300 characters of fields for each record and retain them for up to 30 days.
50%UnverifiedCogniRunner runs on the Atlassian Forge platform, and through a validator (workflow validator) it reads request fields and looks up project configuration during Jira status transitions; if the project is pinned it calls the targeted address, otherwise it goes to the site's default provider.
50%UnverifiedThe inherent pressure on a Jira workflow validator is that it is synchronously blocking—if the validator does not respond for a long time, the status transition gets stuck and thereby freezes the entire approval queue, so CogniRunner defaulting to letting things through when the AI service is abnormal is an understandable engineering trade-off.
50%UnverifiedCogniRunner's pin feature supports project-level AI provider binding, meaning that within a single Jira Cloud site, one project's AI calls can be directed to a specified provider (such as a local LM Studio), while other projects continue to use the site's default cloud provider.
50%UnverifiedWhen a project binding has saved an incorrect token, LM Studio rejects the call with a 401 before the model ever sees the content, and CogniRunner's validator by default fails open and lets it through, causing the request to enter In review via HTTP 204 without being checked.
50%UnverifiedCogniRunner's default fail-open behavior is silent: there is no alerting, no counting metric, and no visibility into the number of fail-open occurrences, so operators cannot perceive that validation has been bypassed.
50%UnverifiedIn a test on October 14, 2026, an HR request text containing information about a colleague's sick leave after back surgery was rejected by the local model all 8 times it was sent (HTTP 400), while all 8 sends not containing that information passed (HTTP 204), and no two of the 8 rejection reasons given were exactly the same.
50%UnverifiedAcross three broken-pin scenarios (project bound to Anthropic but with no key, bound to LM Studio but with no token, and with an incorrect token saved), all three requests in total passed without being checked.
50%