Software Development, DevOps and SRE Platform
From Agile and Scrum Planning to Auto Delivery and Testing.
Noviqent watches your tickets — Jira, ServiceNow, Linear, or Azure DevOps Boards — for a label you choose. Whether it's a new feature, an enhancement, a bug fix, or an operational issue, it gathers the relevant code, runbooks, related tickets, and live observability data; asks Claude, GPT, Gemini, Grok, or your own private endpoint to write the real, complete change — or propose an operational action, like restarting a deployment or rolling back a release, for a human to approve; opens it as a draft pull request; waits for CI; and reports back onto the ticket, in Slack too if you connect it. Nothing merges, and nothing runs against your infrastructure, without a human.
A real code change, tested before you review it
Sample sprint ticket
CI passedFEAT-204: Add CSV export to the invoices page
What was built
Added an Export CSV button to Invoices, backed by a new /invoices/export endpoint that streams the currently filtered results.
Confidence
High
Pull request
Draft, ready
acme/api#58
✓ Draft PR opened · CI passed · commented back onto OPS-1841
Illustrative — your dashboard shows your own tickets.
From Sprint Planning to Automated Delivery
A ticket planned into a sprint doesn't need to wait for someone to pick it up. The moment it carries your trigger label, delivery and testing start immediately — so sprint velocity isn't limited by how many tickets your team can physically start in two weeks.
Planned
Pulled into the sprint
A feature, enhancement, or fix your team already planned gets pulled into the sprint backlog and carries your trigger label — no extra process to run it through.
Delivered
Built, not just drafted
Source, runbooks, and related tickets are gathered automatically, and your configured AI provider writes the complete change — opened as a real, reviewable draft pull request, not a proposal document.
Tested
Checked before review
The draft PR's own CI runs before anyone reviews it, so by the time a sprint item reaches your board, the team already knows whether it works.
The result: a sprint backlog that moves at the speed of your CI pipeline, not the speed of whoever has a free hour to start the next ticket.
Six stages, one webhook
Everything between a labelled ticket and an engineer having a tested pull request to review.
1
A ticket carries your trigger label
The webhook posts to us the moment it's created or updated — we re-fetch the ticket ourselves through your own credentials and check the real, current labels, rather than trusting the webhook payload.
2
Context is gathered
The relevant source files from your GitHub or GitLab repository, runbook pages from your Confluence, related tickets from Jira — and, if a repository or service isn't reachable over a public API at all, the output of read-only commands run by an agent inside your own network.
3
Your AI provider writes the change
One call to whichever provider your organisation has configured — Claude, GPT, Gemini, Grok, or a private-hosted endpoint you control — returning the complete new content of every file it touches, not a diff description, whether that's a new feature, an enhancement, or a fix. It can ask, once, for more read-only context from your on-prem agent before it answers. Or an honest "I can't make this change" when it can't.
4
A draft pull request opens
A real branch, a real commit, a real PR — marked draft so nothing merges it and most CI configurations still run against it. GitHub and GitLab both refuse to merge a draft.
5
Its own CI runs, and we watch it
Opening the PR already triggers your CI — we poll the branch's checks (or pipeline, on GitLab) until they finish. If you've configured a test command for your on-prem agent to run in your own dev environment, that result counts alongside public CI, not instead of it.
6
The result lands back on the ticket
Root cause, the PR link, and whether CI passed — commented straight onto the ticket you were already watching. A human reviews and merges; nothing here does either.
The part most tools skip
A real fix, tested before you look at it.
Most AI coding tools stop at a diff description or a proposal document. Noviqent writes the complete new content of every file it touches, opens that as a genuine draft pull request, and waits for your own CI to run against it — so by the time it reaches you, you already know whether it works.
- The fix opens as a draft pull request — GitHub and GitLab won't merge a draft, and closing one costs a click.
- We never run your CI ourselves — we only poll the result your own CI system already reports.
- Every connector credential is encrypted at rest, or lives in your own Vault space; the API returns whether one is configured, never the value.
- The webhook payload's own fields are never trusted — only the ticket key is used, to look the real ticket up through your own credentials.
- Nothing here comments back onto a ticket, opens a PR, or touches your code unless you connected that tool yourself.
How data actually flows
Every hop, in order — including the one step that's your own configuration choice, not ours.
1
Jira's webhook reaches our platform
Posted over HTTPS to a URL scoped by an unguessable connector id — into infrastructure Noviqent operates directly, not a third-party cloud subprocessor for this part of the flow.
2
We read from your tools — the only write is the PR you asked for
Jira, GitHub, GitLab, and Confluence are read-mostly. The one write every organisation explicitly configures is the draft pull request itself, plus one comment back onto the ticket.
3
Gathered context and your source code go to your AI provider
Claude, GPT, Gemini, Grok, or your own private endpoint — your organisation's choice, using your own key. Point it at an endpoint you host yourself and no AI vendor is involved at all.
4
A pull request comes back — never a merge
The fix lands as a draft PR in your own repository for review. Nothing here has merged anything, run a deploy, or touched production.
5
CI runs on your infrastructure, not ours
We only poll the result your own CI system already reports — GitHub Checks, GitHub Commit Status, or GitLab Pipelines. No build ever executes on our platform.
6
Every credential is isolated from the code it touches
Encrypted at rest in our database, or — if you'd rather we never hold it at all — kept in your own Noviqent Vault space and resolved at the moment it's needed.
Credential storage
Every credential lives in Vault — yours, not ours.
Noviqent Vault is a credential store your organisation controls, separate from this application. Point any connector at a named secret instead of pasting a raw credential in — we resolve it at the moment it's needed and never store the value ourselves. If you'd rather we hold a credential directly, that stays available too: encrypted at rest, never returned by any API response.
Visit Vault →- Your own Vault space, isolated from every other organisation's — not a shared multi-tenant store.
- A secret is referenced by name in a connector's config, never pasted in as plaintext.
- We resolve it at the moment a connector actually needs it — nothing is cached or copied locally.
- Lost access key? A Vault admin reissues one from Vault's own Login methods tab — we never hold it either.
Built to fit into your own compliance program
If your organisation holds SOC 2 or ISO 27001, is pursuing Cyber Essentials, or has UK GDPR obligations of its own, a vendor like this becomes part of your own audit scope.
Access control & least privilege
SOC 2 CC6 · ISO 27001 Annex A.9 · NCSC Cloud Security Principle 9
Role-based access per organisation, connector credentials scoped to exactly the read/write pattern each integration needs, and nothing shared across organisations.
Encryption in transit and at rest
SOC 2 CC6 · ISO 27001 Annex A.10 · UK GDPR Art. 32 · NCSC Cloud Security Principles 1 & 5
HTTPS everywhere, credentials encrypted at rest or held in Vault instead, and secrets never returned by any API response — only whether one is configured.
Audit logging
SOC 2 CC7 · ISO 27001 Annex A.12 · Cyber Essentials (Security Update Management)
Every credential change and every membership change is written to an append-only audit record — not a mutable column that can be edited after the fact.
Data minimisation & residency
UK GDPR Art. 5 · Art. 44
Your ticket and source-code data is processed and stored on infrastructure Noviqent operates directly. The one step that leaves that boundary — the AI reasoning call — is your own configuration choice, disclosed in full in our sub-processor register.
Basic cyber hygiene
Cyber Essentials
Boundary controls, secure configuration, patch management, and malware protection on the infrastructure this application runs on — the baseline UK government-backed scheme, not a claim of certification.
For a full data-processing breakdown see our Privacy Notice, or email compliance@noviqent.co.uk for a security questionnaire or a Data Processing Agreement.
Connects to what you already run
Each connector is read-only except for the two writes every fix attempt makes: the draft pull request, and one comment back onto the ticket.
Jira, ServiceNow, Linear & Azure DevOps Boards
Four triggers, one pipeline — a ticket carrying your chosen label in any of them starts a fix attempt, and the result is commented straight back onto it.
GitHub & GitLab
Reads the source of the affected service, and opens the draft pull or merge request carrying the fix.
Grafana
Optional: pulls live logs, metrics, and firing alerts related to the ticket, so the fix is grounded in what's actually happening, not just the code.
Confluence
Optional: searches your runbook and documentation wiki for pages related to the ticket. Read-only — nothing is ever filed into it.
Slack
Optional: every ticket update — fix drafted, PR opened, CI result — is also posted to one Slack channel.
On-prem agent
For a repository, wiki, or test environment with no public API at all: a small process you run inside your own network, polling us for read-only commands to run and, in your own dev environment, tests.
Kubernetes, AWS, Azure, GCP, Jenkins, ArgoCD, Terraform & more
Not a code bug? The same on-prem agent can run an organisation-approved operational action — restart a deployment, roll back a release, re-run a pipeline. A human always approves the exact command first.
Prior investigations
Every resolved ticket becomes something the next similar one can draw on — no separate setup, no re-investigating the same root cause twice.
Plus Claude, GPT, Gemini, Grok, or an OpenAI-compatible endpoint you host yourself for the reasoning step — bring your own key, or bring your own infrastructure.
Built for more than one team
From a single repository to thousands of them, spread across every team, cloud, and Jira project you run.
Scope any connector to a team
Every connector — and every on-prem agent — can be scoped to a routing key. One team gets their own Jira project, their own repository, their own on-prem agent with access to their own cloud accounts, managed independently of every other team.
Four role templates, or your own groups
Administration, Engineer, Reviewer, and Read Only cover most people directly. For everyone else, group a set of members under one role template — someone can be lifted with one extra capability, like approving remediation actions, without a full role change.
One identity across the whole fleet
Already run Noviqent's Incident Management and Response? Creating an organisation here can automatically bring across the Vault-backed connectors you already configured there — no credential ever leaves your own Vault space to do it.
Stop starting every ticket from zero
Connect Jira and your source control, label one ticket, and the next thing that reaches you is a tested pull request instead of a blank editor.
Get started