Research & records

Sharing & the leaderboard

You can publish a run to the community leaderboard — but not on the strength of its equity curve. Publication requires audit evidence, and the board ranks by that evidence, never by raw return. This page covers the publish checklist, how the ranking works, what happens to flagged runs, and exactly what does and doesn't leave your account.

The publish checklist

Open a run → the Gates tab → the Publish to leaderboard panel. A pre-flight checklist shows each requirement as a ✓/✗ line with its one-click fix — all green enables Publish, and nothing is ever silently blocked:

  • A deep-audited verdict. The run must carry a deep audit — the full simulation battery, not just the quick pass. Why: readers need robustness evidence, not just an equity curve. The fix is one click: Run deep audit (~4 min).
  • Sensitivity and walk-forward coverage present in that deep verdict. Why: a result that hasn't been probed for cost sensitivity and out-of-window degradation is a picture, not evidence. (A check that structurally can't apply to the run never blocks you — the gate is about evidence that could exist, existing.)
  • A hypothesis, for builder-originated runs. A run from an AI-drafted strategy spec must publish with the falsifiable hypothesis on its approved brief. The newest approval decides, so approving a brief that drops the hypothesis blocks publishing until you add one back. A one-click variation publishes on its base version's hypothesis: a variation has no brief of its own — it was approved as part of the base's batch — so the gate reads the base's newest approved brief, and if that brief carries no hypothesis the blocked line links to the base version's brief page, which is the only page whose Approve button can clear it. Runs from AI-assisted workspace code are a different shape, and which way they go is up to you. Unless someone has linked that workspace to a strategy (Link strategy on the workspace row), the workspace has no strategy and so no brief page a hypothesis could be saved on — those runs are exempt, and the checklist line says so in plain words instead of blocking you behind a fix that does not exist. That is still what an untouched workspace does. Link one, and publishes from it read the linked strategy's briefs instead, so they can be blocked until one of those briefs carries a hypothesis — and the fix is on that strategy's brief page. Why the requirement at all: readers deserve to know what market behavior the strategy claims to exploit — and what would prove it wrong. Where it applies, the fix links straight to the brief.

Note what is not on the list: a good grade. The gate demands coverage, not outcome — see flagged runs below.

Publishing embeds a snapshot of the latest deep verdict into the entry. Published pages render that stored copy — a later re-score never alters an existing publication; the listing shows a Newer verdict available chip instead, and Update snapshot re-embeds the latest verdict in place (ratings and comments survive; Revoke deletes the entry and its history).

Ranked by audit evidence, never by return

The board's default order is the audit score: verdict tier first (Clean over Partial over Caution over Flagged), then how many checks passed, then the deflated Sharpe probability. Return-shaped metrics never drive the order — ranking by raw return selects for overfitting and luck, which is precisely what the rest of the platform exists to filter out. The board's own empty-state copy sets the culture:

The house rule

“Ranked by audit evidence, not by return. A modest, robust result outranks a spectacular, fragile one.”

Each card shows the audit chip with its score (e.g. ✓ Clean · 14/14 · DSR 97%), the hypothesis, a small equity sparkline, the trials count — how many things were tried to get here — and, once the strategy is journal-linked, its accruing reality verdict: the out-of-sample track record building after publication. Entries published before this gate existed carry an explicit No audit snapshot chip and order after every scored entry.

Flagged runs publish too — flag showing

A run does not need a Clean verdict to publish. A Flagged run with a deep audit meets the gate and appears on the board with its flag rendered prominently — honesty over curation. The alternative, a board of curated winners, would teach exactly the wrong lesson about what research evidence looks like. What the gate refuses is a run with no evidence, never a run with unflattering evidence.

Comments and ratings are user content, and all user content on the platform passes one moderation gate: an admin can pause an account's posting, the pause names its reason to the affected user, and every create-and-edit surface stays paused until the block expires or an admin lifts it. Reading is never blocked.

What leaves your account — and what never does

  • No dollar P&L, ever. Published entries carry a normalized percent-return series indexed to 100 — never a dollar-denominated curve, and no dollar figure anywhere in the payload. If the normalization base isn't available, the card simply renders without a sparkline rather than fabricating a scale.
  • Visibility is scoped. Entries publish to your team or private board; a public tier exists only where the deployment has enabled it — it is not on by default.
  • Revoke is real. Revoking a publication deletes the entry and its social history. (To refresh a listing instead, use Update snapshot — see above.)
  • Your email address is never shown to another user. On the leaderboard you appear as the display handle you chose (or Anonymous), and entry comments carry an opaque member id — neither is derived from your address. Everywhere else in the app that names you to somebody else — a project's member list, the workspaces list, the shared feedback board — you appear as your username if you set one in Settings → Public identity, otherwise as the first part of your address plus a short code (trader1·4f2a) that keeps two people with similar addresses from being mistaken for one another. The domain is never shown. Administrators do see real addresses, because account support runs on them.