Qualimetry
Enterprise
Set it once. Every repository inherits it.
Governance that has to be configured per repository is not governance, it is a suggestion. In Qualimetry the standards, the merge checks, the review behaviour, the analysis scope and the access model are organisation settings, and every project inherits them. Adding the four hundredth repository does not mean writing a four hundredth config file.
One setting, the whole estate
A project can hold a deliberate override, and that override is recorded and visible rather than buried in a repository file that nobody reviews. The exception is as auditable as the rule.
One organisation setting inherited by every project
Standards, merge checks, review behaviour, analysis exclusions and access are set once at the organisation level and inherited by every project. A project can hold a deliberate override, which is recorded and visible rather than hidden in a repository config file, so the exception is as auditable as the rule.
Inherited by every project, without being copied
- Payments API Inherited
- Customer web Inherited
- Legacy ledger OverrideThis project carries a recorded override rather than the inherited value.
- Every other project Inherited
The controls that decide how your software is governed
All of it in one place, owned by the people who are accountable for it rather than by whoever happened to create the repository.
Merge checks
Which of the three checks hold a merge, and the minimum compliance score they enforce, decided once for the organisation.
Review behaviour
Which projects are reviewed, which glob patterns are excluded, whether draft pull requests are skipped, and whether an update to an open pull request triggers a fresh review.
Analysis exclusions
Generated code, vendored directories and anything else that should never count, excluded at the organisation level rather than repeated per project.
Access control
Who can see what, and who can change it. Organisation administrators create and manage user accounts, and onboarding instructions go out automatically.
Custom categories
Your own business taxonomy, defined once and then used as the grouping axis by every report, every insight and every compliance rollup.
Source control systems
The accounts and instances Qualimetry connects through, registered centrally so a new repository is onboarded rather than integrated.
Package sources
Maven, Gradle, npm and NuGet settings held at organisation level, so a build resolves the same way on the cluster as it does on a developer machine.
Artificial intelligence
Review triggers, diff-only analysis, model tier, compliant code examples, metered mode, and the token and cost activity behind it.
API access and webhooks
Programmatic provisioning and event ingestion, so onboarding a repository can be part of your own automation rather than a manual step.
Act on hundreds of projects at once
Analysis Management is where an estate is actually run. Work is queued in bulk against whatever slice you care about, rather than one repository at a time.
- By build engine so a toolchain change can be re-analysed across everything that uses it.
- By branch class across main, develop or short-lived branches, together or separately.
- By state to re-run everything that failed, or everything never analysed at all.
- By recent activity to cover only branches with commits in the last week.
- Copy a project so a proven configuration becomes the template for the next one.
- Sync settings to push a configuration change across projects instead of editing each.
Accepting a risk is a decision, not a mute button
Every control needs an exception path, and the exception path is where governance usually fails. A suppression in Qualimetry carries everything needed to defend it later.
- Request, then approve or reject, with the requester and the decision both recorded.
- An AI assessment recorded against the decision, so the reviewer has an argued position rather than a bare severity number.
- The next compliant upgrade checked first, because an available fix is a better answer than an accepted risk.
- A scope and an expiry, from a single analysis up to the whole estate, so acceptance is bounded and revisited.
- An email to the requester on approval or rejection, editable before it goes.
Capacity is a setting, not a support ticket
The analysis cluster is managed rather than opaque. You can see the workers, the queues and the throughput, and tune concurrency yourself when a backfill needs to move faster.
- Live cluster nodes, their queues and their source-control accounts.
- Concurrency and queue speeds, adjustable per cluster.
- Cache inspection and clearance when a build needs a clean run.
- Throughput and queue depth reported alongside everything else in the estate.
Volume makes per-repository governance impossible
When agents multiply the rate of change, the only thing that keeps it coherent is that the rules were never per-repository in the first place.
The rate changes, the rules do not
A new standard, a tightened gate or a changed exclusion reaches every project and every agent from one edit, at whatever rate the estate is moving.
Nothing is configured in the dark
Settings live in the platform, not in files an agent could rewrite. An override is a recorded decision rather than a line in a config nobody reviewed.
Answerable after the fact
Who changed the gate, who accepted this risk, when does it expire, and which standard was in force when this code was written.
Underneath every stage, not beside them
Centralised control is not a step in the loop. It is the layer the loop runs on: the standards, gates, review behaviour and access that every stage reads are set here once, for the whole estate.
Centralised control, answered
Can a team still configure their own project?
How do we onboard hundreds of repositories?
What happens when we change a standard or a gate?
Who can change these settings?
Govern the estate, not the repository
Book a demo and see one organisation setting change the behaviour of every project at once.