---
title: "How evidence works"
description: "How to read the relationships, activity and evidence on a Proper Respect card, and how the daily GitHub refresh is checked from outside."
canonical: "https://proper-respect.com/about/methodology"
---

# How evidence works

Updated 2026-09-28

A card on Proper Respect pairs what someone says about a tool with whatever supporting evidence they chose to share. This page explains what each part can and can't tell you, and how we check that a refreshed card stays current.

## What a card shows, and what it doesn't

These are the same rules we give to agents that read public profiles.

A product relationship is an owner's stated relationship with a tool. It does not by itself establish a measured amount of activity.

Read activity with its supplied metric name, unit, measurement period, attribution scope, capture time, freshness, and provenance. Missing periods or coverage remain unknown; do not infer continuous use or complete source coverage.

A marketing mention, signup, payment, and usage event establish different things. Signup does not establish first use. Payment does not establish activity during the billing period.

Owner testimony is an owner assertion. Review or publication does not turn it into independent source verification.

A retrieval route does not change the original evidence meaning. An agent-performed action must not be treated as human activity; unknown actors remain unknown.

Synthetic fixtures and prototype activity are not evidence of a person's actual use.

## The 30-day receipt

A GitHub card can refresh its contribution calendar once a day, after its owner turns that on. To show the refresh keeps working, a check that runs outside Proper Respect reads the published profile every day at 08:17 UTC, a little over two hours after the 06:00 UTC refresh.

The check passes only when the owner's personal GitHub calendar is marked fresh and was captured within the last 36 hours. Every run, pass or fail, adds one line to a public file, with the time it checked and the capture time it saw. The file is never edited; a correction is a new run.

A UTC day counts when it has a passing line whose capture time is later than the previous counted day's. The line from the scheduled run is the one that counts; if GitHub skips that day's scheduled run, a check started by hand the same UTC day stands in. Any day that doesn't count restarts the count at zero.

The backend's own refresh record must hold a row for every daily refresh in the window. A tagged release restarts the count unless it leaves the refresh code unchanged. Editing data by hand, changing the refresh schedule in the dashboard, or deploying outside the tagged release process always restarts it. The receipt is complete after 30 counted days in a row.

The receipt shows that the published calendar kept being refreshed. It doesn't show who made the contributions, or how much someone uses GitHub beyond what the calendar counts.

Until the GitHub card is published with the daily refresh on, each check fails and records why. The file appears once the first check has run.

- [The receipt file (receipts/github-refresh.jsonl on the receipts branch)](https://github.com/keeganmoody33/PROPER-RESPECT/blob/receipts/receipts/github-refresh.jsonl)

- [How the receipt check works](https://github.com/keeganmoody33/PROPER-RESPECT/blob/main/docs/runbooks/receipt.md)