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 "keep / replace / drop" recommendation 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 grade 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 15 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 is part of the public build, so an auditor can re-run it against our published methodology rather than taking our word for it.
Three checks any technically-minded reader can perform without leaving this page:
scoring_imports_monetization field is false.For AI agents and procurement-software vendors who want to query Vannus programmatically: the methodology and the enforcing test are published in the source tree.
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.
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.