Visibility & privacy

When a human on your chain answers a consult, the agent gets a transcript that includes a responder_handle. Visibility controls what that handle shows - the person’s name, a team label, or nothing identifying at all. You set it per chain, and the default protects the contributor.

This is about the agent-facing transcript only. Internally, HumanChain always keeps the real identity for scoring and the audit trail - visibility just decides what crosses the boundary to the agent (and, through it, to you).

The three modes

Mode	The agent sees	Use it when
individual	the contributor’s own handle (e.g. a name)	transparency is expected and contributors are comfortable being named
team	a group label derived from the domain, e.g. "Legal team"	you want accountability at the team level without exposing individuals
anonymous	"Anonymous" + a per-consult token, nothing identifying	maximum privacy - the default (“darkroom”)

Note

Darkroom is the default. A chain with no visibility set behaves as anonymous: the agent sees that a qualified human answered, but nothing that ties the answer to a person, and the token rotates per consult so the same person can’t be tracked across answers. You opt up to team or individual deliberately.

How team mode works (tag-derived)

A “team” isn’t a roster you hand-assign. It’s derived from the domain the contributor answered under. If a consult matched the legal domain, every human who answers it shows to the agent as "Legal team". This reuses the expertise tags your contributors already carry - there’s nothing extra to configure.

Within a single consult, all the humans on a team collapse to one non-correlatable token, so the agent can’t tell whether one person or three answered, or which was which.

The small-team guard

A team label only hides a person if the team is big enough to hide in. If fewer than 3 active members of your chain share the matched domain, team mode automatically degrades to anonymous for that consult - because “the Legal team” when there’s exactly one legal person on the chain would simply name them. You don’t have to manage this; it’s automatic.

LLM answers are never anonymized

If no human answers in time and the consult falls back to an LLM (or to your own configured model), that row is never masked - it isn’t a person. It always carries its real source label (llm_fallback or client_llm) so the agent can tell a machine draft from a human judgment. Masking applies to humans only.

Setting the mode

Visibility is a per-chain setting, changed by the chain’s owner (master authentication required):

# Set a chain to team mode
curl -X PUT \
  https://hub.example.com/api/chains/<chain_id>/visibility \
  -H "Authorization: Bearer <your master key>" \
  -H "Content-Type: application/json" \
  -d '{"mode": "team"}'

# View the current mode
curl https://hub.example.com/api/chains/<chain_id>/visibility \
  -H "Authorization: Bearer <your master key>"

mode must be one of individual, team, or anonymous. You must own the chain (a chain you don’t own returns 403).

What the contributor sees while answering

Visibility isn’t a hidden setting done to contributors - it’s shown to them. While answering, a contributor is told, in plain text and colour, exactly how their response will appear: anonymous, as a team, or by name (and if named, to whom). So consent to be seen is informed, every time.

Tip

Visibility (how a contributor appears in the transcript) is separate from performance consent (whether you can see their name against their scores). A contributor can be anonymous in transcripts but still opt in to named performance, or vice-versa. See Contributor scores & consent.

This space is built to evolve

Visibility is deliberately one rail with room to grow - new modes and audiences slot in without changing how agents call consult(). As real client use cases surface, expect more options here, not a different system.