The problem: yesterday's approval is not today's release
A release owner approved agent version 1.4. Version 1.5 arrives with a critical security finding. The old approval is still visible in the issue history—but should it authorize the new release?
Agent Readiness Gate helps AI platform engineers, security reviewers and release owners answer that question inside Jira. It keeps the candidate version, supplied evaluation evidence, policy checks and human approval together. Our goal is to make stale approval visible before a team makes its release decision.
What it does
The Forge issue panel checks mandatory evidence with a deterministic policy engine. Missing, stale or version-mismatched evidence produces BLOCKED. Repairing evidence does not silently approve the release: an authorized reviewer must explicitly approve the exact version, evidence and policy. Changed evidence invalidates the approval; a new version cannot inherit it.
Previous decisions remain visible in history. A reviewer can preview and explicitly confirm a Jira remediation task for a failed control; repeated confirmation returns the same task instead of creating duplicates. An optional read-only Rovo advisor explains the current assessment and blockers. It cannot grant approval or override the policy.
Why more than a checklist?
A checklist records that someone checked a box. This app binds approval to a particular release, evidence fingerprint and policy version, then recalculates readiness when that input changes. We verified both a version 1.4 → 1.5 regression and a new evaluation of the same version 2.1: even when its measured scores still pass, replacing the evidence invalidates the old approval. Earlier decisions remain in history.
This is an assessment and review gate: it does not intercept deployments or prevent Jira workflow transitions. READY means the supplied evidence meets the configured policy, not that an agent is guaranteed safe.
How we built it
TypeScript and React power a Forge Custom UI panel. Forge resolvers validate evidence and check Jira permissions as the current user. A pure policy engine makes the decision without an LLM. Forge storage retains release state, approval bindings, history and remediation records. The core workflow needs no external model service or API key.
Challenges and lessons
The hardest boundary was defining what an approval actually covers. We bind it to the exact release and evidence and check the expected revision to avoid approving stale state. Server-side authorization protects writes; hiding a button is insufficient. Persistent duplicate prevention handles repeated remediation requests. Testing also showed that site administrator access does not necessarily grant project approval permissions, so setup instructions explain the project role requirement.
Measured evaluation and Rovo: supplemental demo
Watch the 2:10 actual-interaction supplement: two real model evaluation reports flow into Jira, a separate approval becomes READY, and a new run of the same version invalidates it. The opening shows an actual Rovo assessment on the separate development scenario. English narration is synthetic; the screens are real. The main video above retains the original regression and remediation walkthrough.
What we verified
179 automated tests cover validation, policy, permissions, persistence, remediation, panel journeys and the evaluation runner. Production 2.1.0 runs on the second test site; development 2.3.0 includes the optional Rovo advisor.
We executed GPT-5 mini twice on the same support-triage candidate version 2.1: each run completed 100/100 exact-match quality cases and 12 model/platform injection probes (11 model responses passed; Azure blocked one probe). These are synthetic, template-correlated cases, not a representative benchmark or a security audit. The raw reports, earlier failed attempts and reproducible runner are public. Exported JSON preserves run IDs, timestamps and report hashes; it contains no approval.
In real Jira, a distinct test account imported the first report. The policy stayed BLOCKED with only approval missing; that account could read and import but could not use approval controls. The project-authorized owner explicitly approved, and READY survived Reload. Importing the second actual run of the same version returned the issue to BLOCKED and retained the earlier READY in history.
Rovo separately retrieved ARG-1's current assessment: BLOCKED, agent 1.5, policy 1.0, exact failed control/evidence IDs and a fresh assessment time. It stated that it cannot approve, override policy, change evidence or create tasks. This Rovo demonstration uses the development site's synthetic regression scenario; the measured model flow uses AGA-5 on the second site.
These are engineering acceptance results. The two accounts are controlled by the same person, not independent user research. The live negative test verified disabled approval controls; server-side denial has automated coverage, while direct adversarial invocation and hidden-issue live tests remain outstanding.
Try the release review
Use the Forge installer and setup instructions. Create a synthetic Jira software issue and open Agent Readiness Gate from Apps. The reviewer needs Edit Issues and Administer Projects in that project.
- Load and save the blocked sample: inspect missing rollback and approval.
- Load and save repaired evidence: approval is still required.
- Explicitly approve the release, then reload to verify READY persists.
- Load and save the regression sample: version 1.5 is BLOCKED and the earlier READY remains historical.
- Preview and confirm remediation separately; repeat to verify duplicate prevention.
No local checkout, developer token, tunnel or external model account is needed. Rovo is optional and depends on site availability.
Limits and next steps
The current prototype imports small user-supplied JSON; it does not automatically collect or independently attest evaluation results. Samples are synthetic. History is append-only through application APIs, not a tamper-proof archive. The video is a continuous excerpt of actual Jira interactions, cropped to the app panel, with synthetic English narration.
An optional evaluation runner now executes a model, retains responses and exports measured JSON for explicit Jira import. The evidence guide explains the review boundary. Next priorities are first-use testing with release owners, broader permission acceptance, and retention/deletion requirements before production use. We have not yet validated demand or quantified time savings. No MCP, Teamwork Graph or Marketplace capability is claimed.
Log in or sign up for Devpost to join the conversation.