When people hear that Molo uses language models to extract information from school emails and PDFs, a common assumption is that the model "reads" the document the way a person does: starting at the top, understanding the context, picking out the important bits. The actual process is both simpler and more interesting than that, and understanding it helps explain what the system does well and where it has real limits.
This is a plain-language explanation of how the extraction pipeline works. I will avoid jargon where possible and flag it where it is unavoidable.
Step 1: Getting the text out of the document
A language model works on text. Before any "reading" can happen, the document content needs to be in text form. For a plain-text email body, this is already done: the email protocol delivers the content as text, and that text is passed directly to the next step.
For a PDF attachment, the process depends on how the PDF was created. A PDF produced by a word processor or layout application typically encodes the text content as selectable characters. You can highlight text in the PDF by clicking and dragging because the characters are there as data. Extracting text from these PDFs is reliable and quick.
A PDF that is essentially a photograph (scanned pages, photographed letters) contains no text data. The characters exist as pixel patterns in the image, not as characters in the file. To get text from these, you need OCR: optical character recognition, the process of analysing the image and identifying letter shapes. OCR on clean printed text is generally accurate. OCR on faded prints, misaligned scans, or small font sizes is less so. Our pipeline flags low-confidence OCR results rather than passing uncertain text to the extraction step.
Step 2: Finding dates and events in free-form text
Once the text is available, the extraction layer needs to identify which parts of it are schedulable events. This is where language model capabilities come in.
A language model can be given a passage of text and asked to identify named entities: dates, times, places, people, organisations. This is a well-established task in natural language processing. For a sentence like "Year 4 will visit the local library on Thursday 14 November at 10:30am," the model identifies: a date ("14 November"), a time ("10:30am"), a location ("local library"), and a group ("Year 4"). These become the fields of a structured event record.
The model does not "understand" the sentence in the way a human does. It is applying statistical patterns learned from training on large amounts of text to identify which tokens are likely to be date expressions, which are likely to be locations, and how they relate to each other within the sentence structure. In practice, for well-formed English text with standard date formats, this works reliably. The model has seen many thousands of sentences with dates in them and has learned what date expressions look like.
Where the model is reliable
For most of what UK primary schools send by email, extraction accuracy is high. The formats schools use are not exotic. Date expressions like "Wednesday 18th September," "18 Sep 2025," and "the 18th" are all within the range of patterns the model handles well. Event names like "parents evening," "school photograph day," "Year 5 residential," and "non-uniform day" are common enough in UK school communication that they are reliably identified as schedulable events rather than general information.
Well-formatted PDFs from school management systems, term date tables with clear column headers, and short notification emails with a single event are the cases where extraction works consistently. These cover the majority of scheduled communications most schools send.
Where the model is less reliable
Conditional dates are a significant challenge. "Parents evening will be held in November, dates to be confirmed" is not extractable because there is no specific date yet. The model can identify that the sentence refers to a future event, but it cannot invent a date that is not present. In these cases, Molo creates a reminder that an event is pending rather than a dated calendar entry.
Relative dates require an anchor. "Next Tuesday" means nothing without knowing when the letter was written. Our pipeline uses the email's sent timestamp as the anchor for relative date resolution. If the email was sent on a Monday, "next Tuesday" resolves to the Tuesday eight days later. This is usually correct, but it can fail if the email was sent significantly before the newsletter was read, or if the school's communication system delays sending.
Contradictory information within a document is genuinely hard. A newsletter that says "the trip is on 14 November" in one paragraph and "please note the trip date has moved to 21 November" in a later paragraph requires reading the full document in sequence and recognising that the later date supersedes the earlier one. Our extraction handles this better for clearly marked amendments ("please note the date change") than for cases where the contradiction is implicit.
What this means for how you should use the tool
The practical implication is that Molo works as a first pass that catches the clear, well-formatted events reliably, and surfaces ambiguous ones for your review rather than guessing. You should still check your calendar when a newsletter arrives to see what was extracted and confirm the results make sense. Molo is not a substitute for reading the newsletter. It is a way of having the calendar updated from the newsletter without the manual copying step.
We are honest about the limits because a wrong calendar entry is worse than a missing one. An event incorrectly dated by a week is actively harmful: it creates a false sense that the schedule is covered when it is not. Our calibration is toward flagging uncertain cases rather than committing to guesses, and we would rather show you an item that needs manual review than silently put a wrong date in your calendar.