# 04_clone_matching — Tracking-font Variants (Watermark as Validation Anchor)

This mini-pack produces side-by-side comparisons for **two anomaly pairs** in the `children` dataset:

- **Pair 1 (Guertin, 2023-07-13)**: `Finding of Incompetency and Order` vs `Order-Other`
- **Pair 2 (Conditional Release, 2021-04)**: `Order for Conditional Release` variants (two different cases)

The goal is to make the anomalies “pop” immediately in CSV form:
- **`rev_count` jumps by 2** within each pair (e.g., 9→11 and 8→10)
- **Tracking fonts** appear/disappear in patterned ways:
  - `TRACKING-FONT-C1` (sha256 `1fa67c...`)
  - `TRACKING-FONT-C2` (sha256 `b50a03...`)
- A **specific font object** (sha256 `e668b6...`) appears in one variant but not the other
- Signature timelines (from `signatures.full_report[]`) are exported in signing sequence order

**Important note on the MCRO Watermark:**
- The **“Minnesota Court Records Online (MCRO) Watermark”** signature is treated here as a **download-time validation anchor** (i.e., the court-applied stamp at retrieval).
- Small differences in watermark signing timestamps (e.g., ~1 second) are **expected** when documents are downloaded in sequence (e.g., a scripted downloader with a 1-second pause).
- These reports **include watermark fields to confirm presence, signing order, and coverage**, not to imply the watermark itself is fraudulent.


## How to run

From DuckDB CLI (after bootstrapping + starter views):

```sql
.read duckdb/sql/topics/04_clone_matching/04_clone_matching__tracking_font_anomalies__views.sql
.read duckdb/sql/topics/04_clone_matching/04_clone_matching__tracking_font_anomalies__exports.sql
```

Exports land in:

`./reports/04_clone_matching/`

## Outputs

1) **Doc overview**  
`04_tracking_font_anomalies__doc_overview.csv`  
One row per document with:
- core identity (case_id, cluster_id/name, filing_type/date, filenames)
- **metadata** (document_id, instance_id, xmp_create_date/metadata_date, author/creator/title)
- **signature stats** (rev_count_max, distinct_signers, full_report_rows)
- **font stats** (font_object_count + boolean presence flags for key fonts)
- **MCRO Watermark validation fields** (presence + signing order + coverage; extracted from `signatures.full_report[]` so it works regardless of which sig number the watermark lands on)

2) **Pairwise diffs**  
`04_tracking_font_anomalies__pairwise_diffs.csv`  
Self-join within each `pair_id`, showing deltas/ratios:
- `size_bytes_delta`, `size_bytes_ratio_right_over_left`
- `rev_count_delta`
- document_id equality vs instance_id inequality
- key-font presence flips
- watermark download signature time (validation anchor; included for confirmation only, not as a fraud signal)

3) **Key-font presence**  
`04_tracking_font_anomalies__key_font_presence.csv`  
A compact “audit” table for the 3 key font hashes + watermark validation fields.

4) **Font objects**  
`04_tracking_font_anomalies__font_objects.csv`  
All **Font** objects for the four docs (enables direct diffing / filtering by `object_sha256`).

5) **Signatures full_report timeline**  
`04_tracking_font_anomalies__signatures_full_report.csv`  
All entries from `children.signatures.full_report[]` for these docs (ordered by `sig_index`).

6) **Tracking groups**  
`04_tracking_font_anomalies__tracking_groups.csv`  
Rows from `children.tracking.groups[]` if present.

## Notes

- This pack intentionally targets **four known documents** by `children.me_filename` (hard-coded in `v04_clone_matching__tracking_font__target_docs`).
- If you want to expand this into a generalized detector (e.g., “find all docs containing TRACKING-FONT-*”), we can turn the key-font presence view into a dataset-wide scan.