Core concepts

Three ideas shape how Prosopia handles access and visibility. Understanding them makes the rest of the documentation straightforward.

Identity: the ORCID iD is the proof

A profile is keyed on a canonical ORCID iD. When you log in with ORCID and your iD matches a profile’s, the match is the proof of ownership — no operator approval, no challenge. This is why claiming is self-verifying.

Two login providers are supported: ORCID (the primary path — its subject is the ORCID iD, so only an ORCID login can self-claim) and Google OIDC (can be added to a profile’s access list, but cannot self-claim because it carries no ORCID iD).

Ownership and access

Each profile has one owner and one access list:

Ownership: one owner per profile, written in the same transaction that creates or claims it, so there is never a moment when a profile exists but nobody owns it. A profile nobody has claimed is owned by the platform.
The access list says who else may do what with this profile. Each entry names a person, a team, or an app, with one role:
- Reader: reads the parts you pick, beyond what the public sees.
- Editor: edits the content and pushes updates. Cannot publish, delete, or change the list.
- Co-owner: everything the owner may do except hand the profile over.
You add a person by ORCID iD or by email. An email nobody has signed in with yet waits as an invite until someone signs in with that verified email. Only the owner (or a member of the owning team) and co-owners change the list; editors can see it. A person, team, or app may also ask for a role, and the owner or a co-owner approves or denies it.
API keys you make act for you. A key gets your access to each profile, capped part by part by the key’s own list. See Visibility below.

When you reach a profile in more than one way (yourself and a team you are in), the strongest role counts.

A team is a named set of people. It has one layer: everyone in a team holds the team’s access equally, and a team admin can only manage the team (rename it, add and remove people, delete it), which gives no other powers.

A team admin can also add a platform app to a team. An app on a team reaches what the team reaches: the profiles it owns, the profiles shared with it, and its lists. Its key’s scopes decide what it may do there, and writing needs the push scope, so an app whose key may only read cannot change anything. An app is never an admin.

The operator token is deliberately not a principal — it cannot publish, grant, or take ownership.

Curated profiles and collections

A team can keep a profile about someone else, for example a department that keeps profiles of its faculty. This is a curated profile. It is an ordinary profile with one difference: its owner is the team, not the person it is about.

It is never public. Only the owning team and the people, teams, and apps on its access list can read it. It cannot be published.
It makes no identity claims. It cannot claim who the person is (an ORCID iD, a Scholar or OpenAlex id) or say how the profile may be reused (a license or a web address). Only the person’s own profile can do that.
The team can hand it over. An owner sends the person a handover link. When the person accepts, the same profile becomes theirs: nothing is copied, and every list that held it still holds it. The person picks who keeps access, for example the team (as a reader or an editor) and each app that reads it today. If the person already has a profile, the lists point at theirs instead. Claiming an unclaimed profile works the same way: you pick who keeps access.

A collection is a named list of profiles, owned by a person or a team. It can list curated profiles and people’s own profiles side by side.

A list grants nothing. What you see of each profile on it is your own access to that profile. If a person keeps their own profile and has not given your team access, the list shows you only what the public sees, and you can ask them for access.
The owner decides who may see or edit the list. On the collection’s Access tab, a person or a team gets Viewer (sees the list) or Editor (also adds and removes profiles and edits notes). To let an app read a list, add the app to the team that owns it.
Each entry can carry notes: the list’s own private remarks about that person. Everyone who can see the list sees the notes.

Interest papers

Interest papers are papers that define what you want to work on: papers you admire, build on, or want to work near. They are a separate part of your profile from your publications.

They are never your publications. They do not appear in your publication list, they do not count as papers you wrote, and they are never used to write the summary of your own work.
They tune your literature feed and matching. The feed searches near them and ranks new papers against them, and matching uses them too. When you have papers of your own, those always count for more.
Feed upvotes add to them. Upvoting a paper in your feed adds it to your interest papers, never to your publications.
They are private by default. You can share them on the Privacy page, like any other part.

You add them on the Edit page by pasting DOIs or OpenAlex links, or by uploading a BibTeX file, and an assistant connected to your account can add them for you during an interview. They are most useful for someone with few papers of their own, such as a student.

Following

You can follow any published profile, with or without a profile of your own. Your list is private: the person you follow is not told, nothing shows on their profile, and there are no follower counts anywhere. A profile that is unpublished or deleted disappears from your list without a note. Following is for people you sign in as; connected apps and API keys cannot read your list.

Visibility: parts and audiences

There is no single “make this public” toggle. Visibility is decided per part, per audience, on every read.

An audience is whoever is looking: the Public, someone on the profile’s access list (a person, a team, or an app), or one API key.
A part is a section of the profile (Summary, Expertise, Contact, …) or a kind of file (Publication list, Interest papers, Paper full text, CV, Grants, …).
For each part, each audience gets None, Read, or Write (Write includes Read). The Public and readers only get None or Read; editors and co-owners get Write on every part.

Where each audience is set:

The Public is set per profile, on the Privacy page (/privacy). The public reading at least one part is what “published” means. The public reading nothing means the profile is unpublished, and a stranger sees nothing at all.
People, teams, and apps are set per profile, on that profile’s Access tab. An app made a co-owner may also replace the whole profile.
API keys are set once for your whole account, on the Privacy page. One list per key covers every profile your account can reach, and never more than you may do yourself. Every part can be set to Write, and the Everything preset also turns on Replace whole profiles, which hands over total control.

A collection is not an audience. Who may see a list is set on the collection’s Access tab, but seeing a list never lets anyone read more of a profile on it.

Some rules always hold:

You see everything. Owners, co-owners, and editors always see the whole profile. A reader sees the parts you picked.
An app or key never reads less than the public. What the public sees is on the open web anyway.
Only you and your co-owners decide what the public sees. No app or key can publish, unpublish, or change the public’s list.

Signing in is not a privilege. A logged-in person with no role on a profile sees exactly what the open web sees. Access comes from an entry on the profile’s access list (for you, a team you are in, or an app) or a key’s list, never from merely having an account.

Publication is consent, not a content change. It is a separate, recorded, revocable act that only the profile’s owner (or a co-owner) can perform. No ingest path, migration, or bulk import can publish anyone; the schema enforces this structurally. Unpublishing takes the profile off the open web, but it does not black it out: you, everyone on the access list, and the API keys their people allowed keep reading what they were allowed.

Paper full text, CVs, web pages, and the interview digest start hidden from the public. They stay hidden unless you choose to show them.