When organizing an event, the guest list is often the first thing started and the last thing finalized. The host drafts a version first, the co-organizer adds a few people, the event logistics team revises last year's spreadsheet, and the communications team copies another version from chat records. As the send date approaches, several lists are circulating at the same time. Everyone sees a different version, and no one dares to confirm whether the copy in hand is the latest.
The difficulty usually isn't in "not being able to think of whom to invite", whether a particular person is suitable is roughly known within the circle. The real trouble is that this list has to circulate among several people. Each hand adds something and changes the wording, yet the added items have no source, and the reasons for changes are not recorded. So the list should not be a roster of "who appears in whose memory." It should be a structured list in which every entry can point back to a public source and is marked with its verification status.
01 Four filters, and machines can help with the first three
▲ Figure 1 | The direction, fact, conflict, and confirmation filters tighten in sequence; the confirmation filter is completed by people
The direction filter comes first: what is the theme and scope of topics for this meeting, and which directions must the list cover? If this one fails, the later checks are wasted no matter how detailed they are—if the direction is off, completeness is meaningless.
The fact filter governs how things are written. The characters used in names, organization names, job titles, and publicly verifiable representative work are aligned item by item to public pages. Machines can help a great deal with this step: gathering public records scattered across sources by field and laying out inconsistencies side by side.
The conflict filter handles mismatches: whether records with the same name refer to the same person, whether organization information is inconsistent across different pages, and whether the public timeline of a job title connects. Such content is not adjudicated; it is flagged as is.
The confirmation filter is the only one that must be completed by a person. Whether a person on the list can be invited, in what capacity, and to what extent—these judgments cannot be inferred from public materials, and no tool can do them for you. The first three get the materials to the point where they are "one confirmation away"; the fourth is done by a person.
02 Patchwork lists vs. structured lists: the difference shows after the list changes hands
▲ Figure 2 | The two lists look similar right after they are compiled; the difference emerges after they change hands
When first compiled, the two lists are similar in length. The difference only becomes exposed after two handoffs.
A patchwork list has these characteristics: entries have no unified fields, some include an organization while others have only a name; sources rely on memory; there is no record of who added an entry or why; edits directly overwrite the original text, making it impossible to see what the previous version said. This kind of list works in one person's hands, but once it changes hands it starts to lose fidelity, and the next person neither dares to delete nor use it.
A structured list has fixed fields for every entry, sources that point back to specific pages, a separate column for verification status, and an audit trail for changes. The next person does not need to go back and ask the previous owner; by looking at the list itself, they know which entries can be used directly and which still need a confirmation.
The difference isn't in how neat it is, but in how much information remains after it changes hands. The former relies on verbal explanation during handoff; the latter relies on the list's own structure.
03 Three tiers so the next person knows how to proceed
▲ Figure 3 | The tiers are based on verification status, not importance or invitation order
The most common misunderstanding about tiering is treating it as a queue: important ones first, secondary ones later. Tiers divided this way are useless to the next person.
Tiering can only be based on verification status. Verified and ready to use: complete fields, clear source, and a second source that matches. Pending verification and needing completion: the direction is suitable but key fields are still missing, or only a single source has been found. Excluded and not included: the direction doesn't match, or the source is not within the public scope.
The purpose of this division isn't classification itself, but that each tier corresponds to a clear action: tier one can enter the letter-sending process; tier two must have fields completed before a decision; tier three must be removed with a record—clearly state the basis for exclusion to avoid being added back later. Tiering isn't for appearance; it's so that someone who wasn't involved in the earlier compilation can continue the work.
▲ Figure 4 | Before formal sending, check item by item: name characters, organization and job title, source, and confirmer
This self-check before formal sending deserves its own table: whether the characters in names match public materials, whether organization and job titles use current forms, whether each source can be traced back, and whether there is a clear confirmer with the result documented.
These items may look trivial, but once something formally sent is wrong, the cost of correcting it is far higher than checking beforehand: what must change isn't just a line of text; letters, agenda, seating arrangements, and communications messaging all have to move with it—and by then the event date is often close.
04 Organizing an event: how to run the list through a review
▲ Figure 5 | Illustrative structure of an invitation list: verification status and source listed side by side, not mixed into notes
In practice, the order is roughly as follows.
Define fields first. Don't rush to think of names; first write down which columns the list needs: name, organization, job title, direction, public source, verification status, confirmer. Once the fields are complete, adding people later is just filling in cells.
Then fill in separately. Check item by item by field, and note the source as you go; don't wait to fill it in later—sources filled in later often can't be completed. At this step, MuchSci handles gathering and archiving: aligning scattered public records by field and listing inconsistencies side by side; it does not decide for you who should be on the list.
Mark the status. As soon as each entry is checked, mark which tier it belongs to; the criteria must be consistent throughout, otherwise tiering loses meaning.
▲ Figure 6 | After four steps: define fields, fill in separately, mark status, keep records
Keep records. For people added, state the basis and source; for people removed, state the reason for exclusion. Changes should not overwrite the original text; add a new line or note nearby. That way, when someone later asks "who added this entry," no one needs to specially recall.
MuchSci's role in this process ends here: gathering public records into a searchable structure so that each entry points back to a source and each status is verifiable. Whom to invite, in what capacity, and how to communicate remain the responsibility of the event organizers.
05 Boundaries
① This article discusses methods for organizing lists and does not constitute a promise of results. No matter how well a list is organized, it cannot guarantee invitation outcomes, let alone the success of the meeting itself.
② Organizing a list does not constitute an evaluation or endorsement of any person. The structures and examples in this article are illustrative only; formal invitations must be subject to confirmation by the individual or their organization.
③ Organization is conducted only within the scope of public materials. Information obtained through non-public channels and unverified secondhand accounts are not included in the list; when the list is used for formal purposes, applicable regulations prevail.