Enforced by a build test, not a marketing claim.
Vannus's catalog scoring evaluates AI tools against a published methodology. The most load-bearing claim we make about that scoring is that it has 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 scoring engine imports no partnership, affiliate, or monetization module. A test in our continuous-integration pipeline fails the build if that ever changes — so a finding cannot be influenced by 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 scoring stack. It walks every import statement in every module that contributes to tool scoring, follows those imports transitively, and asserts that no module in that import graph reaches any module on the forbidden list.
The test is built into the same source tree as the scoring code. It runs on every change. If anyone — including the founder — ever tries to wire partnership or affiliate data into a scoring module, 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 19 modules. Every module that contributes to tool scoring, trust-badge computation, decay surveillance, recommendation learning, or Concierge audit output is here. Adding scoring functionality without adding the module to this list is itself reviewable.
The forbidden modules exist in the codebase — they handle affiliate URLs and revenue surfaces — but they are structurally walled off from anything that influences a score, a recommendation, or an audit finding.
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. A reviewer cannot accidentally bias a recommendation toward a partnership; the test rejects the change at commit time. A founder cannot quietly favor a partner; the same rejection applies. The test runs on every build, and it is the same file 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, and neither contains any part of the weighting.
Three checks any technically-minded reader can perform without leaving this page:
/.well-known/neutrality.json and confirm scoring_imports_monetization is false.violations is an empty list. Any scoring module that imported a monetization module would be named there, and the build would have failed.scoring_stack against forbidden_modules. The first is every module the scoring engine loads; the second is the monetization modules it is forbidden to touch. 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 and the enforcing test are published in the source tree. The attestation carries no scoring weights — it 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 method for answering that, rather than paraphrasing it 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. Stage 1 exposes one tool, vannus.get_methodology: how a contracting entity is established, what counts as evidence, what “not disclosed” means, and the live attestation above. These are questions about the method.
What it does not answer yet. It does not look up a named vendor. A per-vendor record tool is listed in the manifest as scheduled, and scheduled means not built — it is named there so you can see what is coming, not so you can plan around it. Until it ships, a vendor-specific answer comes from the catalog or a report.
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 scoring engine's source dependencies. It is a strong claim, but it is not every claim Vannus makes.
What it claims is narrow and strong: a partnership relationship cannot influence the score of a tool, because the code that computes scores cannot reach the code that knows about partnerships.
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, scored by the same functions that score the catalog, with the same evidence gate on every field and nothing adjusted because it is us. It grades D. 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.