School newsletters are a surprisingly hard document class to process programmatically. They arrive in dozens of different layouts, carry a mix of narrative text and structured tables, include dates in formats ranging from "Wednesday 18th September" to "18.09.26" to "the 18th of next month," and are often embedded in PDFs designed to be printed and stuck to a fridge, not read by software.
This is a technical walkthrough of how Molo's extraction pipeline handles this. I will cover the document ingestion step, how we approach date and event extraction from free-form text, where we currently draw the line, and what kinds of notices still cause extraction failures.
Document ingestion: getting text out of the attachment
Before any language processing can happen, the document content needs to be in a form the extraction layer can work with. For a plain-text email body this is trivial. For a PDF attachment it is not.
UK school PDFs fall into two broad categories. The first is a text-layer PDF, where the text is encoded as selectable characters in the file. Most newsletters produced from word processors or desktop publishing tools fall into this category. Text extraction from these is straightforward and high-fidelity: we get the actual characters, with most formatting preserved.
The second category is an image-based PDF, where the document has been scanned or exported in a way that embeds the content as a raster image rather than text. A school that photocopies a typed letter and scans it, for instance, will produce this format. For these, we run an OCR (optical character recognition) step before any further processing. OCR on school newsletters is generally reliable for standard printed text, but degrades with handwriting, very small font sizes, or low scan quality. Our pipeline flags low-confidence OCR results and, where confidence falls below a threshold, surfaces the attachment for manual review rather than guessing.
Date and event extraction from narrative text
Once we have clean text, the next challenge is identifying what in that text represents a schedulable event. A school newsletter might contain a sentence like: "Reminder that Years 3 and 4 will be visiting the local library on Thursday 24th April. Children should bring a named water bottle and return their library books by Wednesday 23rd."
From this, the extractable events are: a library visit on 24 April for Years 3 and 4, and a library book return deadline on 23 April. The visit has a named location. Neither has a specific time. Both have implicit dependencies (the return deadline is a prerequisite for the visit). The year group scoping is relevant if you are a parent with a child in Year 3 or 4 but not otherwise.
Our extraction layer uses a combination of named entity recognition for dates and places, and contextual span classification to identify what kind of event each date reference belongs to. The practical result is: event name, date, time where present, location where present, and a notes field capturing contextual details like the water bottle instruction or the return deadline.
What we are not doing is attempting to understand the full semantic structure of the document. We extract what we can reliably classify as a schedulable event. We do not attempt to infer events from text that is ambiguous ("we will let you know closer to the time") or conditional ("if the weather permits").
The date format problem in UK school communications
UK schools use date formats inconsistently, even within a single newsletter. We regularly encounter: "18 September," "18th September," "Wednesday 18th," "18/09," "18.09.26," and occasionally "the eighteenth." We maintain a normalisation layer that resolves these to ISO 8601 format (YYYY-MM-DD) before writing to the calendar.
The tricky cases are relative references: "next Tuesday," "this term," "the last day before half-term." Relative dates require knowing the anchor point, which is either the email's sent date or, where available, previously extracted term date information. If a newsletter from a school has already established term dates via an earlier processed document, we can resolve "last day before half-term" to a specific date with reasonable confidence. Without that anchor, we treat the reference as unresolvable and flag it.
Table-formatted term dates
Many schools send a term dates PDF that is formatted as a table: one column for term, one for start date, one for end date, sometimes additional columns for inset days. These tables are highly structured but the structure varies: some use merged cells, some use bold text as a separator rather than table formatting, some mix landscape and portrait sections in the same PDF.
We handle table extraction as a separate pipeline step. Where a PDF is identified as table-dominant, we run a structure-detection pass before the text extraction step, which improves accuracy on column-aligned content that plain text extraction would otherwise concatenate into a single run-on string.
Where extraction still fails
We are honest about current failure modes. Handwritten additions to printed letters (a teacher has written a time or room number by hand) are outside what our OCR layer can reliably read. Scanned documents where the scan is misaligned or has dark edges from the copier's roller marks degrade OCR confidence significantly.
Newsletters that mix English and another language create a challenge for date normalisation, because the month names differ and the ordinal conventions differ. We are actively working on multilingual date resolution, but it is not complete. A newsletter written primarily in another language with English dates interspersed will often extract the dates correctly; a newsletter where the date itself is written in the other language may not.
Emails that link to a school website or app for the full notice, rather than containing or attaching the notice directly, cannot be processed. We receive only what is in the email and its attachments. A link to a PDF on a school's website is not an attachment.
A note on what this means for calendar accuracy
The design principle we hold is that a missed extraction is better than a wrong entry. Calendar events that arrive with a wrong date are actively harmful: they create a false sense that the schedule is covered. Our pipeline is calibrated to flag uncertain extractions rather than commit to a guess.
In practice, for a standard UK primary school newsletter in plain-text email or text-layer PDF format, extraction accuracy on clear date references is high. The cases that require manual attention are genuinely ambiguous in the source document: a reasonable reader would also need to make a judgement call or contact the school to confirm. We surface those rather than silently elide them.