Contributor scores & consent

You can see how the contributors on your chain are doing overall - enough to know who’s reliable - without ever seeing the granular “who answered what,” and without HumanChain exposing its internal ranking of people. Identity in this view is gated on the contributor’s consent.

The scores view

curl https://hub.example.com/api/chains/<chain_id>/contributor-scores \
  -H "Authorization: Bearer <your master key>"

Returns one row per active contributor:

{
  "chain_id": "…",
  "contributors": [
    {
      "display_name": "kashmira@example.com",
      "named": true,
      "consults_reviewed": 18,
      "marked_correct": 16,
      "accuracy": 0.89,
      "track_record_established": true
    },
    {
      "display_name": "Contributor 7a3f",
      "named": false,
      "consults_reviewed": 12,
      "marked_correct": 9,
      "accuracy": 0.75,
      "track_record_established": true
    }
  ]
}

Each row is a contributor’s own outcome history, summarised: how many of their answers you’ve reviewed, how many you marked correct, the resulting accuracy, and whether they’ve answered enough outcome-marked consults for that record to be considered established.

Note

These numbers are just your own verdicts, aggregated back to you - the outcomes you marked. They are not HumanChain’s internal expertise ranking, which stays concealed from everyone, including you. There is deliberately no percentile, no score-of-the-person, and no “who answered which question how.”

Identity is consent-gated

By default, the scores view shows each contributor as a stable, opaque pseudonym - "Contributor 7a3f". Same person, same label over time, so you can watch a contributor’s standing improve without learning who they are.

A contributor is shown by name only if they’ve opted in (named: true). The default is off - privacy first.

This is the whole point of the design: you get the signal you need to run a reliable chain (who’s accurate, who’s establishing a record) while a contributor who hasn’t consented keeps their identity private, even from you.

How a contributor consents

The contributor controls their own consent, per chain:

# A contributor opts in to being named to THIS chain's owner
curl -X PUT \
  "https://hub.example.com/api/dabba/<human_id>/chains/<chain_id>/perf-consent" \
  -H "Authorization: Bearer <contributor token>" \
  -H "Content-Type: application/json" \
  -d '{"visible": true}'

Only the contributor themselves can set this (the token must match the human_id). Setting it back to false returns them to a pseudonym.

Tip

Consent here governs the scores view only. It is independent of transcript visibility: a contributor can answer anonymously in transcripts yet still let you see their name against their performance, or stay fully private in both. Two separate controls, by design.

What the contributor sees about themselves

Every contributor has their own performance view - their answers submitted, how many you reviewed, how many were correct, their accuracy, and whether their track record is established:

curl https://hub.example.com/api/dabba/<human_id>/performance \
  -H "Authorization: Bearer <contributor token>"

It shows them only their own data, and - like your view - never any internal score. So both sides see the same honest, outcome-based picture: you in aggregate, they about themselves.