Trust model
How scores are produced and what they mean.
Nipcode returns two integers per recommendation: decision_score and trust_score. Both are 0-100. Both come from the same structured LLM ranking step over source-owned evidence.
Score bands
| Score | Decision | Agent behavior |
|---|---|---|
| 75-100 | recommended | Present with its install plan and approval boundary. |
| 50-74 | usable_with_warning | Show warnings clearly before user decides. |
| 0-49 | unknown / avoid | Do not execute by default. |
A package can only be marked recommended: true when decision_score >= 70 AND risk_level != "high". Popularity alone never makes a package recommended.
Signals consumed
The ranking step sees source-owned metadata only:
license. SPDX identifier if declaredmaintainerscount and recent activity- release recency and version sanity
- registry-native quality / download counts (ranking weight only)
- repo link present and resolving
- description (first 160 chars, truncated to avoid prompt injection)
Signals explicitly NOT consumed: README body content, model card text, MCP descriptions, anything caller-supplied about the package.
Trust flags
Hard signals that always populate the trust.flags array:
no_license_declaredno_maintainers_listedlow_quality_score(npm only, score < 0.2)low_repo_stars(github only, < 5)package_deprecatedlatest_version_yankedrepository_archivedinstall_scripts_presentvery_deep_dependency_tree(> 200 deps)not_updated_in_2_years
Heuristic fallback
If the LLM ranker is unavailable (provider outage, configuration missing), Nipcode falls back to a heuristic ranker that maps the trust-flag count onto the same band system.
The fallback path is never marked recommended: true. The highest level it returns is review_caution. Agents that depend on Nipcode for safety should treat fallback responses as lower confidence.