How to Turn Event Messages Into Reliable Person-and-Status Records

Nina Okonkwo August 20, 2026

Extracting event attendance status and names from text sounds simple until the input contains statements such as:

“Jordan Lee will not attend.”
“Maya may join the afternoon workshop.”
“Alex checked in, but Priya canceled.”
“Sam registered but never checked in.”
“Taylor said they would come, although the host later marked them absent.”

Finding names is only the first step. A reliable system must determine what each statement asserts, which person it concerns, which event or session it applies to, when the assertion was made, and whether it describes intent or evidence of presence.

The safest architecture treats attendance extraction as evidence linking, not keyword spotting. Four principles guide the design:

Keep invitation, registration, response, check-in, and post-event attendance separate.
Link every status to the correct person, event, session, source, and time.
Preserve raw text and source values alongside normalized fields.
Leave unsupported or ambiguous information unresolved instead of manufacturing certainty.

Define the extraction task before choosing a model

Information extraction converts free-form language into structured entities, relations, events, or schema-compliant records. In an attendance system, the target is not simply a list of names. It is a collection of assertions connecting people, statuses, events, sessions, sources, and times.

Break the task into five independently testable components:

Person-name detection: Locate a span such as “Jordan Lee.”
Attendance-expression detection: Locate language such as “will not attend,” “checked in,” or “may join.”
Person-status linkage: Determine which status belongs to which person.
Event or session linkage: Determine which event, occurrence, or session the assertion concerns.
Identity resolution: Match the extracted mention to an existing person record when the evidence permits it.

These stages fail in different ways. A system might detect every name but attach the wrong status, interpret “canceled” correctly but connect it to the wrong workshop, or extract the correct assertion and then assign it to the wrong contact because two people share a name.

Named entity recognition, or NER, addresses only the first part. A PERSON model can locate “Jordan Lee,” but it cannot by itself determine whether Jordan accepted, declined, registered, checked in, attended, or was absent. Relation or event extraction is needed to connect the person with a status in context. Character offsets can preserve the exact supporting span for later review, as described in this overview of information extraction, NER, relations, events, and structured output.

Event-extraction terminology makes the target more precise:

The event extent is the relevant text span, often a sentence or clause.
The event type identifies the kind of occurrence represented by the schema.
The trigger is the word or phrase that most clearly indicates the occurrence.
The arguments identify participants and details such as time, place, event, or session.

For “Alex checked in to the morning workshop,” the extent may be the full sentence, “checked in” is the trigger, Alex is the participant argument, and “morning workshop” is the session argument. Event detection identifies the extent, type, and trigger; event extraction additionally identifies and classifies the arguments, according to Ontotext’s explanation of event extraction.

An attendance schema can model registration, response, check-in, cancellation, and verified attendance as related event types. It can instead store them as status assertions attached to a person-event relationship. Either design is workable if the distinctions remain explicit.

The central implementation rule is:

A person mentioned near an event is not automatically an attendee.

“Jordan organized the conference but did not attend,” “Maya invited Alex,” and “Contact Priya if Sam is absent” all contain people and event-related language. None supports classifying every named person as attended.

This guide presents an architecture, schema, and evaluation framework. It does not claim that a general NER library, event-extraction product, language model, or vendor export provides a production-ready attendance extractor without configuration, labeled attendance data, and operational controls.

Separate RSVP intent from evidence of actual attendance

Attendance systems often fail because they collapse the event lifecycle into one field. A person can be invited without responding, register and later cancel, accept without appearing, arrive without registering, or attend one session while missing another.

Use separate conceptual dimensions:

Status dimension	Question answered	Example values
Invitation	Was the person invited?	invited, not invited, unknown
Registration	Did the person enter the registration workflow?	registered, waitlisted, canceled
Response	What did the person say they planned to do?	yes, tentative, declined, no response
Check-in	Was an arrival or access action recorded?	checked in, checked out, not checked in
Post-event attendance	What does the final attendance record say?	attended, no-show, absent, unknown

An RSVP-yes, registration, calendar response, or schedule selection records intention or workflow state. It does not establish that the person entered a venue, joined a virtual event, or participated for a meaningful period.

Microsoft, for example, documents Outlook response categories including attending, declined, and no response. Organizers can copy tracking information in a tab-delimited format or download it as CSV in supported workflows. These fields describe invitee responses, not verified presence, as shown in Microsoft’s Outlook attendee-tracking instructions.

Some event systems explicitly separate workflow from attendance. Blackthorn maintains distinct Registration Status and Attendance Status fields. Its documented attendance values are Pending, Attended, and No Show, while registration uses a broader vocabulary that includes invited, registered, declined, canceled, and waitlist-related states. In the documented mobile-app workflow, checking in changes attendance to Attended; a configured post-event process can assign No Show to qualifying records (Blackthorn attendee documentation).

A checked-in attendee export is therefore usually a more direct presence signal than an RSVP. Modern Campus Involve describes its Attendees tab as listing people checked in to an event. Its CSV includes first name, last name, email, and check-in time, with ID numbers included only for users who have sufficient access (event attendee export instructions).

Check-in still has limits. Someone could check in and leave early, join briefly, or be checked in incorrectly. If duration or completion matters, store separate supporting evidence.

Session granularity is equally important. A person may attend the keynote, miss the workshop, and join the reception. Store each assertion against the applicable session_id rather than replacing those facts with one undifferentiated event-level status.

You may derive an event summary for reporting, but its rule must be explicit. Possible policies include:

attended any session;
attended a required session;
attended every scheduled session;
attended a minimum number or duration of sessions.

These are organization-defined aggregation rules, not universal standards. The underlying session records should remain available after a summary is calculated.

Design a canonical status model without erasing the source meaning

Platforms use incompatible vocabularies, so cross-system analysis requires normalization. The following is a design recommendation, not an external standard.

Use a separate enum for each status type:

`status_type`	Core normalized values
`invitation`	`invited`, `not_invited`, `unknown`
`registration`	`registered`, `waitlisted`, `canceled`, `unknown`
`response`	`rsvp_yes`, `tentative`, `declined`, `canceled`, `no_response`, `unknown`
`check_in`	`checked_in`, `checked_out`, `not_checked_in`, `unknown`
`attendance`	`pending`, `attended`, `no_show`, `absent`, `not_expected`, `unknown`

This contract includes the common concepts invited, registered, RSVP-yes, tentative, declined, canceled, checked-in, attended, no-show, absent, not-expected, and unknown without forcing them into one mutually exclusive field.

A person-event relationship can therefore contain all of the following:

registration = registered
response = rsvp_yes
check_in = checked_in
attendance = attended

It can also represent:

registration = registered
response = declined
check_in = unknown
attendance = unknown

The second example should not automatically become absent. A decline is an expression of intent; absence is an affirmative attendance classification requiring separate evidence.

Always preserve both raw_status and normalized_status:

Source value	Status type	Default normalized value	Mapping state
`No Response`	response	`no_response`	mapped
`Attending`	response	`rsvp_yes`	mapped
`Pending`	attendance	`pending`	mapped
`No Show`	attendance	`no_show`	mapped
`Moved`	organization-defined	`unknown`	unresolved
`Not Expected`	attendance	`not_expected`	mapped

A compound source value such as Checked In/Out should not be split unless the source provides enough information to determine the actual state. If separate timestamps or actions exist, emit separate check-in and check-out assertions. Otherwise retain the raw value, normalize to unknown, and mark the mapping unresolved.

Platform-specific mapping is unavoidable. Kaymbu documents Checked In/Out and Moved for staff attendance records, with student exports additionally supporting Absent and Not Expected. Its exports can also contain dates, times, time zones, location identifiers, and the staff member who logged the activity (Kaymbu Attendance Data Export documentation).

Names require the same restraint. Retain:

raw_name: exactly as expressed by the source;
first_name: when provided or confidently parsed;
last_name: when provided or confidently parsed;
display_name: the preferred presentation form;
resolved_person_id: the matched identity, if any.

Do not assume every name can be divided reliably into first and last name. Inputs may contain mononyms, initials, titles, family-name-first ordering, particles, multiple surnames, nicknames, transliterations, or malformed values. Preserve source-provided components when available and retain the original display string even when a parser proposes a split.

A practical assertion record could look like this:

{
  "raw_name": "Jordan Lee",
  "first_name": "Jordan",
  "last_name": "Lee",
  "display_name": "Jordan Lee",
  "resolved_person_id": "person_example",
  "event_id": "event_example",
  "session_id": "afternoon_session",
  "raw_status": "will not attend",
  "status_type": "response",
  "normalized_status": "declined",
  "mapping_state": "mapped",
  "linguistic_features": {
    "negated_trigger": true,
    "modality": "definite",
    "conditional": false
  },
  "evidence_span": {
    "text": "Jordan Lee will not attend",
    "start": 118,
    "end": 149
  },
  "assertion_time": "2026-08-18T14:03:00Z",
  "source_document": "email_example",
  "source_type": "email_reply",
  "extraction_time": "2026-08-18T14:05:11Z",
  "identity_match_method": "normalized_email",
  "confidence": null,
  "confidence_state": "not_calibrated"
}

The identifiers and timestamps above are synthetic examples. The null confidence deliberately avoids implying that an arbitrary score is calibrated for production use.

Linguistic polarity should remain separate from business meaning. In “Jordan will not attend,” the trigger contains grammatical negation, but the system is making a positive business assertion that Jordan’s response is declined.

Missing information must remain explicit:

no stated session: session_id: null;
unresolved person: resolved_person_id: null;
unsupported status: normalized_status: unknown or no status assertion;
unclear mapping: mapping_state: unresolved.

Unknown means the system lacks supported information. Absent and no_show are affirmative classifications and should not be used as substitutes for missing data.

Build a layered extraction pipeline

A production workflow should make every transformation observable. A practical sequence is:

Parse and segment the document.
Detect event and session mentions.
Extract PERSON spans.
Detect attendance and response expressions.
Identify negation, modality, conditions, tense, and quoted history.
Link each status expression to the correct person.
Resolve pronouns and descriptive references when supported.
Normalize the source status.
Match the person mention to an existing record.
Emit the assertion or route it to review.

Parse the source structure

Preserve paragraphs, sentences, list items, table cells, email headers, quoted replies, and character offsets. A current email should not be confused with older text copied into the reply history. In tables, row and column structure may encode relations that a prose model would otherwise need to infer.

Create one canonical text representation and calculate offsets against it. If text is cleaned or transformed, retain a mapping back to the original document.

Detect event and session context

An event may be named directly—“Product Summit 2026”—or supplied by trusted document metadata. A message attached to one registration may already carry an event_id.

Session expressions such as “afternoon workshop,” “day two,” and “the keynote” need independent links. Do not attach a session merely because it is the closest one in a database.

Extract person mentions

The appropriate technique depends on the source:

Gazetteers work well when a known attendee or contact list is available.
Regular expressions suit stable formats such as Last name: Lee.
General NER can find names absent from a supplied list.
Contextual models can help with varied or ambiguous wording.

Rule-based tools can combine exact lists with regular-expression patterns, but status detection and person-status linkage remain separate tasks. The Spark NLP EntityRuler tutorial illustrates list- and regex-based entity detection rather than a complete attendance extractor.

Detect and interpret status expressions

Begin with a domain lexicon containing inflections and multiword phrases:

accept, attending, plans to attend;
might come, may join, tentatively accepted;
decline, cannot attend, will not attend;
canceled, withdrew;
checked in, scanned in, joined;
attended, participated;
did not attend, no-show, absent.

The detector should return a span, candidate status type, and contextual features. It should not immediately issue a final classification.

“Will attend,” “will not attend,” “may attend,” “would attend if travel permits,” and “previously planned to attend” require different records. Relevant features include negation, modality, tense, conditions, reported speech, quotation boundaries, document time, and correction language.

Link people and statuses

Relation or event extraction must determine which participant and status belong together, especially when several people occur in one sentence. Nearest-name proximity can be a candidate feature, but it is unsafe as the sole rule.

Potential linkage features include:

grammatical subject and predicate;
clause boundaries;
conjunctions and contrast markers;
table row and column alignment;
list structure;
event and session compatibility;
discourse continuity.

These are candidate features to validate on attendance-specific labeled data, not a benchmarked guarantee of accuracy.

Preserve offsets, resolve references, and merge mentions

Store start and end offsets for every name, status phrase, event mention, and session mention. Offsets support reproducibility, reviewer interfaces, error analysis, and later reprocessing.

Coreference can connect repeated mentions:

“Jordan Lee registered on Monday. They later said they could not attend.”

If “They” has one well-supported antecedent, the system can connect the second sentence to Jordan. General event-extraction systems similarly describe linking names, pronouns, and descriptive phrases and merging repeated event references (NetOwl event-extraction overview).

If multiple antecedents are plausible, leave the reference unresolved or route it to review. Coreference determines whether textual mentions refer to the same entity; identity resolution determines whether that entity corresponds to a database record. Keep those decisions separate.

Event merging can consolidate “the summit,” “Tuesday’s event,” and “it” into one event object. Do not discard the original mentions or offsets when merging them.

Compare pipeline and joint approaches

If person detection misses a name, later relation extraction cannot link it.

A joint model may learn triggers and arguments together, but it still needs:

an attendance-specific schema;
normalization and conflict rules;
labeled training and evaluation records;
calibrated decision thresholds;
provenance and review controls.

Model architecture does not remove the need to define the task.

A simplified implementation might follow this pattern:

document = parse(source)
contexts = detect_events_and_sessions(document)
people = detect_people(document)
status_spans = detect_status_expressions(document)

for status_span in status_spans:
    features = interpret_context(status_span, document)
    person_link = link_person(status_span, people, contexts)

    if person_link is ambiguous:
        send_to_review(status_span, person_link.candidates)
        continue

    assertion = normalize(
        person=person_link.person,
        status=status_span,
        features=features,
        event_context=contexts
    )

    identity_match = resolve_identity(assertion.person)

    emit(
        assertion=assertion,
        identity=identity_match,
        provenance=document.provenance
    )

This is architectural pseudocode, not a production-ready implementation or validated model.

Handle negation, uncertainty, multiple people, and changing plans

Keyword matching fails most visibly around negation, uncertainty, and time. Treat the following as distinct linguistic conditions:

Definite: “Jordan will attend.”
Negated trigger: “Jordan will not attend.”
Uncertain: “Jordan may attend.”
Conditional: “Jordan will attend if the flight arrives.”
Historical: “Jordan had planned to attend.”
Reported: “Maya said Jordan would attend.”
Corrected: “Ignore my earlier response; Jordan cannot come.”

The normalized status must reflect the complete assertion, not a positive keyword embedded within it.

“Jordan Lee will not attend”

{
  "person": "Jordan Lee",
  "raw_status": "will not attend",
  "status_type": "response",
  "normalized_status": "declined",
  "linguistic_features": {
    "negated_trigger": true,
    "modality": "definite"
  }
}

If Jordan had previously registered and the message explicitly cancels that registration, a separate registration assertion of canceled may also be appropriate. The sentence must never become attended merely because it contains the word “attend.”

“Maya may join the afternoon workshop”

{
  "person": "Maya",
  "session": "afternoon workshop",
  "raw_status": "may join",
  "status_type": "response",
  "normalized_status": "tentative",
  "linguistic_features": {
    "modality": "uncertain"
  }
}

The result remains session-specific. If “Maya” cannot be matched uniquely, retain the assertion while leaving resolved_person_id null.

“Alex checked in, but Priya canceled”

[
  {
    "person": "Alex",
    "status_type": "check_in",
    "normalized_status": "checked_in"
  },
  {
    "person": "Priya",
    "status_type": "response",
    "normalized_status": "canceled"
  }
]

The multi-person rule is straightforward: assign statuses through grammatical, semantic, table, or discourse relationships—not nearest-name proximity alone.

Titles, nicknames, pronouns, and descriptions introduce further ambiguity. “Dr. Lee,” “Jordan,” “J. Lee,” “the facilitator,” and “they” may denote one person, several people, or nobody in the contact database. Do not force uncertain coreference or identity links.

Plans also change. Store a timeline of assertions rather than one mutable label:

Time	Source	Status type	Status
Monday	Registration form	registration	registered
Tuesday	Email reply	response	rsvp_yes
Friday	Email update	response	canceled
Event day	Check-in export	check-in	unknown
Next day	Host record	attendance	no_show

The current response may be canceled because the later response supersedes the earlier RSVP. The earlier record still explains planning, reminders, and other actions.

Contradictory sources should remain visible. If an RSVP says declined but an authoritative check-in record shows arrival, the system can represent both. An organization may choose to prioritize check-in or reviewed post-event records when answering whether someone appeared, while retaining the earlier RSVP for audit.

A proposed operational hierarchy might be:

reviewed post-event attendance record;
authoritative event or session check-in record;
host or staff attendance note;
registration or RSVP export;
calendar response;
free-text inference.

This order is a policy choice, not a universal rule. Conflict handling should consider source type, timestamp, event granularity, and the question being answered.

Optional dimensions can represent richer evidence:

attendance_mode: in_person, virtual, hybrid, unknown;
arrival_time;
departure_time;
participation_duration;
partial_attendance;
late_arrival;
early_departure.

Populate them only when supported. A check-in timestamp does not establish departure time, and a virtual login does not establish continuous participation.

Prefer structured exports when the source already has reliable fields

Not every person-and-status problem requires NLP. First classify the source:

Arbitrary prose: email, chat, notes, narrative documents;
Structured export: CSV, API response, database table;
Semi-structured content: HTML tables, forms, PDFs;
Platform tracking view: fields exposed through an interface;
Clipboard data: copied tab-delimited rows;
Fixed-layout scraping: values retrieved through stable selectors.

When an authoritative system already supplies separate person, event, session, status, and timestamp fields, ingest those fields directly. Running prose extraction over a structured row adds ambiguity and can discard identifiers or timestamps.

Planning Pod illustrates why format matters. Its CSV attendee export includes contact details, RSVP status, meal choices, and custom-question responses, while its PDF export contains a narrower subset and excludes contact information and custom-question responses (Planning Pod attendee export guide).

Outlook can likewise provide copied tracking rows or a CSV. Import those as structured response records with provenance such as calendar_response or rsvp_export; do not relabel “attending” as verified attendance.

Fixed CSS selectors may retrieve a speaker name or RSVP count from a known page layout. That is useful for layout-specific scraping, but it is not a general solution for extracting attendance assertions from arbitrary language. Selectors can break when markup changes, and an RSVP count still represents planned rather than verified attendance.

Use this practical source-selection order:

Authoritative structured attendance or check-in data
Structured response or registration data
Semi-structured extraction from stable layouts
Free-text inference for facts unavailable in reliable fields

Apply the hierarchy at field level. An export may authoritatively supply person_id and event_id, while a staff note provides the only evidence of an early departure. Combine the fields without pretending the sources have equal evidentiary strength.

Every assertion should carry a provenance label, such as:

check_in_export;
post_event_attendance;
rsvp_export;
registration_export;
calendar_response;
email_reply;
meeting_note;
html_scrape;
inferred_text.

Provenance lets downstream users distinguish stated intent from recorded presence after values have been normalized.

Resolve identities conservatively and create an ambiguity queue

Extracting a name mention and resolving it to a unique database person are separate operations.

The text may clearly say “Alex Kim checked in” while the CRM contains several people with that name. The extraction can be correct even when identity resolution is impossible. Do not convert identity uncertainty into a false attendance record.

Use a layered matching policy:

stable registration or attendee identifier;
normalized email address;
normalized phone number;
full name only when exactly one eligible candidate qualifies;
manual review or unresolved status.

Eligibility constraints may include event registration, account membership, organization, or location when those attributes come from trusted fields. Avoid narrowing candidates with speculative attributes inferred from prose.

Email and phone matching are useful, not infallible. Names may be abbreviated, misspelled, transliterated, or duplicated.

Document automatic synchronization and CSV import as separate workflows. Solidarity Tech’s automatic Zoom synchronization can use registration identifiers and may use email in some cases. Its documented CSV matching sequence tries case-insensitive email, then phone number, and then full name only when exactly one database person has that name. Unmatched results remain available for review, and the documentation notes that personal email addresses or nicknames can explain failures (Solidarity Tech attendance documentation).

For each successful resolution, preserve the method and evidence:

{
  "resolved_person_id": "person_example",
  "identity_match_method": "normalized_email",
  "identity_match_confidence": null,
  "confidence_state": "not_calibrated",
  "candidate_count": 1
}

Confidence should accompany—not replace—the match method, candidate set, and supporting identifiers.

Create an ambiguity queue with explicit categories:

duplicate full names;
several possible contacts;
unmatched name;
conflicting identifiers;
unresolved pronoun;
unnamed guest;
nickname or variant not confidently mapped;
contradictory statuses;
low-confidence event or session link;
malformed or incomplete source record.

Each review item should display the source document, evidence span, extracted fields, proposed candidates, matching rationale, and relevant assertion history.

Reviewers should be able to:

accept a proposed candidate;
select another existing identity;
merge duplicates through a controlled process;
leave the mention unresolved;
correct the extracted name span;
change the normalized status;
change the event or session link;
reject the assertion;
add an explanatory note.

Preserve both the original extraction and the corrected result. Reviewer changes are valuable audit evidence and potential training data.

Do not automatically create a contact for every unmatched mention. The mention could be a duplicate, quoted person, fictional example, staff member, unnamed guest, or someone outside the intended data scope. Contact-creation rules require their own duplicate, access, and retention controls.

Evaluate every component and govern the resulting personal data

A single overall accuracy score is inadequate. Strong name detection can conceal poor person-status linkage, while high status-classification accuracy can conceal identity matches assigned to the wrong person.

Evaluate these components separately:

person-name span detection;
attendance-expression span detection;
linguistic-feature detection;
normalized status classification;
person-status linkage;
event linkage;
session linkage;
coreference resolution;
database identity matching;
current-state derivation from assertion history.

For extraction stages, report precision, recall, and F1 on an attendance-specific annotated test set. Exact-span and overlap-tolerant metrics can both help with entity spans, but relation scoring should require the correct person, status, event, and session where applicable.

Identity resolution needs operational metrics:

correct matches;
false matches;
unresolved cases;
coverage;
automatic-acceptance rate;
review rate;
reviewer correction rate.

The relative cost of a false match and an unresolved case depends on the use case. Set thresholds from the organization’s error costs rather than adopting a universal cutoff.

Build test groups that expose likely weaknesses:

direct acceptances and declines;
negated statements;
tentative and conditional language;
cancellations and corrections;
several people in one sentence;
duplicate full names;
pronouns and descriptive phrases;
repeated event mentions;
conflicting timestamps;
missing statuses;
event-level versus session-level assertions;
quoted email history;
alternate addresses and nicknames;
unnamed guests;
structured rows mixed with narrative notes.

Measure performance overall and by group. A system that succeeds on “Name — Attended” lists may still fail on corrections, cancellations, or multi-person sentences.

Compare rules, conventional classifiers, contextual models, joint extraction systems, and LLM-based approaches on the same labeled records. The methods and heuristics in this guide are design candidates; the supplied evidence does not establish an attendance-specific benchmark winner.

Production monitoring should track distribution changes. A new platform, language, email template, or status vocabulary can reduce performance without a code change. Monitor unknown raw statuses, unresolved identity rates, mapping failures, and review volume.

Auditability requires more than the final label. Retain:

evidence spans and offsets;
source and document identifiers;
source type;
document and assertion timestamps;
extraction model or ruleset version;
normalization mapping version;
identity-match method;
confidence state;
reviewer decisions;
correction history;
current-state derivation policy.

Operational safeguards should apply data minimization and role-based access to names, email addresses, phone numbers, identifiers, and presence histories. Source permissions should carry through to imported data: Modern Campus limits ID-number exports by access level, while Kaymbu restricts staff attendance exports to higher-level users and limits teachers to student data for their classrooms.

Privacy, retention, deletion, access, and permitted-use rules vary by organization and context. The extraction system should support those policies with field-level controls, retention metadata, deletion workflows, and audit logs. This technical architecture is not a complete legal or regulatory framework.

Frequently asked questions

Can named entity recognition determine whether someone attended an event?

No. NER can identify a PERSON span such as “Jordan Lee,” but it does not establish that person’s relationship to an event.

The system must also detect the status phrase, interpret negation or uncertainty, link the phrase to the correct person and event, and resolve the mention to a database identity when needed.

Does an RSVP of ‘attending’ count as verified attendance?

No. It records a response or intention, not proof that the person arrived, joined virtually, or participated.

A check-in or reviewed post-event record is generally stronger evidence of presence. Even check-in should not be treated as proof of full-session participation without supporting duration or completion data.

What fields should event attendance extraction return?

At minimum:

raw_name;
resolved_person_id;
event_id;
session_id;
raw_status;
status_type;
normalized_status;
mapping_state;
evidence_span;
assertion_time;
source_document;
source_type;
extraction_time;
confidence_state.

When available, retain name components, offsets, linguistic features, identity-match method, candidate count, attendance mode, arrival and departure times, model version, and review history. Unsupported values should remain null, unknown, or unresolved.

How should two attendees with the same full name be handled?

Do not resolve either mention by name alone. Check for a stable registration identifier, normalized email, or phone number. Accept a full-name match only when exactly one eligible candidate remains.

If several candidates qualify, preserve the extracted assertion, leave resolved_person_id null, and route the record to review.

Is CSV import better than extracting attendance information from text?

Usually—when the CSV is authoritative and already contains the required fields. Direct ingestion preserves source-provided names, identifiers, relationships, statuses, and timestamps.

Text extraction remains useful for emails, chats, notes, corrections, and facts absent from structured fields. The strongest design uses authoritative attendance data first, response or registration data second, and text inference only where reliable fields do not answer the question.

The most dependable workflow treats attendance extraction as evidence linking rather than keyword spotting. Preserve response, registration, check-in, and attendance as separate states; connect each assertion to a person, event, session, source span, and timestamp; prefer authoritative structured records when available; and automate only well-evaluated, unambiguous decisions. Everything else belongs in a reviewable ambiguity queue.