An AI obituary writer for families, and an API that moderates obituaries

The worst thing this tool could do is say something untrue about someone’s mother. A lot of the prompt is there to stop that.

The server builds the request from the answered fields only. An empty prompt is left out entirely, so the model never sees a “Hobbies” heading with nothing under it and tries to fill it in. Each group of answers carries its own instruction. Military service is written “as though the audience understands military lingo.” Religion is mentioned only if the family gave details, and the model is told not to guess. Phone numbers are excluded.

The system message casts the model as a newspaper obituary editor, tells it to use only the data the family provided, and to write a short death notice instead of a full obituary when only the basic details are filled in. One line in it says the audience “is easily offended if you make claims about their deceased loved one that are not true.”

Temperature took a few tries. In February 2023 we raised it from 0.7 to 0.9, and later settled the first draft at 0.6. The Creativity slider in Adjust AI runs from 1 to 5, and the server maps that to a temperature between 0.2 and 1.0, with the middle setting landing on the same 0.6 as the first draft.

A tone change sends the whole conversation so far, then asks the model to rewrite the draft with that tone’s instruction (“give it a more religious tone,” “add some more poesy and artistry”). That way the model is revising the draft it just wrote, with the family’s answers still in front of it.

ObitWriter started on GPT-3.5 Turbo. Tone rewrites moved to gpt-4-1106-preview in January 2024, and in June 2024, with 3.5 Turbo about to be deprecated, first drafts moved to gpt-4-turbo.

Each generation is saved as a Completion row on the family’s Session, with the model, tone and temperature that produced it. The session points at the one the family has chosen through selectedCompletionId, and that’s the text that gets published. The Versions panel is just a list of those rows.

It didn’t start out that clean. Until February 2024 the obituary text also lived in a column on the session and another on the order, and the copies drifted, so an admin or a publish could pick up the wrong version. We moved everything onto Completion, split it into text (the clean obituary) and textWithPrompt (with the AI helper text, which remixes need), backfilled selectedCompletionId with each session’s newest draft, and exported the old columns to CSV before dropping them.

Legacy made some obituaries free to publish, and that opened the door to a false or prank obituary landing on Legacy.com. The fix was to ask who is handling the body, and have someone check.

Every family publishing through the writer enters the provider handling final disposition: whether it’s a funeral home or a cremation provider, its name, phone number, city and state. Providers running the writer on their own site skip this, since we already know who they are. The obituary publishes right away, and the order lands in a Disposition Verification queue in the admin we built, showing the provider details, decedent information and the obituary itself. Legacy’s support team confirms it or rejects it. Rejecting deletes the obituary from Legacy.com through Legacy’s API, and each rejection is stored with the admin who made it.

Whether verification is required at all is a setting in the admin (final_disposition_verification), stored in the database and validated at build time alongside the environment variables. We got the first release wrong. Paid orders were landing in the queue along with free ones, and in April 2024 a hotfix limited verification to free orders.

In July 2024 Legacy wanted a one-week test of whether more families publish when it costs nothing. Every path to publishing on Legacy.com went free behind settings that could be flipped back quickly, and Legacy warned its verification team to expect a spike. The result of that test stayed with Legacy, and we don’t have it.

We also opened the models up through three API routes, for Legacy and partners it approved.

POST /api/obituaries/generate takes the form’s fields as JSON, validated with Zod, where only the first name, last name and date of death are required. Callers authenticate with a bearer key we issue. A second mode takes an existing obituary and a tone and returns a rewrite. The API’s prompt used to ask for a simpler obituary than the writer’s, and in May 2024 we removed that line so API callers and families get the same prompt.

POST /api/obituaries/processor/v2 takes an obituary someone has pasted in and rewrites it as a plain, factual notice in two passes. The first pass pulls the facts out as JSON: name, pronouns, age, birth and death dates and places, services, schools, employer, military branch and a charity, with “undefined” wherever the text doesn’t say. It runs under strict rules. No days of the week, times on a 12-hour clock, no officiants, no links, and military service only if the person served. The second pass gets a prompt assembled from just the defined facts and writes a short notice in its own words, paragraphs of three sentences or fewer, full name used once. Splitting it in two means the rewrite only ever sees facts that the first pass found in the original.

The third route is moderation.

POST /api/obituaries/moderation/v1 takes an obituary and an api_key header and returns a list of flags. Each flag has a flag_id, the bad_content copied word for word, and the rule_broken. An empty list means nothing was found. We built it in late 2023, and by March 2024 Legacy was using it to moderate obituaries on another of its platforms, outside the writer.

A request goes through three layers.

The model comes first, gpt-4o in JSON mode at temperature 0.5. Its first job is to decide whether the text is an obituary at all. If it is, it flags anything that breaks Legacy’s list. The published version has 23 rules, and they’re specific to obituaries:

• song or poem lyrics longer than three lines, and quotes or other copyrighted text
• obituaries for pets
• birth or death years in the future, worked out from the current year on every request, with service dates exempt
• complaints about what the obituary or newspaper costs, and requests to text someone
• non-English text, misspellings, and odd punctuation or line breaks
• slurs, profanity (including inside hashtags), hate groups and a list of hate acronyms, drug references, addiction and violence, including family fights
• Native American team names such as the Redskins and the Cleveland Indians

The prompt also says what not to flag. Death itself isn’t hateful, and non-hateful mentions of gender transition are fine.

Next come a few fixed phrase checks Legacy asked for, plain string matches that always run. “Only regret,” for example, comes back flagged with the note “check for blame or other content issues,” which reads like an instruction to the person reviewing it.

Last, if the caller turns it on, a word list. Each word is matched as a whole word with a regex after email addresses are stripped out, so an address that happens to contain a listed word doesn’t trip it. Each hit becomes its own flag.

Legacy kept adding rules after launch, in November 2024, July 2025 and August 2025, the last one a variant spelling for the team-name rule. One weakness we know about is that if the model’s reply ever fails to parse, the service logs it and returns only the phrase and word-list flags. In that case it fails open, and nothing in the response says the model’s check didn’t run.

The writer was a T3 stack app (Next.js, tRPC, Prisma, Postgres) on Vercel, with Stripe for paid orders and Mailgun for email. Published obituaries went to Legacy’s obituaries API, and newspaper orders to Legacy’s newspaper partner, whose list of papers a cron refreshed every night. Other Vercel crons handled the rest:

• an hourly SFTP upload to Legacy of a CSV of orders created six to seven hours earlier and still not published
• reminder emails to families with an unfinished draft, at 24 and 48 hours, the second with a discount
• a daily report of obituaries created and published and the revenue from them, with CSVs for yesterday, month to date and year to date

In September 2024 we raised every API route’s time limit to 300 seconds. Errors went to Sentry and Datadog, and product analytics to PostHog. Honestly, this codebase never had an automated test suite. Changes went through a staging deployment before production, across 398 merged pull requests. If we built it today, the prompt-building code and the moderation parser are the first things we’d put under tests.

In November 2025 Legacy launched its own guided obituary writer and asked us to point the old one at it. We shipped the permanent redirect the next day. We still keep the API project current, most recently moving it to Node 24 in September 2026. We also built MarketIQ, Legacy’s monthly report for funeral brands.