# Topic 10 — Font Tracking (Run 01)

## Goal
This topic quantifies and inventories **tracking-font objects** that appear in select PDFs and are flagged in your dataset via:
- `children/doc_set[]` tags like `TG_A1..TG_F1`, and/or
- the presence of `children/tracking.groups[]`, and/or
- tracking-font font objects inside `children/objects[]` whose `object_description` matches `TRACKING-FONT-*`.

The intention of Run 01 is to give you a **clean, repeatable baseline**: “what docs, what groups, what font objects, where do they recur, and how do the metadata/toolchains shift when you cross groups (the ‘brick wall’).”

## What the views produce

### 1) `v10r1_tracked_docs`
A filtered set of **only** documents that look like they participate in tracking-font grouping.

Key fields:
- `doc_set_has_tg_tag`: true if a TG tag appears in `doc_set[]`
- `tracked_flag`: uses `tracking.tracked_flag` when present, else false
- `tracking_group_count`: how many `tracking.groups[]` structs exist (0 if absent)
- metadata convenience fields (`xmp_*`, `derived_create_newer_by_days`, `efile_date`) used for “brick wall” comparisons

### 2) `v10r1_tracked_groups__long`
Explodes `tracking.groups[]` so each row = one doc × one group struct.

Columns are intentionally conservative to avoid binder errors:
- `pdf_group`, `font_group`, and (when present) `font1_name..font4_name`, `font_hash_date`

If your group structs later gain additional keys (hashes, ranks, etc.), we can extend this view safely with `try(g.<key>)`.

### 3) `v10r1_tracking_font_objects__long`
Explodes `objects[]` and keeps only **Font** objects whose description matches `TRACKING-FONT-*`.

This is the “hard evidence” layer:
- `object_sha256` is the stable object hash you can treat as the *tracking-font identifier*
- `object_pdf_group` is parsed from `object_description` (e.g., `B1`)

### 4) `v10r1_doc_summary`
One row per tracked document with:
- `pdf_groups` / `font_groups` (from tracking.groups)
- `object_pdf_groups` + counts (from tracking font objects)

### 5) `v10r1_pdf_group_inventory`
Per `pdf_group`:
- doc counts, cluster presence, and which filing types show up.

### 6) Focal reuse (`v10r1_focal_tracking_font_hashes`, `v10r1_cross_focal_reuse`)
- Focal = `cluster_id = 1570`
- `v10r1_cross_focal_reuse` shows which focal tracking-font hashes recur in other clusters, and how widely.

### 7) Brick wall (`v10r1_brickwall_metadata_by_pdf_group`)
For each `pdf_group`, shows:
- the distinct creator tools/producers/toolkits/companies/authors seen
- how many docs have `derived_create_newer_by_days > 0` (create-date after efile-date)

This is the fastest “is the workflow/toolchain changing abruptly?” detector.

## How to run

From project root:

```bash
duckdb duckdb/mcro.duckdb
```

Inside DuckDB:

```sql
.read duckdb/bootstrap.sql
.read duckdb/starter_views__v3_provenance.sql

-- Topic 10 Run 01
.read sql/topics/10_font_tracking/10_font_tracking__run01__views.sql

-- export CSVs
.read sql/topics/10_font_tracking/10_font_tracking__run01__exports.sql
```

Create the output directory once:
```bash
mkdir -p reports/10_font_tracking
```

## Outputs written
All exports land in:
- `reports/10_font_tracking/`

Files:
- `10r1_tracked_docs__summary.csv`
- `10r1_tracked_groups__long.csv`
- `10r1_tracking_font_objects__long.csv`
- `10r1_pdf_group_inventory.csv`
- `10r1_focal_tracking_font_hashes.csv`
- `10r1_cross_focal_reuse.csv`
- `10r1_brickwall_metadata_by_pdf_group.csv`