PerlTurner Pension SolutionsBack to Perl →

Documents

Terms of ServiceAgreementPrivacy PolicyYour dataAcceptable Use PolicyHow you may use itData and AI Usage DisclosureWhat powers it

What powers it

Data and AI Usage Disclosure

Effective August 16, 2026

1. The data

Form 5500 annual reports

Nearly every private-sector retirement and welfare benefit plan in the United States files an annual report — a Form 5500 or, for smaller plans, a Form 5500-SF — with the Department of Labor. Those filings, their schedules, and their attachments are published by the Department as public records. Perl is built on the complete published set.

Coverage. Filing years 2009 through the most recent published year. 2009 is where the Department's electronic filing system (EFAST2) begins; earlier filings exist but are not part of the electronic datasets Perl is built on, so Perl cannot tell you about a plan's filings before 2009.

Scale, as of August 1, 2026. Approximately 4.4 million Form 5500 filings and 10.1 million Form 5500-SF filings across 17 filing years, plus the full set of schedules — including Schedule A (insurance contracts), Schedule C (service-provider compensation), Schedule H and I (financial information), Schedule R (retirement-plan distributions and funding), and Schedule SB and MB (actuarial information).

Filing documents and attachments

Beyond the structured data, Perl can retrieve the filing documents themselves — the form as filed, and its attachments, which is where audited financial statements and accountants' opinions live. She retrieves these from Department of Labor systems and reads them, including scanned attachments, which she processes with document-reading models.

Pension Benefit Guaranty Corporation data

For defined benefit plans, Perl also draws on public PBGC data: single-employer and multiemployer premium filings, and PBGC's list of trusteed plans — plans that failed and were taken over by PBGC, going back to 1974. PBGC publishes these quarterly. Note that the trusteed-plan list reaches much further back than the Form 5500 coverage above, so Perl may know that a plan failed decades ago even though she has none of its filings.

How current it is

Two different clocks, and the slower one matters more.

Our clock is fast. The Department publishes updated datasets around the first of each month. We refresh from the Department daily, so what we hold is generally within a day of what the Department has published.

The filings' clock is slow, and there is nothing anyone can do about it. A plan's Form 5500 is due roughly seven months after its plan year ends, and extensions are routine and common. In practice, when you look at a plan's most recent filing, you are usually looking at a plan year that ended twelve to twenty-four months ago. A plan can have changed recordkeepers, doubled in size, or been terminated since. Perl will always tell you which plan year she is describing. Read that date.


2. What we add to it

The filings arrive as raw government data files — dozens of separate datasets, inconsistent field names, one row per filing with no notion of a plan's history. Most of the work in Perl is in what happens after the download:

  • Plan continuity. A plan's filings are stitched into a single history across years, and across the large-plan and small-plan forms, so that a plan that grew past the small-plan threshold does not look like two unrelated plans. Sponsor name changes, EIN changes, and plan-number changes are tracked.
  • Computed metrics. Per-participant balances, cost ratios, growth rates, funding measures, and provider relationships are calculated from filed figures rather than left for you to derive.
  • Signals worth investigating. Patterns that a professional would want to notice — a sharp change in participant count, a provider change, an unusual expense ratio, a late or amended filing.
  • Document reading. Attachments are located, retrieved, and read, so that an accountant's opinion or a financial statement note is searchable rather than buried in a scanned PDF.

These calculations are ours, and they are derived from filed data. They inherit every limitation of that data, and where a filing is ambiguous, a computed metric built on it is ambiguous too. Perl will tell you when a figure is derived rather than filed.


3. What the filing data can and cannot tell you

This is the section we would most like you to read.

Filings are self-reported. They are prepared by the plan's sponsor, administrator, recordkeeper, or accountant, and submitted under penalty of perjury — but they are not audited by the Department of Labor before publication, and they are not verified by us. Filers make mistakes: transposed figures, wrong codes, blank fields that should have been completed, a service provider recorded under a subsidiary's name.

Filings are amended. A plan can file an amended return that changes the numbers materially. Perl shows the filings as published; if an amendment has not yet been published, she cannot know about it.

Filings are incomplete by design. Small plans file an abbreviated form and are generally not required to attach audited financials. Schedule C compensation reporting has thresholds and exclusions, so an absence of reported fees is not evidence of an absence of fees. Some arrangements are reported at the insurance-contract level rather than the plan level. Some are bundled in ways that make a provider invisible in the data.

Filings describe the past. See the two clocks above.

What this means in practice. Public filing data is excellent for finding what is worth asking about and insufficient for concluding what is wrong. An expense ratio that looks high may reflect a bundled arrangement, a short plan year, a one-time conversion cost, or a filer's reporting choice. The professional move is to treat what Perl surfaces as a question to bring to a conversation, not a finding to announce. Saying "I noticed your most recent filing reports X — help me understand that" is both safer and more effective than saying "your plan is overpriced."


4. What Perl is, technically

Perl is an AI assistant. When you ask her something, a language model reads your question, decides what information it needs, runs queries against our Form 5500 database, retrieves filing documents where relevant, and writes you an answer.

A few things about how that is built:

  • She cannot change the filing data. The queries Perl writes to answer your questions run under a database role that has no ability to insert, update, or delete, inside a read-only transaction, and they pass a guard that rejects anything that is not a read. Three independent layers, because this is the one thing that must not fail. Nothing you can ask her to do — and nothing anyone else can ask her to do — will alter a filing record.
  • She does save a few things, deliberately. When she builds a report for you, it is saved so you can return to it; when she retrieves a filing document, it is cached so nobody has to fetch it twice. Those writes use fixed, pre-written statements in separate areas of the database, never a query she composed. She writes what she is designed to write, and nothing else.
  • She cites her sources. Material facts are tied back to a specific filing — plan, sponsor, filing year, and where applicable the schedule, line, or attachment. That is deliberate: the citation is how you verify her, and verifying her is part of using her properly.
  • She uses different models for different work. Simpler requests are handled by faster, cheaper models and harder analysis by more capable ones. This is a cost and speed decision, and we tune it; it does not change the data she is working from.
  • She is instructed not to guess. Perl's instructions require her to say she does not know, or that the data does not support a conclusion, rather than produce a plausible-sounding number. We consider a confident wrong answer to be the worst thing this product could do.

5. What Perl gets wrong

She will sometimes be wrong. Being specific about how is more useful than a general disclaimer:

  • She can misread a document. Scanned attachments, unusual layouts, and handwritten or poor-quality pages are read by a document model and can be misread — a figure from the wrong column, a footnote attached to the wrong line.
  • She can summarize imprecisely. A summary compresses, and compression loses qualifiers. The qualifier in the original filing may be the thing that mattered.
  • She can be confidently wrong while citing a real source. The citation tells you where she looked. It does not prove she read it correctly. This is the failure mode to watch for.
  • She can miss something. A plan filed under an unexpected sponsor name, a provider reported in an unusual field, an attachment that was never filed — absence in Perl's answer is not proof of absence in the world.
  • She works from what was filed. If the filer got it wrong, so will she.

So: verify anything that matters before you use it. Before you put a figure in front of a client or a prospect, open the filing she cited and look at it. She makes that one click. That is the point of the citations.


6. What Perl is not

Perl does not give advice. She provides information and analysis about public filings. She does not provide investment, tax, legal, accounting, actuarial, insurance, or fiduciary advice, and nothing she produces is a recommendation to buy, sell, hold, or replace any investment, provider, plan design, or service arrangement. Turner Pension Solutions is not your fiduciary or a fiduciary to any plan by virtue of your using Perl. The professional judgment is yours, and so is the responsibility for it.

Perl is not a consumer report. She is not a consumer reporting agency's product and may not be used to determine anyone's eligibility for credit, insurance, employment, housing, or any other purpose regulated by the Fair Credit Reporting Act.

Perl does not vouch for a plan or a sponsor. She has not vetted anyone. She reports filings.

Perl does not promise you business. She is a research tool. What you do with what she finds is your work.


7. Your information

Briefly, because the Privacy Policy covers it properly:

  • We do not keep a transcript of your conversations. Your questions and her answers are not written to a transcript in our database. What we do keep is a count of your activity, a profile of the topics you research and how you like to be written to, a record of which plans you looked at, and any report you had Perl build.
  • Our AI provider is contractually prohibited from training its models on your content.
  • We do not sell your information, and we do not use it for advertising.
  • Your exports are yours. Files you download stay yours, including after your subscription ends.
  • If you use the microphone button, your browser sends your voice to its own vendor — Google in Chrome, Microsoft in Edge — to turn it into text. That happens between you and your browser, before it reaches us. Type instead if you would rather it didn't.

The full picture is in the Privacy Policy.


8. If you think something is wrong

If Perl misreports what a filing says — she cited a filing but got the number or the meaning wrong — please tell us at perl@wehelppeopleretire.com with the plan and the answer. This is the most useful bug report we can receive, and we would rather hear it than not.

If the filing itself is wrong — the plan's own annual report contains an error — we cannot fix that, because we publish what the Department of Labor publishes. The correction has to be made by the plan's filer through an amended filing. Once the Department publishes the amendment, it will flow into Perl on a normal refresh.

If you are a plan sponsor or administrator who has found your plan's filing information here and has questions about it, you are welcome to write to perl@wehelppeopleretire.com. Form 5500 filings are public records published by the federal government, and we do not have the ability to remove a plan's public filing history from the record. We will explain what we hold and where it came from.