Synthetic Onboarding — Beneficiary Designation Data

What this document is

The beneficiary designation names who receives an employee's life insurance and retirement account. It records the employee, their marital status, spouse, children, parents, and then either an election to follow the statutory order of precedence or an explicit list of primary and first and second contingent beneficiaries — each with a name, relationship, date of birth and Social Security number, all of it signed.

Why generate synthetically

This is the densest concentration of personal identifiers in the onboarding packet: a dozen Social Security numbers belonging to a dozen different people, including minors, on two pages. There is no version of a real corpus of these documents that anyone can lawfully share, which is why beneficiary capture is one of the least automated steps in HR onboarding despite being one of the highest-volume. It is also structurally the most interesting form in the packet, because which blocks exist at all depends on the employee's family.

What makes synthetic data useful

Family structure drives the document. A spouse block appears on the 47.1% of employees who are married; a first child on 32.6%, a second on 14% and a third on 3.4%; parents appear on every form. 34.9% of employees elect the statutory order of precedence and sign it themselves, while the other 65% name beneficiaries explicitly and the form carries an employer countersignature instead. Primary beneficiaries are a spouse on 47.2% and a parent on 46%, which mirrors the marital split exactly — the coherence that lets the corpus support relationship reasoning rather than just field reading.

Training challenges

A dozen Social Security numbers on one document means every one of them has to be attached to the right person: a model that finds all twelve and misassigns two has produced a legally wrong document. Twelve dates of birth create the same problem in a different type. Block presence is conditional on family structure rather than fixed, so the same labelled section is populated on 47% of documents and empty on the rest, and the second-contingent block is empty on every document in the corpus while the second primary block appears on just 1.4% — a block so rare that a thousand-identity corpus contains only nine examples of it. Layer on two pages, and the association problem crosses a page boundary.

Who uses this data

HR-tech onboarding suites and benefits administrators capturing designations, retirement recordkeepers and life-insurance carriers processing beneficiary paper, and identity and PII-redaction teams who need a document with many identifiers of the same type belonging to different people — the case single-identifier test documents never exercise.

Document complexity profile

Fields spread across two pages: 29 text, 14 date, 12 Social Security number and 5 checkbox targets, joined by 66 annotation relations. 6 conditional bindings, 4 arithmetic bindings and 16 function calls at maximum expression depth 3 — the deepest binding structure of any onboarding form in the catalog. Whole blocks are gated on marital status and number of children, so the populated field set differs substantially from document to document.

Key stats from our synthetic corpus

Quantitative characteristics of the Onboarding — Beneficiary Designation documents our generator produces.

How this document co-occurs with others

Rates at which identities in our corpus that produce a Onboarding — Beneficiary Designation also produce other documents.

Prevalence rates above are corpus-derived: they were computed over the 641 employment-eligible identities inside a local synthetic corpus of 1,000 identities generated by SymageDocs' World Simulation Engine at seed 20260421 — the shipped definition gates onboarding forms on active employment. Field, page, type and relation counts and the never-populated second contingent block come from the shipped beneficiary designation definition in the SymageDocs form library. No real employee, family, or beneficiary data was used at any stage.

Frequently asked questions

What data format do synthetic beneficiary designations include?

Each generated identity produces a rendered two-page PDF plus a structured JSON annotation file with bounding boxes, field types, and ground-truth values for all 60 fields — 29 text, 14 date, 12 Social Security number and 5 checkbox targets — plus 66 label-to-value relations. Each identifier is linked to the person it belongs to. COCO, YOLO, FUNSD, and BIO/NER exports come from the same job.

Why are there twelve Social Security numbers?

Because the form collects one for the spouse, up to three children, both parents and up to six named beneficiaries. Entity linking — attaching each identifier to the right person — is the actual task, and it is why this document is worth generating rather than approximating with a simpler form.

Which blocks are conditional?

Most of them. The spouse block appears on 47.1% of forms, the first child on 32.6%, the second on 14% and the third on 3.4%; parents always appear. The named-beneficiary section exists on the 65% who do not elect the statutory order. Empty labelled blocks are the norm on this document, not the exception.

Are there blocks the corpus never populates?

Yes. The second contingent beneficiary block is empty on every document, and the second primary beneficiary block appears on only 1.4% — nine documents in a thousand-identity corpus. If your pipeline needs those cases, treat them as effectively uncovered.

Can I use this data commercially?

Yes. Every employee, family member, beneficiary, date of birth and Social Security number is synthetic, contains no real personal data, and is licensed for commercial use including model training, benchmarking, and redistribution inside your own products.