How trust signals work

What trust signals are

GraphCanon surfaces sourced, dated heuristics to help you compare open-source AI development tools. They are decision inputs, not certifications.

Every trust report names its methodology version, when signals were computed, and what data we actually inspected. We do not ship a composite letter grade or a black-box safety score.

Maintenance (`github_public_v1`)

Maintenance posture is derived from public GitHub repository metadata refreshed on ingest and on scheduled GitHub sync. The label and percentage signal reflect recency of activity, not code quality or security.

• Archived on GitHub → label Archived (repos marked archived are treated as unmaintained by definition).
• No `pushed_at` timestamp → label Unknown.
• Last push within 7 days → Very active; within 30 days → Active; within 90 days → Steady; within 365 days → Slowing; older → Dormant.
• When metric history exists, we also store 30-day deltas for stars and open issues alongside the push recency signal.
• Discovery surfaces may show the persisted label or the same heuristic when trust metadata has not been computed yet.

Provenance (`github_public_v1`)

Provenance fields identify the upstream repository and basic lineage from GitHub's public API. They help spot forks and account type; they do not verify maintainer identity or organizational endorsement.

• `github_id` - stable numeric id for the repository on GitHub.
• `is_fork` and `parent_repo` - whether the catalog entry points at a fork and, when known, the parent `owner/repo`.
• `owner_type` - GitHub account class (`Organization` vs `User`) when returned by the API.
• `computed_at` - ISO timestamp when these fields were last merged into stored trust metadata.

Security scans (Phase 2 - dependency advisories)

When enabled for a tool, security status comes from an automated dependency advisory lookup against lockfiles present in the default branch. This is intentionally narrow: known CVEs in declared dependencies, not a review of application code.

If no supported lockfile is found, status is No lockfile and we do not infer a clean bill of health.

• Scanner: OSV (`osv@v1`) batch queries against declared package versions.
• Lockfiles tried (up to three per repo): `package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `requirements.txt`, `go.sum`.
• At most 150 unique package coordinates are queried per scan to bound cost and latency.
• Findings list severity, advisory title, package coordinate, and CVE alias when OSV provides one.
• A status of No criticals means no critical-severity advisories matched scanned packages on the scan date - not that the project is secure.

What we never claim

Trust signals must not be read as warranties. GraphCanon does not run penetration tests, code audits, or maintainer background checks.

• We do not claim a tool is safe, production-ready, or verified secure.
• We do not claim pen-test coverage, SOC 2 compliance, or supply-chain certification.
• We do not endorse maintainers, organizations, or downstream use in regulated environments.
• Absence of findings in a dependency scan is not proof of absence of vulnerabilities (unscanned lockfiles, private deps, runtime-only risk, etc.).
• Maintenance labels describe GitHub activity heuristics, not whether you should adopt the software.

Freshness and limits

Trust metadata is recomputed when a tool is ingested or synced from GitHub. Security scans run on that same cadence when the scanner is enabled for the corpus.

GitHub facts can lag reality (force-pushes, mirror delays, archived state changes). Always confirm critical decisions against the live repository and your own security process.