Almost every research group, department, and editorial office has its own “expert roster.” Its starting point is usually casual: jot down a few names during a meeting, get a few recommendations from senior colleagues, save a few entries while browsing papers. Only when using it do the problems surface—the affiliations in the list are still from five years ago, some people have long since moved elsewhere, and some entries contain only a name with no idea where it was copied from.
What this document wants to say is: it is easy to accumulate a list; the hard part is keeping it usable two years later. MuchSci’s talent profile tool is, in essence, establishing rules for this matter.
01 From a pile of names to an asset takes five steps
First, break down the governance workflow.
▲ Figure 1 | Step 5 is the easiest to overlook, and also the most critical
Setting inclusion criteria is the first step, and also the easiest to skip. Which records count and which can only serve as leads must be written down upfront. Without this step, later verification has no basis—you will keep struggling with “does this one count or not.”
Item-by-item verification and flagging uncertainties are a paired set. Verification is done by cross-checking three sources: name, affiliation, and career history against public information item by item; those that do not match are not forced into the list but placed in the“Pending Verification”area. The existence of this “Pending Verification” area is the most restrained part of the whole mechanism—it acknowledges that it will be uncertain, and places uncertain items separately so they do not contaminate the formal roster.
Classification and archiving determine usability. Group by discipline, affiliation, and title, and retrieve the type of expert needed by dimension. Periodic review sits at the end of this chain and is also the easiest step to overlook: affiliations change, positions change, research directions change. If a three-year-old list is used without review, it will go wrong very naturally—and the errors will go unnoticed.
02 A naturally accumulated list vs. a governed list
The names on the two may be exactly the same, but whether you can use them with confidence is very different.
▲ Figure 2 | The difference is not how much was collected, but whether each entry can explain “why it is here”
A naturally accumulated list cannot answer “why.” If you ask “why are these three people here,” the answer is “someone seemed to mention them at the time.” Such a list may work for small internal use, but once it must be reported to superiors, handed to editors, or used in formal processes, it cannot provide an answer.
In a governed list, every entry comes with its supporting context. The basis for inclusion is stated, information granularity reaches the field level, sources can be traced back, and review times are recorded. When asked “why recommend this person,” you can point to specific fields: does the research area match, is the project they led in this direction, and when was the affiliation information verified.
The most practical difference shows at the moment an error occurs. Errors in a list are not scary; what is scary is being unable to explain the basis when an error occurs. Even if an entry in a governed list later turns out to be wrong, you can still explain what it was judged on at the time; if a naturally accumulated list has an error, you can only admit that “it was jotted down casually at the time.”
03 A long-term usable database has three layers
Mixing information with different degrees of certainty together is the root cause of a list quickly becoming messy.
▲ Figure 3 | Three layers separated, each with its own role
The formal profile layer is the part that has passed all verification and can be used externally: all four types of fields are complete, sources are marked, and the review time is still within the validity period. This layer is the part that can be taken out directly.
The pending verification layer contains records with mismatched information or unclear sources—same-name cases to be distinguished, conflicting affiliation information, single sources. They are not useless; they simply cannot count yet. Keep them separately and promote them later when more materials are available.
The observation lead layer is the lightest and exists only as leads: conference speakers, paper collaborators, project participants. The significance of this layer is to expand the search scope—when you need to find people in a certain direction, expanding outward from here is far more effective than thinking up names from scratch.
The biggest benefit of separating the three layers is: when the list needs to be expanded, filter downward from the third layer, rather than mixing uncertain information directly into the formal profile.
04 Interface: the profile header states the rules upfront
Back to the tool itself, let’s see how these rules are implemented in the interface.
▲ Figure 4 | At the very top of the profile, the inclusion scope and matching requirements are stated, as well as how “pending verification is not counted as an expert” is handled
The explanatory text at the very top of the interface is the “inclusion criteria” mentioned earlier in its public version: only national-level projects are included, and the name, affiliation, and career history must exactly match public information; those that do not meet the criteria are marked “Pending Verification” and not counted as experts. By writing the rules in the header, when users receive a profile, they can tell at first glance what standard it was organized by.
Looking further down at how the fields are organized:
▲ Figure 5 | Employment history and research outputs are both presented in tables, and each row can be verified separately
It is worth noting that this structure contains nothing like “score,” “match rate,” or “recommendation index.” There are only time, affiliation, position, specialty, and results—fields that can be verified by external materials. This restraint is intentional: MuchSci makes it responsible only for organizing the verifiable parts neatly; whether to use this person, and where, is the user’s judgment.
05 Boundaries
① This article discusses the mechanism of roster governance and does not constitute a promise of results. The completeness of a roster depends on the availability of public information. The inclusion scope is limited and does not mean it can cover all experts in a field.
② Structured does not equal evaluated. Profiles are an organization of public information and do not constitute an evaluation of anyone’s ability, recommendation, or endorsement; every entry in the roster is only a lead to be confirmed, and judgments involving specific individuals must be independently verified by the user, who bears the responsibility.
③ For formal processes, the relevant regulations prevail. Uses such as review, recruitment, and due diligence involve confidentiality, conflict-of-interest, and procedural requirements, and must follow the current regulations of the relevant institution; all materials use only public information and do not involve personal privacy data.