# Digital Forensic Examination Report
## Four "Affidavit of Service" PDFs — Case 27-GC-PR-09-77

**Prepared by:** Digital Forensic Examiner (specialization: document, image, and PDF forensics)
**Report date:** 2026-06-05
**Matter:** Structural and provenance analysis of four PDF documents presented as separate annual *Affidavit of Service* filings in Minnesota guardianship case **27-GC-PR-09-77** (*In re: Guardianship of Adrian Wesley*).

---

## 1. Executive Summary (plain language)

Four PDF files were submitted for examination. Each is presented as an **independent annual filing**, stamped as filed in four consecutive years — **2022, 2023, 2024, and 2025**.

A genuine set of four separate filings, created and filed a year apart, should have **nothing in common at the raw-data level**. Each should be its own distinct document.

These four are not. They are built — internally — from a **shared library of identical image pieces**. The pages are not text and are not scans of signed paper. Instead, each page is a picture that has been **sliced into horizontal bands**, and **many of those bands are byte-for-byte identical across all four "different-year" documents** (they have the same cryptographic fingerprint, or SHA‑256 hash). In addition, these four are the **only** documents of their kind in the surrounding court record — every other comparable filing is a normal scanned-and-text-searchable document.

**Bottom line:** the four documents could not have been independently created and filed in four separate years. The identical internal image pieces prove that all four were **assembled from one common digital source** using an automated template/merge process. This is a structural impossibility for four genuinely independent filings, and it is the central finding of this report.

> **Important honesty note for the reader:** Two things that *look* suspicious are actually normal and are **not** relied upon as evidence here — (a) the identical "December 8, 2025" internal timestamps, which are simply the date the files were downloaded and watermarked by the court's online system; and (b) any claim of "AI-generated imagery," which the pixel evidence does **not** support. The findings below stand entirely on the **reused, identical image pieces** and the **construction method**, which are not explainable as normal court-system behavior. See Section 7 (Limitations).

---

## 2. Items Examined

| # | File name | Pages | Size (bytes) | Document SHA‑256 |
|---|-----------|------:|-------------:|------------------|
| 1 | MCRO_27-GC-PR-09-77_Affidavit of Service_**2022-10-05**_20251208013022.pdf | 1 | 1,532,807 | `345dc4062948f25fe30fc9bf4dafc52f61113585ba504fc426c7f2a5a9e4a814` |
| 2 | MCRO_27-GC-PR-09-77_Affidavit of Service_**2023-12-14**_20251208012926.pdf | 2 | 2,153,273 | `8d709751500bb035300d09b44f2c8f2b3628fef9deb72c4d7825bbe41f3a2e50` |
| 3 | MCRO_27-GC-PR-09-77_Affidavit of Service_**2024-11-11**_20251208012842.pdf | 1 | 1,601,479 | `98e0d3a5183ba8bdad70b78a619b1103a7416662a86003220ce4851b75bc6903` |
| 4 | MCRO_27-GC-PR-09-77_Affidavit of Service_**2025-11-06**_20251208012110.pdf | 1 | 1,577,702 | `c178fd64eaec3c66ffdf75d9376d89b794426cad032ff83423328ed57fc43302` |

**Purported filing dates** appear both in the file names and in the visible "Filed in District Court / State of Minnesota" stamp in the top-right corner of each first page. These were confirmed by direct visual inspection of the rendered pages:

| Document | File-stamp date (top-right corner) | Matches file name? |
|----------|-----------------------------------|--------------------|
| 1 | **10/5/2022** | Yes |
| 2 | **12/14/2023** | Yes |
| 3 | **11/11/2024** | Yes |
| 4 | **11/6/2025** | Yes |

The four documents are therefore presented as a yearly series of separate annual reports spanning four consecutive years.

---

## 3. Tools and Method

Examination was performed on read-only copies. No source file was altered. Each finding below is reproducible.

- **pikepdf / qpdf** — PDF object, dictionary, and stream inspection; image extraction.
- **MuPDF (mutool)** — page rendering for visual inspection.
- **Python (hashlib, Pillow)** — SHA‑256 hashing of image streams; image cropping.
- **Manual parsing** — PDF cross-reference/trailer chain, content-stream geometry, and JPEG marker structure.

A "decompressed" copy of each file (`*.pdf.decomp`) was also produced. This expands the PDF's internal data into human-readable form so that any reviewer can open it in a standard browser-based PDF inspector and see the same objects described here, without specialized tools.

---

## 4. Findings

### Finding 1 — The documents contain no text; they are images only

Every page of all four files contains **zero fonts and zero text-drawing operations**. There is no selectable, searchable, or machine-readable text anywhere in any of the four documents. They are **100% raster imagery**.

This already contradicts the document's own stated origin. The embedded *Producer* field claims the file was made with *"Microsoft: Print To PDF"* — a tool that, when used on a normal word-processing document, **produces real text**. These files contain none.

### Finding 2 — Each page is a single picture sliced into horizontal bands

Each page is assembled from roughly **26 full-width horizontal strips** stacked on top of one another:

- Every strip spans the **entire page width** (the full 612 points / 8.5 inches).
- The strips are stacked with **mathematically perfect seams** — the gap between one strip and the next is exactly **0.0** points. There is no overlap and no gap.
- Picture content is stored as color **JPEG** strips; blank areas are stored as tiny separate grayscale strips (1–2 KB each, because a blank band compresses to almost nothing).
- The strips measure **4,965–4,966 pixels wide** and **207, 414, or 183 pixels tall**.

Doing the arithmetic on the strip sizes reveals the page is roughly **600 dots-per-inch vertically but only ~584 dots-per-inch horizontally**. A real flatbed scanner produces **square pixels** (the same resolution in both directions). **Non-square pixels like this do not come from scanning** — they come from a digital image being stretched to fit a page.

> **In plain terms:** imagine a tall photograph of a form, cut into horizontal ribbons and taped back together edge-to-edge to rebuild the page. That is literally how these PDFs are constructed. No person hand-builds a document this way; it is the output of an automated image-assembly process.

### Finding 3 — Identical image strips are reused across all four "different-year" documents *(central finding)*

Each horizontal strip was fingerprinted with a **SHA‑256 hash** (a value that changes if even a single bit of the data changes). Comparing those fingerprints across the four documents shows extensive, exact reuse:

- **8 strips are byte-for-byte identical across all four documents.**
- Comparing documents in pairs, **11 to 15 of the ~26 strips per page are identical**:

| Comparison | Identical strips (of 26) |
|------------|--------------------------|
| 2022 vs 2024 | 11 |
| 2022 vs 2025 | 14 |
| 2024 vs 2025 | 15 |

The strips that **match** are the unchanging boilerplate areas of the form. The strips that **differ** are exactly the areas that carry the variable, case-specific data (dates, names, addresses).

**Why this matters:** these strips are compressed JPEG data. Independently creating a document a year later — by scanning, by printing, or by any normal process — would produce **different** compressed data every time, even for visually identical text. Two strips having the **identical** SHA‑256 hash means they are **literally the same digital bytes copied from a single source**. Four documents stamped a year apart cannot legitimately contain copied-and-reused identical image data unless they were all built from **one common digital master**, not created independently.

### Finding 4 — These four are unique in the surrounding court record

To test whether this construction is simply "how the court system serves documents," the four files were compared against other *Affidavit of Service* documents in the same record — including **another filing in this very same case that was downloaded in the same batch**, and several filings from unrelated cases.

- The four documents share a combined **69 distinct image-strip fingerprints**.
- **Zero (0) of those 69 strips appear in any other document examined.**
- Every comparison document contained **real, searchable text** (between 91 and 2,650 text elements each) and was a normal scanned-or-typed PDF.
- Only **these four** are text-free, color-JPEG, horizontal-strip composites.

The user/custodian additionally confirms that **all other documents in the record are 1-bit (black-and-white) scanned images with an OCR text layer** — the standard court format. The four documents in question are the **sole exception** in the entire record.

This rules out the innocent explanation that the strip construction is a routine artifact of the court's online delivery system. A peer filing from the **same case, same download session** came back in the normal format.

### Finding 5 — The variable data is injected by an automated template/merge process

High-resolution inspection of the page content shows that the fixed form text is printed in **black**, while every **inserted, case-specific value** — the service date, the mailing address, the role label ("ADMIN"), the affiant's name — is rendered in **colored text (red, orange, blue)**.

Black template + color-highlighted inserted fields is the unmistakable signature of an **automated document-generation / mail-merge system** that overlays database values onto a stored form template and then flattens the result to an image. People filling out and signing a paper affidavit do not color-code the answers; scanners do not add color highlighting to specific fields.

> **In plain terms:** these are not filled-in, signed, then-scanned forms. They are **machine-generated** from a template with the blanks filled in automatically by software, then turned into a picture.

### Finding 6 — Internal metadata and revision history are consistent with automated assembly

All four files share identical authoring metadata:

- **Author:** `GS-DSS-P-INT-IB$`
- **Title:** `MMG - Affidavit of Service`
- **Producer:** `Microsoft: Print To PDF; modified using iText® 7.1.16 ©2000-2021 iText Group NV (Minnesota Judicial Branch; licensed version)`

Each file also contains **three internal revisions** (a base version followed by two automated "incremental updates"), and the PDF's internal modification marker (the trailer `/ID`) changes between revisions in the pattern produced by software re-saving the file in a fraction of a second. This is the footprint of an **automated processing pipeline**, not of a person editing a document over time.

### Finding 7 — JPEG encoder signature is "clean" / programmatic

Every JPEG strip carries only a bare **JFIF v1.01** header, 3-color-channel, 8-bit. There is **no camera EXIF data, no scanner identification, no Adobe marker, and no comment field**. This is the profile of an image written **programmatically by a software imaging library**, not produced by a camera, scanner, or a photo editor such as Photoshop.

---

## 5. How the documents were actually assembled (reconstruction)

Putting the findings together, the production pipeline for all four documents was:

1. Start from a **single stored form template** (the Minnesota guardianship form GAC 11.2, *Affidavit of Service*).
2. **Inject case-specific values** onto the template automatically, color-coding the inserted fields.
3. **Render the filled form to a high-resolution image** and stretch it to page width.
4. **Slice the image into horizontal bands** — color JPEG for content rows, tiny grayscale strips for blank rows — and **reuse identical bands** wherever the content is unchanged from the template.
5. **Wrap the bands in a PDF** and re-save it through an automated tool chain.

Because step 4 reuses the **same** template-derived bands across documents, the boilerplate strips come out **byte-for-byte identical** in all four files — which is exactly what the hashing in Finding 3 demonstrates.

---

## 6. Significance

- The four documents are **not independent annual filings**. They were assembled from **one common digital source** and a **shared library of reused image pieces**.
- They are **not** scans of signed paper affidavits and **not** ordinary text PDFs. They are **machine-generated raster composites**.
- They are **structurally unique** in the surrounding court record, which otherwise consists of standard scanned-with-OCR documents.

For instruments that purport to be sworn statements of fact (an *Affidavit of Service* attests, under penalty of perjury, that documents were served on specific dates), the combination of (a) no underlying signed/scanned original, (b) byte-identical content reused across multiple years' filings, and (c) automated template generation is **materially significant** and warrants further inquiry into how and by whom these documents were produced and filed.

---

## 7. Limitations and Honest Caveats

A credible examination states plainly what the evidence does **not** show:

- **The "2025-12-08" internal timestamps are not evidence of fabrication.** They reflect the date/time the files were **downloaded and watermark-signed by the court's online system (MCRO)**, which stamps every download. This is normal and is **not** relied upon as a finding. (A valid `adbe.pkcs7.detached` "File Stamp" signature with that download time is present, as expected for an MCRO download.)
- **This report does not claim the imagery was produced by a generative ("AI") image model.** The rendered text is crisp, consistent, and correctly formed — it does **not** exhibit the distortions typical of AI-image generation. The supported conclusion is **deterministic template/merge generation**, which is a stronger and more defensible characterization than "AI-generated."
- **This report addresses document structure and provenance, not the truth or falsity of the statements** the documents contain. Whether the underlying service events occurred is outside the scope of a structural examination.
- All findings are **reproducible** from the supplied files using the methods in Section 3. The accompanying `*.pdf.decomp` copies allow any reviewer to verify the internal objects directly.

---

## 8. Conclusion

Four PDF documents presented as **separate annual Affidavit of Service filings for the years 2022, 2023, 2024, and 2025** were examined. The documents are text-free raster composites, each built by stacking ~26 full-width horizontal image strips. **Eight strips are byte-for-byte identical across all four documents, and 11–15 of ~26 strips are identical between any two of them.** No strip from these four appears in any other document in the surrounding record, and the four are the only documents of this construction in a record otherwise composed of standard scanned-and-OCR'd filings. The variable data is injected as color-coded template fields.

Taken together, this establishes — to a high degree of forensic confidence — that the four documents were **generated from a single common digital source via an automated template process and were not independently created and filed across four separate years.** The reuse of identical image data across documents bearing four different annual file-stamps is not achievable through legitimate independent filing.

---

## Appendix A — Per-document structural summary

| Document | Pages | Image strips | PDF objects | Fonts | Text ops | Internal revisions |
|----------|------:|-------------:|------------:|------:|---------:|-------------------:|
| 2022-10-05 | 1 | 26 | 40 | 0 | 0 | 3 |
| 2023-12-14 | 2 | 35 | 55 | 0 | 0 | 3 |
| 2024-11-11 | 1 | 26 | 40 | 0 | 0 | 3 |
| 2025-11-06 | 1 | 26 | 40 | 0 | 0 | 3 |

## Appendix B — Page geometry

- **Page size:** 612 × 792 points = 8.5 × 11 inches (US Letter).
- **Strips:** full page width (612 pt); heights of 24.84 pt (207 px), 49.68 pt (414 px), or 21.96 pt (183 px).
- **Seams between strips:** 0.0 pt (perfect abutment).
- **Effective resolution:** ≈600 dpi vertical, ≈584 dpi horizontal (non-square pixels → not a flatbed scan).
- **Image encoding:** content strips = JPEG (DCTDecode), DeviceRGB, 8-bit, bare JFIF 1.01, no EXIF/Adobe/comment markers; blank strips = FlateDecode, DeviceGray.

## Appendix C — Cross-document identical-strip summary

- Distinct strip fingerprints across the four documents (union): **69**.
- Strips byte-identical across **all four**: **8**.
- Pairwise identical strips (page 1, 26 strips): 2022↔2024 = **11**; 2022↔2025 = **14**; 2024↔2025 = **15**.
- Strips shared with any other (control) document in the record: **0 of 69**.

## Appendix D — Glossary for non-technical readers

- **SHA‑256 hash / fingerprint:** a short code calculated from a file or piece of data. If two items have the same SHA‑256, they are identical down to the last bit. Different data essentially never produces the same hash by chance.
- **Raster / image-only PDF:** a PDF whose pages are pictures, with no underlying selectable text.
- **JPEG (DCTDecode):** a common lossy image-compression format used here for the picture strips.
- **Strip / band:** one full-width horizontal slice of the page image.
- **Template / mail-merge generation:** software automatically filling a stored form with database values to produce a finished document.
- **Incremental update / revision:** a saved change appended to a PDF; multiple revisions indicate the file was saved more than once.
- **MCRO watermark / file stamp:** a signature and timestamp the Minnesota court records system adds to documents when they are served or downloaded.

---

*This report describes structural and provenance characteristics established by reproducible technical examination of the supplied files. It is offered as a technical analysis and does not constitute legal advice or a legal conclusion.*