Enforced by a build test, not a marketing claim.
Vannus records who legally controls AI vendors, and publishes no grade, score, tier or ranking. The claim this page is about is narrower: the modules listed below have no path of dependency on partnership, affiliate, or monetization data. Every record in our catalog and every Concierge audit must be defensible regardless of who pays Vannus a referral commission.
Most platforms make a claim like this in marketing copy. We enforce it in code.
The modules on the neutrality list below import no partnership,
affiliate, or monetization module, directly or through another import.
A test in our continuous-integration pipeline fails the build if one of
them starts to, directly or through the modules it imports in turn,
including through a package’s __init__
file — and none of those modules reaches the code that records who
pays Vannus a commission. This is a property of how the code is
wired, not a promise in marketing copy.
A separate Python test — praxis/tests/test_neutrality_invariant.py — performs static analysis on the source code of the modules on the neutrality list below. It walks every import statement in every one of those modules, follows those imports transitively, including into each package’s __init__ file, and asserts that no module in that import graph reaches any module on the forbidden list.
The test lives in the same source tree as the modules it checks. It runs on every change. If anyone, at Vannus or outside it, ever adds an import of a partnership, affiliate or monetization module to a module on the list, directly or through another import, including a package’s __init__ file, the build fails with a clear violation path before the change can land:
# Hypothetical violation report from the test Structural neutrality violated. Violations: - praxis.concierge.scoring → praxis.tools → praxis.affiliates
The same logic that produces a green build also produces the neutrality check above. They share a single source of truth in praxis/neutrality_attestation.py. There is no way for the test to pass while the public attestation reports a violation, or vice versa.
The check covers the following 23 modules, named in praxis/neutrality_attestation.py. The claim stops at this list: a module that is not on it is not covered by the check.
The forbidden modules exist in the codebase — praxis.affiliates holds the affiliate links, and praxis.monetise the monetization layer — but no module on the list above reaches them, directly or through another import.
The most common failure mode for an "independent" review or recommendation platform is not deliberate corruption. It's gradual drift: someone wires the affiliate URL into the recommendation flow because it's convenient; six months later, three other code paths quietly depend on that wiring; the platform's outputs are now contaminated and no one is sure exactly when it happened.
Code-enforced separation closes that drift before it starts, for the modules on the list. Importing either forbidden module into one of them, directly or through another module, including a package’s __init__ file, by accident or on purpose, fails the build. The test runs on every build, and it runs the same code that produces the check above. The source repository is private, so an auditor cannot re-run it unaided — we provide praxis/neutrality_attestation.py and praxis/tests/test_neutrality_invariant.py on request for review.
Three checks any technically-minded reader can perform without leaving this page:
/.well-known/neutrality.json and confirm scoring_imports_monetization is false (the field keeps the name it had before Vannus stopped scoring in September 2026; it covers the modules on the neutrality list).violations is an empty list. Any module on the list that imported a monetization module, through any import, including a package’s __init__ file, would be named there, and the build would have failed.scoring_stack (the neutrality list, under its pre-September-2026 field name) against forbidden_modules. The first is the modules on the neutrality list; the second is the monetization modules they are forbidden to reach. No name may appear in both.For AI agents and procurement-software vendors who want to query Vannus programmatically: the same attestation is served as JSON at /.well-known/neutrality.json and /api/neutrality/status, and the methodology is published; the enforcing test is in the private source repository and is provided on request for review, as above. The attestation names modules, not numbers.
If you are answering a data-processing agreement, a security questionnaire, or a transfer impact assessment, the question you are stuck on is usually the same one: which legal entity do we actually contract with, and whose law governs it? Vannus publishes a connector so an AI assistant can read our answer for a named vendor, and the method behind it, rather than paraphrasing either from a marketing page.
The manifest lives at /mcp/v0. It is plain JSON and describes itself — open it in a browser and it will tell you what it is for and what it refuses to do.
What it answers today. Two tools. vannus.get_determination looks up one catalog vendor by name and returns its determination: the entity a customer contracts with, its country, the governing law, what the record establishes about US corporate control and who claims it, and the source document and the date it was read. It is the same object /determination/{name} serves, which each assessed vendor’s tool page links as data. vannus.get_methodology returns how a contracting entity is established, what counts as evidence, and a link to the live attestation above.
What it does not answer. It does not quote the clause a finding rests on; the report does, where the record holds a clause it can quote. Where the record does not establish something, the answer says so.
What it will never answer. Which tool to buy. Vannus does not rank vendors or recommend replacements; it reports what vendors publish about who controls them, quoted and dated, and says “not disclosed” where they publish nothing. A connector that returned a shortlist would be a different company’s product.
Structural neutrality is a claim about the source dependencies of the modules on the neutrality list. It is a strong claim, but it is not every claim Vannus makes.
What it claims is narrow: the listed modules cannot reach the code that knows about partnerships, so a partnership cannot change what they compute from a record. Whether a person let one shape the record itself is a question the test does not answer; the last line above says what a reader can check instead.
Apart from the check above, Vannus holds itself to three rules about partner programs. The partners page publishes them with both dates on every partner card, so the second can be checked:
Neutrality is about partnerships. There is a second and larger objection, and it is the one a careful buyer raises first: Vannus is a United States company selling analysis of United States legal reach. The CLOUD Act reaches a provider subject to US jurisdiction over data in its possession — which includes us. We are not an exception to the thing we report on, and no argument makes us one.
So we publish our own entry, produced by the same code that produces every other entry, with the same evidence gate on every field and nothing adjusted because it is us. The entry records that Vannus contracts through PRAXIS AI LLC, a United States company, and is therefore within reach of US legal process — the same finding we publish about any US vendor. Alongside it is everything Vannus holds about you, how long we hold it, and how to make us delete it.
Implementation lives in praxis/neutrality_attestation.py and is enforced by the test at praxis/tests/test_neutrality_invariant.py. The check re-runs on every build, against the current state of the source tree.