Sample document — a filed credit agreement, printed to PDF
One credit agreement from public EDGAR, printed to PDF without alteration, so that what the document path reads can be shown on a real agreement rather than on one we wrote. Everything below the line is the provenance record committed beside the file, rendered from it; none of it is retyped here.
GoDaddy Inc. — Amended and Restated Credit Agreement (EDGAR exhibit, 22 Jan 2024)
- 24 counted terms · 19 non-recomputable (79%)
- 195 defined terms reached
- 24 of 24 quotations found on the page they cite
- 8 schedules cited · 0 attached
What this means for a lender: of the terms this definition sends outside the agreement, the lender can recompute one in five from reported lines; for the rest the report prints the term, the reason and the page.
A report on a public exhibit; it describes the text of the agreement and is not a finding about the borrower.
Download the agreement (PDF) · Download the report UMFR produced from it (PDF)
This is the report UMFR delivers to a lender who uploads this agreement. We produced it by uploading the file ourselves. 'Borrower' means the party to the agreement; nothing here is a finding about GoDaddy's credit or conduct; it describes the text of the agreement.
This file is a blackline: deleted words appear struck through. Our PDF reader reads struck words as ordinary text. None of the 24 quotations in the report contains a struck word.
To tie the report to the agreement: the agreement’s SHA-256 must equal the digest the report prints under “Per-file digests (the bytes we read)”. The agreement’s SHA-256 is in the first table below. The report cannot name the file it read, so this digest is the only tie between them. A match shows the report read these bytes; as the report itself says, it does not show the document is genuine. Each quotation in the report’s per-term list names the page of the agreement it was read from.
Schedules this agreement cites and the package does not contain
A lender would ask the borrower for these.
- Schedule 9.14 [page 327]
- Schedule 13.2 [page 50]
- Schedule 1.1(d) [page 45]
- Schedule 1.1(a) [page 144]
- Schedule 10.5 [page 153]
- Schedule 10.2 [page 161]
- Schedule 8.13 [page 308]
- Schedule 10.1 [page 329]
Verify this report
- download the exhibit and the report
- run SHA-256 on the exhibit and compare to the digest printed in the report
- open any of the 24 quotations on the page the report cites
edgar-godaddy-ex10-1-credit-agreement-2024-01-12-printed-from-filed-htm.PROVENANCE.md
Sample provenance — GoDaddy credit agreement
This sample describes the text of a filed agreement, not the borrower's conduct.
What this file is
| Filer | GoDaddy Inc. (CIK 1609711) |
| Exhibit | EX-10.1 |
| Filed | 2024-01-12 |
| Accession | 0001609711-24-000009 |
| Source file | ex101-1222024.htm |
| Source URL | https://www.sec.gov/Archives/edgar/data/1609711/000160971124000009/ex101-1222024.htm |
| This PDF | the filed .htm printed to PDF without alteration |
| sha256 (this PDF) | d41a0cf1b3665ff44c788899414e9e421895f4425bf000cbbce54af14c718380 |
Print settings, recorded so the file can be reproduced
Chromium 153.0.8010.12, driven by Playwright: the filed HTML was loaded into a blank page as it is, and the page was printed to PDF with these settings:
- Letter paper
- margins of 0.5 inch on all four sides
- background graphics off
- the browser's own header and footer turned off, explicitly — a browser's default print injects a URL, a date and a page count into the PDF. That would place our text inside the filer's document. The extracted text of this file was checked for that URL, date and page count: none is present. (The agreement's own text names one website and writes "1/2 of 1%"; neither came from the printer.)
What was added to the document: nothing
Only the container is ours. No annotation, no header, no footer, no watermark, no cover page, no provenance note inside the file. Everything on this page lives outside the PDF, which is the only way the statement can be true — the resolver, the classifier and the quotation gate read whatever text is in the uploaded file, so a provenance note inside it would become part of the agreement as far as the engine is concerned, and would be quoted back as the filer's words.
The file's first line, EX-10.1 2 ex101-1222024.htm EX-10.1, is not ours either: it is EDGAR's own wrapper around the exhibit, present in the filed .htm as EDGAR serves it, and printed with the rest.
What UMFR reads out of it, and what a reader can check
Running this file through the conversion route (/api/convert), with the at-close option not set (this document is a tenth amendment with an amended and restated agreement, not a closing), reproduces the measurement committed for this agreement exactly:
| from this printed PDF | the committed measurement | |
|---|---|---|
| non-recomputable share | 79% | 79% |
| covenant-EBITDA terminals | 24 | 24 |
| closure size | 196 | 196 |
and of the 24 quotations in the per-term list:
- 24 of 24 are literal substrings of the text extracted from this PDF, with each run of whitespace collapsed to one space as the engine reads it;
- 24 of 24 contain no string our PDF reader inserts;
- 24 of 24 resolve to a definite page of this document.
That is the point of choosing an agreement from the measured draw. The measured draw was committed on 2026-09-21, before this sample existed. On 2026-10-10 the reader's rule for where a definition ends was corrected. The agreements in the draw are unchanged; the whole draw and this sample were re-derived by the same code, so both still come from one reading. The repository is private, so that comparison is our statement and not something a reader of this page can check. What a reader holding the file and a report can check is the sha256 in the first table and every quotation against the PDF itself.
What the deliverable cannot say about its own input
The convert route never reads an uploaded file's name (session isolation: files are positional). So a report produced from this file cannot state the filer, the exhibit or the filing from the file itself — of the three fields a caller supplies (the borrower name, the document date and the at-close option), the only one that could name it is the borrower name, which prints on the cover. The provenance above is therefore stated here and in this file's name, and not inferred by the engine.