Turn Attendance Mentions Into an Auditable Person-by-Status Table

To extract attendance from text, identify each person, locate the status phrase, and connect the phrase to the correct person. Do not collapse invitation responses, future intentions, calendar states, and observed attendance into one yes-or-no value. Preserve the original wording, offsets, source metadata, and an explicit unknown state so every result remains reviewable.

Use a four-stage extraction pipeline

A practical workflow has four stages:

1. Detect people: Find names such as “Maya Chen” or “Leo” and retain each span exactly as written.
2. Detect attendance expressions: Find phrases such as “accepted,” “may attend,” “checked in,” and “did not attend.”
3. Link people to expressions: Determine which person is the grammatical participant in each statement.
4. Normalize the evidence: Put the phrase in the appropriate response, intent, or attendance field without claiming more than the source establishes.

This is a specialized event-extraction task. The event is a meeting, conference, session, or gathering; people are participants or arguments; and attendance phrases describe responses, intentions, or observed states. Event-extraction systems commonly distinguish event detection from the identification of participants, attributes, and argument roles, as summarized in this survey of event extraction from text.

Keep text extraction separate from identity resolution. The extraction stage should first return the name and evidence as they appear in the source:

person_text: Maya
person_start: 0
person_end: 4
evidence_text: checked in
evidence_start: 5
evidence_end: 15

A later matching stage can try to connect “Maya” to a registration, employee, constituent, or contact record. If that match is uncertain, retain the extracted mention and leave matched_person_id empty.

Named entity recognition alone is insufficient. Detecting “Alex” as a person does not establish whether Alex accepted an invitation, planned to attend, checked in, failed to appear, organized the event, or was merely discussed. When the text does not establish observed participation or absence, use attendance_status=unknown.

Define separate fields for response, intent, and observed attendance

The following taxonomy is a recommended design, not an official spaCy, Microsoft Graph, or industry standard.

Field	Purpose	Example values
person_text	Name exactly as written	Maya Chen
invitation_response	Reply to an invitation	accepted, tentative, declined, unanswered, organizer
attendance_intent	Stated plan	planned, tentative, not_planned, unknown
attendance_status	Observed participation	attended, absent, unknown
calendar_availability	Calendar display state	free, busy, tentative, unknown
event_cancellation	Event-level state	cancelled, not_cancelled, unknown
event / session	Relevant event and sub-event	Summit, Morning workshop
source_value	Unmodified source label	tentativelyAccepted
evidence_text	Exact supporting phrase	may attend
character_offsets	Evidence location	42:52
timestamp / source	Evidence time and origin	Timestamp, file, or record
perspective	View that supplied the value	organizer_calendar
confidence	Extraction or linkage confidence	Score or band

Add identity and review fields after extraction: match_method, matched_person_id, match_confidence, and review_status.

Reserve attendance_status=attended for explicit evidence such as “attended,” “checked in,” or a documented participation record. Use absent only when the source explicitly reports nonattendance or a no-show. Silence, an unanswered invitation, or a blank check-in field remains unknown.

Input statement or value	Normalized result	Still unknown
“Alex accepted the invitation.”	invitation_response=accepted	Actual attendance
“Priya may attend.”	attendance_intent=tentative	Actual attendance
“Maya was checked in.”	attendance_status=attended	—
“Leo did not attend.”	attendance_status=absent	—
Blank check-in field	attendance_status=unknown	Whether the person attended

Calendar availability and event cancellation belong in separate fields. A busy calendar does not prove participation in the named event, and cancellation describes the event rather than an individual attendee. Microsoft Graph likewise models response status, availability, and cancellation as separate event properties in its event resource documentation.

Detect person names and attendance expressions

Start with a trained spaCy pipeline appropriate to the input language. Processing text creates a Doc; predicted entities in doc.ents expose entity text, labels, and character offsets. Token annotations also provide lemmas, morphology, dependency labels, heads, and children that can support extraction, according to spaCy’s linguistic features documentation.

A basic person-span pass might look like this:

import spacy

nlp = spacy.load("en_core_web_sm")
doc = nlp(text)

people = [
    {
        "person_text": ent.text,
        "start": ent.start_char,
        "end": ent.end_char,
        "label": ent.label_
    }
    for ent in doc.ents
    if ent.label_ == "PERSON"
]

Treat the resulting entities as predictions. Depending on the source material, supplement NER with known aliases, bounded rules, or a model tuned to representative examples.

Group attendance rules by evidence type instead of maintaining one undifferentiated keyword list:

• Invitation response: accept, decline, RSVP yes, RSVP no, no response
• Future intent: will attend, plans to join, intends to come
• Uncertainty: may attend, might join, hopes to come
• Observed attendance: attended, checked in, joined, participated
• Explicit absence: did not attend, was absent, no-show
• Cancellation: event cancelled, session called off

Use lemmas and token attributes to cover variants such as attend, attends, attended, and attending. Add multi-token patterns for expressions such as check in and checked in.

Classification must account for syntax:

• “will attend” → planned intent
• “may attend” → tentative intent
• “did not attend” → explicit absence
• “was checked in” → observed attendance
• “did not say Maya attended” → no positive attendance claim
• “the event was cancelled” → event cancellation, not personal absence

For every match, save the original phrase and its offsets. Reviewers should be able to trace a normalized value back to the exact words that produced it.

Link each status to the correct person

When several names appear, use grammatical relationships before proximity. Dependency relations can help connect a person acting as a subject or object to an attendance verb while identifying auxiliaries, modal terms, and negation. The nearest name is not always the participant.

Consider this synthetic input:

Maya checked in, Leo may attend, and Alex accepted the invitation.

The output should contain three rows:

Person	Response or intent	Observed attendance
Maya	unknown	attended
Leo	tentative intent	unknown
Alex	accepted response	unknown

More difficult structures need explicit handling:

• Shared predicate: “Maya and Leo attended.” Expand the coordinated subject and link both names to attended.
• Elliptical negation: “Maya attended, but Leo did not.” Carry the omitted attendance verb into the second clause and assign absent only to Leo.
• Pronoun: “Priya accepted. She later checked in.” Resolve “She” to Priya, but mark the coreference link as model-predicted.
• Reported speech: “Maya checked in while Leo said Alex might attend.” Assign tentative intent to Alex, not Leo.
• Operator role: “Jordan checked in Maya.” Treat Maya as the attendee and Jordan as the check-in operator unless other evidence establishes Jordan’s attendance.

Coreference can also connect references such as “the keynote speaker” to an earlier name. If the antecedent is ambiguous, retain the candidate link, method, and confidence rather than silently treating it as fact.

Store separate confidence values for the person span, status span and classification, person-status link, coreference link, and identity match.

The following illustrative baseline shows how one source sentence can become an auditable row. It is a representation pattern, not a validated classifier:

source_text: Maya checked in at the morning workshop.
person_text: Maya
person_offsets: 0:4
evidence_text: checked in
evidence_offsets: 5:15

invitation_response: unknown
attendance_intent: unknown
attendance_status: attended

event: Annual Summit
session: Morning workshop
source: meeting_notes_01
timestamp: 2026-06-12T10:05:00Z
person_status_link_confidence: high

matched_person_id:
match_method: unresolved
review_status: needs_identity_review

This structure preserves the observation even when identity resolution is incomplete.

Normalize source-specific values without overstating attendance

Source systems use “status” to mean different things. Normalize each value according to what it measures, and preserve the original field and value.

Microsoft Graph’s responseStatus values are none, organizer, tentativelyAccepted, accepted, declined, and notResponded. They describe a response to a meeting request, not verified physical or virtual participation. Microsoft documents none as the organizer-side view and notResponded as the attendee-side view of an unanswered request, while noting that clients may treat the values as equivalent (Microsoft Graph responseStatus documentation).

For analysis, both values may map to invitation_response=unanswered, provided the source value and perspective remain available:

invitation_response: unanswered
source_value: none
perspective: organizer_calendar

Do not convert:

• accepted or tentativelyAccepted to attended;
• declined, none, or notResponded to absent;
• organizer to proof that the organizer participated.

Keep showAs values such as free, busy, and tentative in calendar_availability.

Structured check-in records provide a different type of evidence. In the Encompass Event Attendance Export, checked_in=1 is the documented positive check-in signal. The export covers registrants, guests, and walk-up attendees, but its documentation does not define a missing or non-1 value as proof of absence. Map the positive signal to attendance_status=attended; otherwise retain unknown unless another source explicitly establishes absence (Encompass export field definitions).

Represent multi-session events at the session level:

person_text,event,session,attendance_status
Maya Chen,Annual Summit,Morning workshop,attended
Maya Chen,Annual Summit,Afternoon panel,unknown

A walk-in can have documented attendance without prior registration or a persistent person ID. Conversely, an accepted registration can remain unknown for every session.

Treat evidence as typed observations rather than imposing a universal precedence rule:

• Positive check-in or participation evidence may establish attendance for a defined event or session.
• Explicit nonattendance language may establish absence for its stated scope and time.
• Invitation data establishes response or intent.
• Calendar availability supplies scheduling context.
• Missing evidence remains unknown.

If positive and negative attendance observations refer to the same person, session, and relevant period, retain both with their sources and timestamps. Add a contradiction or review flag and route the record for human resolution. Do not automatically decide that one evidence type always overrides the other.

By contrast, “accepted on Monday” and “did not attend on Friday” are not inherently contradictory: the first records an invitation response, while the second records observed nonattendance.

Match extracted names to attendee records cautiously

Entity extraction answers, “What name appears in the text?” Identity resolution asks, “Which database person, if any, does this mention represent?” Keep both answers.

A recommended matching order, informed by documented event-attendance workflows, is:

1. Registration or attendee ID
2. Email address
3. Phone number
4. Uniquely matching full name
5. Manual review

One documented attendance workflow uses registration ID, email, phone number, and uniquely matching full name to reconcile participation records. It also identifies practical obstacles such as nicknames, alternate email addresses, guest access, and differently entered virtual-meeting names. In that workflow, full-name matching is automatic only when exactly one database record has the name (Solidarity event-attendance documentation).

An unresolved record might contain:

person_text: Sam Lee
matched_person_id:
match_method: full_name_multiple_matches
match_confidence: low
review_status: needs_review

Do not choose arbitrarily between duplicate names. Route multiple matches, conflicting identifiers, and ambiguous aliases to review. Keep unmatched people as valid extraction results rather than discarding them.

Walk-ins may require new attendee records, but incomplete identity information does not invalidate the underlying observation. “Sam Lee checked in” can remain credible event evidence even when the system cannot yet determine which Sam Lee it describes.

Evaluate, export, and publish an auditable results table

Create an attendance-specific annotated test set before calling the extractor reliable. Include invitations, calendar messages, chats, meeting notes, post-event reports, check-in statements, uncertainty, negation, multiple people, pronouns, duplicate names, shared predicates, and conflicting updates.

Evaluate each stage separately:

• Person spans: Was the complete name found with correct offsets?
• Status detection: Was the evidence phrase found and classified correctly?
• Person-status links: Was the status assigned to the correct person?
• Normalization: Did the value enter the correct response, intent, availability, cancellation, or attendance field?
• Identity resolution: Was the textual mention matched to the correct record?

Calculate precision, recall, and F1 for each component. Do not publish performance figures unless they can be traced to a defined test set, annotation policy, language, source mix, and system version.

Error analysis should examine:

• organizers or speakers incorrectly labeled as attendees;
• unusual names or initials missed by NER;
• correct statuses attached to the wrong person;
• negation assigned to the wrong clause;
• pronouns linked to the wrong antecedent;
• accepted invitations promoted incorrectly to attendance;
• blank check-in fields converted incorrectly to absence.

Export a CSV or spreadsheet containing the original text, person and evidence offsets, original and normalized values, source, timestamp, event, session, perspective, confidence, identity-match fields, contradiction flags, and review state. Add a compact data dictionary that explains the difference between invitation_response, attendance_intent, attendance_status, and calendar_availability.

TablePage publishes spreadsheets as public data pages, so do not upload private attendee names, contact details, confidential messages, sensitive participation records, or restricted source text. Redact, aggregate, or replace records with synthetic examples before publication.

Use this implementation checklist:

• Separate response, intent, availability, cancellation, and observed attendance.
• Retain unknown instead of forcing unsupported attended-or-absent decisions.
• Preserve source names, evidence spans, original values, timestamps, and perspective.
• Flag conflicting observations for review rather than applying an unvalidated precedence rule.
• Resolve identities only when identifiers or uniquely matching records make the match unambiguous.
• Evaluate person detection, status detection, relation linking, normalization, and identity matching separately.
• Publish only synthetic or genuinely public results as an auditable table.