Structural Neutrality

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 neutrality methodology

Enforced in the build

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 that ever changes — so none of those modules can reach 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.


What the neutrality check actually proves

A separate Python test — praxis/tests/test_neutrality_invariant.py — performs static analysis on the source code of the modules on the neutrality list (the scoring stack below). It walks every import statement in every one of those modules, follows those imports transitively, 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, 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.


What's in scope

The check covers the following 19 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.

Scoring stack

  • praxis.concierge.deliverable
  • praxis.concierge.ingest
  • praxis.concierge.intake
  • praxis.concierge.narrative
  • praxis.concierge.outcomes
  • praxis.concierge.pipeline
  • praxis.concierge.scoring
  • praxis.engine
  • praxis.feedback
  • praxis.feedback_db
  • praxis.learning
  • praxis.model_trust_decay
  • praxis.scoring_optimized
  • praxis.sovereignty
  • praxis.trust_badges
  • praxis.trust_decay
  • praxis.vendor_trust
  • praxis.verification
  • praxis.weights_default

Forbidden in the import graph

  • praxis.affiliates
  • praxis.monetise

The forbidden modules exist in the codebase — they handle affiliate URLs and revenue surfaces — but no module on the list above reaches them, directly or through another import.


Why this is the claim Vannus chose to enforce

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, 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.

How to check it yourself

Three checks any technically-minded reader can perform without leaving this page:

  1. Open /.well-known/neutrality.json and confirm scoring_imports_monetization is false.
  2. Confirm violations is an empty list. Any module on the list that imported a monetization module would be named there, and the build would have failed.
  3. Compare scoring_stack 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 and the enforcing test are published in the source tree. The attestation names modules, not numbers.


Reading this from an assistant (MCP)

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.


What this does not claim

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 and strong: a partnership relationship cannot influence what the listed modules produce about a tool, because they cannot reach the code that knows about partnerships.


The objection this page does not answer

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.

Read Vannus on Vannus →


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.