Hi — falsify author here. I built a small bridge for hud and I'd rather show it than describe it: examples/hud — runs offline, pip install hud falsify, no account needed.
What it does, in one sentence: hud's Job is the receipt of the run; this adds a receipt of the bar — the reward threshold, the task (content-hashed over your own Task model) and the verifier slug, committed to a SHA-256 before any rollout, so none of them can be quietly adjusted after the rewards are known.
The adversarial case in the demo is the one I think matters for RL environments: the verifier is swapped after the rewards come back. The Job alone cannot catch that — nothing in the run receipt says which bar it was supposed to be graded against. The locked manifest exits TAMPERED.
Two things I deliberately reused from your design: Task being pure data means the identity side needs no API key, and your args-digest slugs already do half the disambiguation work — the bridge just content-addresses the full definition on top.
This is opt-in and external; nothing is needed from hud's side for it to work. The question I'd genuinely like your read on: for leaderboard-style tasksets (your columns facets), is "the bar was locked before the rollouts" something your users ask for — or does the platform's own audit trail already answer it for them? If the former ever becomes native, the spec is CC BY 4.0 and deliberately not tied to us.
Hi — falsify author here. I built a small bridge for hud and I'd rather show it than describe it: examples/hud — runs offline,
pip install hud falsify, no account needed.What it does, in one sentence: hud's Job is the receipt of the run; this adds a receipt of the bar — the reward threshold, the task (content-hashed over your own
Taskmodel) and the verifier slug, committed to a SHA-256 before any rollout, so none of them can be quietly adjusted after the rewards are known.The adversarial case in the demo is the one I think matters for RL environments: the verifier is swapped after the rewards come back. The Job alone cannot catch that — nothing in the run receipt says which bar it was supposed to be graded against. The locked manifest exits
TAMPERED.Two things I deliberately reused from your design:
Taskbeing pure data means the identity side needs no API key, and your args-digest slugs already do half the disambiguation work — the bridge just content-addresses the full definition on top.This is opt-in and external; nothing is needed from hud's side for it to work. The question I'd genuinely like your read on: for leaderboard-style tasksets (your
columnsfacets), is "the bar was locked before the rollouts" something your users ask for — or does the platform's own audit trail already answer it for them? If the former ever becomes native, the spec is CC BY 4.0 and deliberately not tied to us.