Skip to content

'Cite this result' button, version badge, and shareable TRO permalinks #2830

@MaxGhenis

Description

@MaxGhenis

Context

Today's meeting with Lars Vilhuber (AEA Data Editor), Tara Watson, John Sabelhaus, and the TRACE team (Tim Clark, Casper) landed on this framing: policyengine.org is the primary TRACE surface for us. When a researcher runs a simulation on policyengine.org, the institution (PolicyEngine) certifies the run on their behalf. The researcher / reader / reviewer of any paper that cites the result can verify it without having to re-run the simulation themselves, because the TRO binds all the inputs and outputs by SHA-256 and carries a PolicyEngine-side attestation.

The backend emission is scoped in PolicyEngine/policyengine-api#3485. This issue is the user-facing side.

What to build

Once the api emits a TRO URL alongside every simulation result, the app should expose it as a first-class citation surface. Three specific UI elements:

1. "Cite this result" button

Lives on every simulation result page (household impact, reform economy-wide impact, geographic impact, policy charts, etc.).

Clicking it:

  • Opens a panel with a citation block — BibTeX / Chicago / APA formatted — that references the TRO URL as the persistent identifier
  • Offers a "Download TRACE TRO" action → downloads the .trace.tro.jsonld
  • Offers a "Copy permalink" action → copies a policyengine.org/{country}/trace/{tro-id} URL
  • Shows the verification snippet: policyengine trace-tro-validate path/to/trace.tro.jsonld

2. Version badge on every result

Small, always-visible, somewhere in the result header / footer. Reads:

rules us@1.653.3 · data enhanced_cps_2024.h5@1.78.2 · h5 sha256:a4f2...

Hover / click shows the full DataReleaseManifest fingerprint and links to the TRO. This is the most important single feature from Lars's / Tara's perspective: it makes the "rules changed vs data changed" question answerable at a glance.

3. Shareable TRO permalinks

Requirement: a result URL, when shared, should resolve to a page that renders the same numbers forever — even after we publish new models or new calibrated data. This means the result page must either:

  • Store the TRO-ID in the URL and re-render by replaying the pinned bundle, or
  • Store the result payload itself and render it without re-simulating

Either is acceptable; the former is more rigorous because it proves reproducibility on every load. Interaction with the existing session URL / share-link machinery is TBD (this is probably the biggest UX decision inside this issue).

Out of scope for this issue (follow-ups)

  • "Replicate in Colab" button: the TRO contains the pip install line. A button that opens a Colab notebook with pip install policyengine==X policyengine-{country}==Y policyengine-{country}-data==Z + the reform JSON pre-filled is a natural extension. Worth its own issue once the cite button ships.
  • Diff view: "this result moved from $X to $Y between model release A and model release B — here's what changed in rules and here's what changed in data." Tara's user test for the whole architecture. Follow-up.
  • In-app TRO validator: paste a TRO, see what it binds + whether the hashes still resolve. Follow-up.

Dependencies

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions