Qualimetry
Enterprise
Author your standards once. Every agent, reviewer and gate uses them.
Your architecture standards, language standards, coding principles and policies belong in one governed, versioned library rather than in a wiki nobody reads and an agent never opens. Publish from the Standards Center and the same content reaches every place a decision about your code gets made.
Policies, principles, language standards and architecture
Five categories, one source of truth. Industry best practice is applied as a review perspective rather than as a category of its own, because it describes how the others are judged rather than being something you author.
Policies
What your organisation has decided must be true of its software, independent of language. The top of the chain, and the thing an auditor asks about first.
General Coding Principles
How code should be written anywhere in the estate: structure, naming, error handling, readability, testability.
Secure Coding Principles
The security posture every engineer and every agent is expected to hold, expressed as principles rather than a scanner ruleset.
Language Standards
Per-language rules with a rationale, a severity, and a compliant and non-compliant example, so an agent has a target to write to rather than a complaint to react to.
Architecture Standards
How your systems are meant to be structured and how they are meant to talk to each other, held as governed content rather than as a diagram nobody updates. Importable from an architecture MCP server you already run.
Architecture is the one most organisations have no home for. An architectural decision usually lives in a diagram nobody updates or in the heads of the people who made it, which means no reviewer checks it and no agent can read it. Here it is a governed category in its own right, published into agent context and reviewed on the pull request through exactly the same path as a naming rule.
Publish once, and it lands everywhere code is written
This is the part that makes a standards library worth keeping. Publishing does not produce a document; it reconfigures every consumer that acts on your rules.
One source of truth, four consumers
Standards are authored and published once in the Standards Center. Publishing distributes them to four consumers: the context of every coding agent, the AI reviewer that checks pull requests, the compliance score that gates merges, and a quality profile in the SonarQube instance you already run. Nobody maintains four copies.
- Before the code exists The agent's context MCPSkillsAgent apps
- When the PR opens The AI reviewer Five perspectives
- At the merge The compliance score ScoredTrendedGated
- For rules-based analysis Your SonarQube Quality profile
Import them from the MCP server you already run
Most organisations already hold their architecture somewhere an MCP server can reach: a decision record store, an internal knowledge base, a documentation server. Qualimetry connects to it and imports that content into the Standards Center as governed architecture standards.
- Point Qualimetry at an existing MCP server rather than retyping decisions nobody wants to write twice.
- What comes in arrives as draft, so an architect reviews and publishes rather than the import going straight live.
- Once published it behaves like every other category: into agent context, checked on the pull request, counted in compliance.
- The architecture your agents build to is then the architecture you actually decided on.
This is the gap that matters most in agentic work. An agent will infer a plausible architecture from the code it can see, and plausible is not the same as yours.
Draft, review, publish, with a history
Standards are a governed artefact, not a wiki page. Draft changes are staged, reviewed and published deliberately, and every version is retained.
- Draft standards are held separately until you finalise them.
- Full version history, so you can show what the rule was when a change was written.
- Import and export, so an existing standards library can be brought in rather than retyped.
- Standards can be excluded from AI review individually where that is the right call.
Starting from a blank page is why standards libraries fail
Qualimetry drafts candidate standards for a language or category so your architects edit rather than invent, and flags duplicates before the library sprawls.
- Suggested standards are proposed for review, never published automatically.
- Duplicate detection catches the same rule arriving twice in different words.
- The content stays yours. Qualimetry supplies structure and a starting point, not your opinions.
Clear, reviewable, and impossible to misread
A standard is more than a rule id. Each one carries the context a developer, a reviewer or an agent needs to get the code right the first time.
- Title and severity so teams know what matters most.
- Rationale and implications that explain why the standard exists.
- Compliant and non-compliant examples that show the fix, not just the fault.
- A classification of engineering or architecture, so an architectural decision is governed like one.
The compliant example is what an agent is handed when it asks how to fix a finding, which is why writing one is worth the effort.
From a policy you wrote to the code an agent writes
Every finding traces back to a documented language standard, which upholds a principle, which implements a policy. Nothing is enforced that you did not decide.
The golden thread, from policy to compliance score
A six stage chain. A policy sets organisation intent, a principle upholds it, a language standard makes it concrete, that standard is carried into the agent's context as it writes, the pull request is reviewed against it, and the result becomes a compliance score.
- Policy Organisation intent
- Principle General and secure
- Language standard Per-language, with examples
- In the agent's context Delivered before code is written
- Reviewed on the PR Against the same standard
- Compliance score Measured, trended, gated
Because the chain is explicit, you can answer the questions auditors and engineering leaders actually ask: which policy does this standard serve, why is it here, and where is it being breached.
Where this sits in Continuous Analysis
None of this works as a separate product. Each stage exists because of the one before it and is only worth doing because of the one after it.
Standards, gates, review behaviour and access are organisation settings, so none of this is configured per repository.
The MCP server, the agent apps and the file-open hook put those standards in front of the agent before it writes.
The Standards Center, answered
Do we have to use Qualimetry's standards?
What does publishing actually do?
Can we govern architecture as well as code style?
Can we exclude a standard from AI review?
Which languages do you support?
Make your standards act on your code
Book a demo and we will take one of your policies all the way through to an agent producing compliant code against it.