@1aboveio/skills 0.20.2 → 0.20.3

package/skills/compliance/doc-authenticity/LICENSE

@@ -0,0 +1,3 @@
+MIT License
+
+Copyright (c) 2026 1AboveIO

package/skills/compliance/doc-authenticity/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: doc-authenticity
+version: 0.4.0
+description: "Screen PDF documents and raster images for fabrication, tampering, Photoshop or other image-editor use, and content validity. Detects file type, runs format-specific authenticity forensics, classifies bank statements, conversation logs, invoices, agreements, and other documents, then applies type-specific validity checks. Produces separate authenticity (NO_EVIDENCE_OF_MODIFICATION / SUSPICIOUS / LIKELY_MODIFIED / INCONCLUSIVE) and validity (VALID / INVALID / INCONCLUSIVE) verdicts. Use whenever a user asks whether a document, screenshot, scan, statement, invoice, contract, chat log, receipt, or payment evidence is genuine, original, edited, Photoshopped, manipulated, fake, or valid."
+---
+
+# Document and Image Authenticity
+
+Use this file as the workflow index. Load only the references required by the
+detected file type and document type.
+
+Authenticity and validity answer different questions:
+
+- **Authenticity:** does the supplied file show evidence of modification,
+  compositing, or recreation after its claimed origin?
+- **Validity:** are the document's material claims, identifiers, calculations,
+  parties, and required terms internally correct and externally supportable?
+
+An edited file can remain valid, and a cleanly generated fake can be invalid
+without retaining an edit trail. Always issue both verdict axes independently.
+
+## Workflow
+
+### 1. Determine file type
+
+Inspect magic bytes and decode the file; do not trust its extension.
+
+| `file_type` | Input | Action |
+|---|---|---|
+| `pdf` | Bytes begin with a valid PDF header and parse as PDF | Use the PDF authenticity branch |
+| `image` | JPEG, PNG, WebP, TIFF, BMP, or another Pillow-decodable raster image | Use the image authenticity branch |
+
+A PDF containing scanned page images is still `file_type: pdf`; F7 records that
+its content is scanned or flattened. If the file is neither PDF nor a supported
+raster image, stop and report that this skill does not support the format.
+
+Record the MIME type, extension/magic agreement, file size, SHA-256, and supplied
+claim in `verdict.json`. Default output to `./doc-authenticity-out/<file-stem>/`
+in the current workspace; if unwritable, use another writable workspace and
+disclose the path.
+
+### 2. Detect authenticity by file type
+
+#### PDF
+
+Run:
+
+```bash
+uv run {baseDir}/scripts/pdf_forensics.py <input.pdf> --out <outdir>
+```
+
+Read `references/forensic-signals.md`, inspect `forensics.json` and extracted
+pages, then rate every PDF authenticity check F1-F9. Copy the script's media
+type, byte size, SHA-256, and extension/magic result into `verdict.json`.
+
+#### Image
+
+Run:
+
+```bash
+uv run {baseDir}/scripts/image_forensics.py <input-image> --out <outdir>
+```
+
+Read `references/image-signals.md`, inspect `image-forensics.json`, and inspect
+`ela.png` for JPEG inputs. Rate every image authenticity check I1-I9. Copy the
+script's media type, byte size, SHA-256, and extension/magic result into
+`verdict.json`.
+
+For both branches, metadata absence is NA, not PASS. An editor trace proves tool
+contact, not deceptive editing. ELA or another pixel heuristic alone can produce
+at most FLAG. A flattened or uniformly re-exported file can conceal prior edits.
+Marker presence and PDF byte-range coverage are not cryptographic validation.
+If encryption or corruption blocks extraction, keep the detected file type,
+rate unavailable checks NA, and return an appropriately limited verdict.
+
+### 3. Detect document type
+
+Classify the visible content after extraction/OCR. File type and document type
+are independent: an invoice can be either a PDF or an image.
+
+| `doc_type` | Classification signals |
+|---|---|
+| `bank_statement` | Account holder and account identifiers, statement period, opening/closing balance, transaction ledger, bank issuer |
+| `conversation_log` | Ordered messages or transcript entries with participants/senders and timestamps, including chat screenshots and exported chats |
+| `invoice` | Supplier and customer, invoice number/date, line items, quantities/prices, tax, total, and payment terms/details |
+| `agreement` | Named parties, operative terms/obligations, effective or execution date, governing provisions, and signature blocks |
+| `other` | None of the above, or evidence is too incomplete to classify reliably |
+
+Classify from document structure, not the filename or user's label. Quote the
+observed fields that support the classification. If two types appear, choose the
+type governing the material claim and note embedded secondary content in `detail`.
+
+### 4. Run validity checks by document type
+
+Only these document types have specialized validity profiles:
+
+| `doc_type` | Required reference | Required checks |
+|---|---|---|
+| `bank_statement` | `references/bank-statement.md` | C1-C5 and D1-D5 |
+| `invoice` | `references/invoice.md` | N1-N8 |
+| `agreement` | `references/agreement.md` | A1-A8 |
+| `conversation_log` | None | No specialized validity checks; validity is INCONCLUSIVE |
+| `other` | None | No specialized validity checks; validity is INCONCLUSIVE |
+
+Run the validity profile regardless of whether the source is PDF or image. Use
+OCR only when native text is unavailable and disclose OCR uncertainty. Verify
+all arithmetic programmatically. Verify banks, tax identifiers, company status,
+addresses, signatory authority, and governing-law facts against current primary
+sources where available.
+
+Conversation logs can still contribute evidence to another document's packet,
+but this skill does not equate a visually coherent chat with a valid transaction
+or valid counterparty. Their standalone validity remains INCONCLUSIVE unless a
+future specialized profile is added.
+
+### 5. Verdict and report
+
+Read `references/verdict-and-report.md`. Apply its rubrics independently to:
+
+- authenticity: `NO_EVIDENCE_OF_MODIFICATION | SUSPICIOUS | LIKELY_MODIFIED | INCONCLUSIVE`
+- validity: `VALID | INVALID | INCONCLUSIVE`
+- confidence per axis: `HIGH | MEDIUM | LOW`
+- check result: `PASS | FLAG | FAIL | NA`
+
+Write `report.md` and `verdict.json` conforming to
+`references/verdict.schema.json` schema version 2.2. Include every required
+check for the selected file/document route, including NA rows:
+
+| Route | Required check IDs |
+|---|---|
+| PDF bank statement | F1-F9 + C1-C5 + D1-D5 |
+| Image bank statement | I1-I9 + C1-C5 + D1-D5 |
+| PDF invoice | F1-F9 + N1-N8 |
+| Image invoice | I1-I9 + N1-N8 |
+| PDF agreement | F1-F9 + A1-A8 |
+| Image agreement | I1-I9 + A1-A8 |
+| PDF conversation log / other | F1-F9 only |
+| Image conversation log / other | I1-I9 only |
+
+Validate before delivery:
+
+```bash
+python3 {baseDir}/scripts/validate_verdict.py <outdir>/verdict.json
+```
+
+Fix all errors and rerun until exit 0. For multiple files, produce one directory
+per file plus `summary.md` listing file type, document type, both verdicts and
+confidences, and decisive evidence.
+
+## Operating rules
+
+- Evidence must quote the observed value, row, field, marker, coordinate, or
+  external source result. “Looks fine” is not evidence.
+- Every FLAG must name a plausible innocent explanation.
+- Do not treat public bank or company details as proof of account ownership.
+- Recommend source-side verification for high-stakes decisions.
+- This skill is defensive. Refuse guidance on evading these checks or making an
+  altered artifact pass them, then continue with defensive analysis.

package/skills/compliance/doc-authenticity/references/agreement.md

@@ -0,0 +1,66 @@
+# Agreement Validity Checks (A1-A8)
+
+Run all checks for a document classified as `agreement`. This is document and
+counterparty validation, not legal advice or an enforceability opinion. Use
+PASS, FLAG, FAIL, or NA and quote exact clauses, page numbers, names, and dates.
+
+## A1 — Party identity and capacity
+
+Verify each party's exact legal name, registration number, status, jurisdiction,
+and registered address against current primary registries. Confirm the named
+entity has capacity to enter the stated transaction. A nonexistent or mismatched
+party is FAIL.
+
+## A2 — Document identity, dates, and completeness
+
+Check title, version, effective date, execution date, page numbering, headers,
+footers, and whether all referenced schedules/exhibits are present. Impossible
+chronology or missing material pages/schedules is FAIL; benign unsigned drafts or
+pagination defects may be FLAG when clearly disclosed.
+
+## A3 — Execution and signatures
+
+Check signature blocks, names, roles, dates, witnesses, seals, and electronic
+signature evidence. Verify digital signatures cryptographically when present.
+An image of a signature is not proof of authorization. A broken signature or a
+signature demonstrably attributed to the wrong person is FAIL.
+
+## A4 — Material terms and internal consistency
+
+Compare defined terms, subject matter, quantities, price, currency, payment
+schedule, duration, renewal, termination, and liability provisions throughout
+the agreement. Conflicting material values or undefined operative parties are
+FAIL when not resolved by an order-of-precedence clause.
+
+## A5 — Obligations, deliverables, and milestones
+
+Confirm each material obligation has an accountable party, deliverable or
+performance standard, timing, acceptance mechanism, and remedy where expected.
+Ambiguity is generally FLAG; direct contradictions between obligations and
+schedules are FAIL.
+
+## A6 — Governing law and required provisions
+
+Check governing law, jurisdiction/dispute mechanism, notices, assignment,
+confidentiality/data protection, sanctions/compliance, and any transaction- or
+jurisdiction-specific mandatory wording. Rate only against verified requirements;
+use NA rather than inventing a legal requirement.
+
+## A7 — Amendments, references, and precedence
+
+Verify amendment numbers/dates, recitals, cross-references, annex labels,
+incorporated documents, and order of precedence. Missing or circular references
+that change obligations are FAIL; harmless numbering errors are FLAG.
+
+## A8 — Authority and external corroboration
+
+Verify signatory titles/authority through board resolution, power of attorney,
+company records, trusted e-signature audit trail, or direct counterparty
+confirmation. Rate NA when authority evidence is unavailable. Do not treat a
+company logo, stamp image, or public contact details as proof of authority.
+
+## Decisive validity evidence
+
+A nonexistent party, invalid/broken signature, unauthorized signatory supported
+by primary evidence, impossible execution chronology, missing operative schedule,
+or irreconcilable material terms can independently support `INVALID`.

package/skills/compliance/doc-authenticity/references/bank-statement.md

@@ -0,0 +1,150 @@
+# Bank Statement — Content & Domain Checks (C1–C5, D1–D5)
+
+Detailed procedure for the bank-statement-specific layers. Work from the
+extracted text in `pages/*.txt`; quote row-level evidence.
+
+## Content plausibility (C-checks)
+
+### C1 — Balance arithmetic
+
+The single highest-value check. Parse every transaction row into
+(date, description, debit/credit amount, running balance) and verify:
+
+1. `opening_balance ± each transaction = next running balance`, row by row.
+2. `opening + sum(credits) − sum(debits) = closing`.
+3. Any "money in / money out" summary box equals the transaction sums.
+
+Do this in Python (a throwaway script is fine). Mind the parsing traps before
+declaring a FAIL: negative amounts as `(123.45)` or `123.45 DR` / `CR`
+suffixes; thousand separators and European decimal commas; multi-line
+descriptions that split a row across text lines; statements that list newest
+first (reconcile in reverse). A parsing artifact misread as a balance break is
+the most damaging false positive this skill can make — when a row doesn't
+reconcile, re-read the raw text around it before rating.
+
+A genuine break — especially several rows suddenly offset by the same amount
+(one edited transaction shifts every balance after it, and fabricators forget
+to propagate) — is decisive FAIL evidence. Quote the first broken row, the
+expected vs printed balance, and the offset.
+
+### C2 — Date sequence
+
+- Transactions in consistent chronological order (all ascending or all
+  descending), all inside the printed statement period.
+- Statement period itself sane: start < end, matches the "statement date".
+- Value dates vs posting dates: value date may trail/lead a bit; a value date
+  *months* away from its posting date is an anomaly.
+- Feb 30ths, dates that don't exist, or a period that ends after the file's
+  CreationDate (cross-check F2) → FAIL.
+- Weekend/holiday postings: card transactions post on weekends routinely;
+  BACS/ACH batch credits (salary) on a Sunday is odd but not impossible —
+  FLAG, don't FAIL, and only when it recurs.
+
+### C3 — Transaction plausibility
+
+- Exact-duplicate rows (same date, description, amount) — real duplicates
+  happen (two coffees), so look for *implausible* duplicates: identical
+  salary credits twice in a month, duplicated references.
+- Round-number saturation: fabricated statements over-index on 100.00 /
+  500.00 / 1,000.00. Compute the share of round amounts; > ~40% of rows in a
+  personal account is anomalous.
+- Description/amount coherence: "TESCO STORES" for 4,900.00, a salary line
+  labelled like a card purchase, references that don't match the described
+  counterparty format (e.g. faster-payment references, card scheme suffixes).
+- Copy-paste artifacts: identical timestamps-in-reference across different
+  days, sequential references out of order.
+
+### C4 — Internal cross-consistency
+
+- "Page X of Y" matches actual page count and pages are all present.
+- Account number/sort code/IBAN printed identically on every page.
+- Customer name/address identical everywhere it appears (watch for one
+  respelled instance — a splice trace).
+- Summary boxes (opening, closing, money in, money out) agree with C1's sums.
+- Statement number / period continuity if the user supplied adjacent
+  statements: closing of month N = opening of month N+1.
+
+### C5 — Formatting consistency
+
+Fabricators editing one row rarely match the original formatting exactly:
+
+- Decimal places uniform (no `1,234.5` among `1,234.50`).
+- Thousand-separator style uniform; currency symbol placement uniform.
+- One date in `01/02/2026` among `1 Feb 2026` rows.
+- Column alignment in the raw extracted text: a value whose x-position drifts
+  from its column (the script emits word x-coordinates) suggests re-set text.
+
+## Domain knowledge (D-checks)
+
+### D1 — Account identifiers mechanically valid
+
+Run `scripts/validate_codes.py` with everything extractable:
+
+- **IBAN** — mod-97 checksum, length-per-country. An invalid checksum on a
+  printed IBAN is decisive FAIL (banks do not misprint IBANs).
+- **US ABA routing number** — 9 digits, checksum `3(d1+d4+d7)+7(d2+d5+d8)+(d3+d6+d9) ≡ 0 (mod 10)`.
+- **UK sort code** — format `XX-XX-XX`; the script checks format and known
+  leading-range → bank-group hints, not the private EISCD modulus tables.
+  Format-valid ≠ real; pair with D3.
+- **Account number** — country format (UK 8 digits, etc.).
+
+### D2 — SWIFT/BIC belongs to the named bank
+
+- Format: 8 or 11 chars, `AAAA BB CC (DDD)` — bank code letters, ISO country
+  code, location code. Country letters must match the statement's country.
+- The 4-letter bank code should correspond to the claimed bank (BARC→Barclays,
+  HSBC/MIDL→HSBC, LOYD→Lloyds, NWBK→NatWest, ABBY→Santander UK, CHAS→JPMorgan
+  Chase, BOFA→Bank of America, CITI→Citi, DEUT→Deutsche, BNPA→BNP…). Verify
+  by web search when available; otherwise rate from knowledge and say so.
+- A BIC whose country code contradicts the branch address → FAIL.
+
+### D3 — Bank / branch / address consistency
+
+- UK sort-code leading pairs map to bank groups (e.g. 20–29 Barclays [20s],
+  40–49 HSBC/first direct, 30–39 Lloyds group, 07/08 Nationwide/co-ops,
+  04 challengers/fintechs — Monzo 04-00-04, Starling 60-83-71 under NatWest
+  ranges…). A sort code from bank A on bank B's letterhead → FAIL. Web-search
+  the exact sort code when possible.
+- Postcode/ZIP format valid for the country; branch address city consistent
+  with the branch name.
+- Contact details: phone country code, domain of any printed email/URL
+  belongs to the bank (statement footer URLs on lookalike domains → FAIL).
+
+### D4 — Template & branding match the claimed bank
+
+- Regulatory footer text expected per jurisdiction: UK statements carry
+  FSCS protection wording and "Authorised by the PRA / regulated by the FCA
+  and PRA" + registration number; US statements carry Member FDIC / Equal
+  Housing Lender; EU statements name the local deposit-guarantee scheme. Its
+  *absence* on a full statement is a FLAG; a *wrong* registration number is a
+  FAIL (verify the FCA/FDIC number by search when available).
+- Layout matches the bank's known statement style where you know it (column
+  order, summary-box placement, typography). Check `issuer-profiles.md` for
+  the issuer's typography and its evidence grade — Verified rows can support
+  a FAIL; knowledge-grade rows support at most a FLAG (brand font ≠ statement
+  font). Rate only what you actually know; "I don't know this bank's
+  template" → NA, not PASS.
+- Producer tooling vs bank expectations (ties back to F1): e.g. big
+  retail banks emit composition-platform or server-library producers; a
+  boutique layout claiming a tier-1 bank with a Word producer contradicts D4
+  and F1 together.
+
+### D5 — Address plausibility
+
+- Customer address: real-format street/city/postcode for the country;
+  consistent across pages and with the user-supplied KYC context (if the
+  packet's proof-of-address disagrees with the statement, flag it for the
+  analyst — that's a packet-level finding, not necessarily forgery).
+- Geocode-sanity by knowledge/search: postcode district matches the city
+  (e.g. an "M1" postcode in London → FAIL-grade inconsistency).
+
+## Scoring reminders (bank statements specifically)
+
+- C1 multi-row breaks and D1 checksum failures are decisive validity FAILs;
+  F6 splices on amounts are decisive authenticity FAILs. Together they support
+  `LIKELY_MODIFIED` authenticity and `INVALID` validity.
+- A statement that is a clean scan (F-layer NA) but reconciles perfectly and
+  has valid, mutually consistent identifiers has authenticity INCONCLUSIVE and
+  may have validity VALID. A scan can still depict a fabricated original.
+- When the user names the expected bank, D3/D4 disagreements weigh more; when
+  they don't, an unknown template is NA.

package/skills/compliance/doc-authenticity/references/forensic-signals.md

@@ -0,0 +1,157 @@
+# Forensic Signals — Interpretation Guide (F1–F9)
+
+How to read `forensics.json` and rate each F-check. The recurring theme:
+distinguish **evidence of tampering** (FAIL) from **evidence of an untidy but
+innocent document journey** (FLAG) from **no signal** (NA).
+
+## F1 — Producer / Creator tool
+
+`metadata.producer` and `metadata.creator` name the software that generated
+the PDF. Banks generate statements with **document-composition platforms**;
+fabricators use **desktop editors and web tools**.
+
+**Consistent with a bank (PASS):**
+- Quadient / Inspire, OpenText Exstream, HP Exstream, Smart Communications /
+  SmartCOMM, Messagepoint, Papyrus (ISIS), StreamServe / OpenText StreamServe,
+  Xenos, Elixir, Crawford Technologies
+- Big-bank in-house stacks often show generic library names: iText, Apache
+  FOP, PDFBox, Aspose, BIRT, JasperReports, Eclipse BIRT, XSL-FO processors
+  (AntennaHouse, RenderX XEP), wkhtmltopdf / headless Chromium ("Skia/PDF")
+  — these are server-side generation traces and are normal.
+
+**Editor-associated (FLAG, often FAIL with corroboration):**
+- iLovePDF, Smallpdf, Sejda, PDFescape, pdfFiller, DocHub, SodaPDF, PDF24
+- Adobe Acrobat (as *Producer* on a re-save; banks don't hand-edit statements
+  in Acrobat), Foxit PhantomPDF / PDF Editor, PDF-XChange Editor, Nitro
+- Canva, Photoshop, Illustrator, GIMP — image tools have no business
+  producing a bank statement
+- Word / LibreOffice / Google Docs ("Microsoft® Word", "Writer", "Skia/PDF
+  m… Google Docs renderer") — someone authored this as a document
+
+**Ambiguous (FLAG with innocent explanation, or NA):**
+- "Microsoft: Print To PDF", macOS Quartz PDFContext, browser "Save as PDF" —
+  the classic customer flow: opened online banking, printed to PDF. The
+  original bank metadata is destroyed, not forged. Lean FLAG + note; push the
+  weight onto C/D checks.
+- Scanner strings (ScanSnap, Epson Scan, "TWAIN") — see F7; usually NA here.
+
+Rate FAIL only when the editor trace is corroborated (e.g. editor producer
+**and** incremental updates **and** a font splice), or when the claimed bank's
+statements are reliably known to carry different tooling (see the bank notes
+in `bank-statement.md`).
+
+## F2 — Creation vs modification timestamps
+
+`metadata.creation_date` vs `metadata.mod_date`.
+
+- Equal or mod within seconds of creation → PASS (single-pass generation).
+- ModDate later than CreationDate → someone re-saved it. FLAG, innocent
+  explanations abound (mail clients, previewers, print-to-PDF chains).
+- **ModDate earlier than CreationDate, impossible dates, or dates after the
+  statement was supposedly issued but before it covers** → strong anomaly;
+  FAIL when corroborated.
+- Timezone offsets wildly inconsistent with the bank's country → FLAG.
+- Statement period ends *after* the file's CreationDate → the file predates
+  the data it reports. FAIL. (Check against the period parsed in C2.)
+
+## F3 — Incremental updates
+
+`structure.eof_count`, `structure.xref_sections`, `structure.prev_pointers`.
+A PDF saved incrementally appends a new body + xref; the count of `%%EOF`
+markers approximates the number of save generations.
+
+- 1 EOF → single generation. PASS.
+- 2+ EOFs → the file was modified after creation. What matters is **what
+  changed**: `structure.updated_objects` lists object numbers that appear in
+  more than one generation. Content-stream or font objects updated → the
+  visible page was altered → FAIL. Only metadata/annotation objects → FLAG
+  (e.g. a viewer stamped it opened).
+- Note: a digital-signature workflow legitimately adds a generation (that's
+  how signing works). Cross-check F8 before rating.
+
+## F4 — XMP metadata consistency
+
+`xmp` block: `xmp_toolkit`, `history`, `derived_from`, and agreement with
+docinfo.
+
+- XMP history events (`saved` entries with softwareAgent) narrate the edit
+  chain — an entry with an editor agent after creation corroborates F1/F3.
+- `derived_from` naming another document → this file was built from a source
+  file. FLAG→FAIL depending on what the source appears to be.
+- Docinfo says one producer, XMP says another → the metadata was partially
+  scrubbed or spoofed. FLAG, FAIL with corroboration.
+- Absent XMP entirely: common in minimal server-side generators. NA, not
+  suspicious on its own.
+
+## F5 — Font inventory
+
+`fonts` array: name, subset prefix (6 letters + `+`), embedded flag, per page.
+
+- Bank statements are typographically boring: 1–3 families, consistently
+  subset-embedded. PASS.
+- A family appearing **twice with different subset prefixes** (e.g.
+  `ABCDEF+Helvetica` and `GHIJKL+Helvetica`) means two tools embedded that
+  font — classic edit trace. FAIL with corroboration, FLAG alone.
+- Non-embedded standard-14 fonts (plain `Helvetica`, `Arial`) mixed with
+  embedded subsets → text added by a lightweight editor. FLAG→FAIL.
+- A font present on exactly one page that otherwise matches the others'
+  typography → localized edit. Investigate with F6.
+
+## F6 — In-line font splice
+
+`text_fonts` in the per-page extraction: font name and size per word. The
+smoking gun is a **single value rendered in a different font/size than its
+row** — a pasted-over balance or name.
+
+- Compare each transaction row's amount/balance cells to the column's modal
+  font. One cell differing in font name, or in size by >0.3pt, while the rest
+  of the column is uniform → FAIL, and quote the exact row and fonts.
+- Whole-column or whole-block differences (headers vs body, bold totals) are
+  design, not splices. PASS.
+- Kerning/width anomalies aren't extracted by the script; if the user supplies
+  a rendered image and something looks visually off, say so as a FLAG with a
+  note that pixel-level analysis wasn't performed.
+
+## F7 — Text layer type
+
+`pages[].char_count`, `pages[].image_coverage`.
+
+- Native text, low image coverage → full forensic surface. PASS (as a check,
+  this "passes" when the layer is native — it's about signal availability).
+- Full-page image, no/synthetic text (OCR layer) → scan or flattened export.
+  Most F-checks and F6 go NA. **This alone must not drive the verdict
+  negative** — it drives it toward INCONCLUSIVE unless C/D find substance.
+- Hybrid: native text pages plus one image-only page in the same statement →
+  FLAG; why would page 2 of a digital statement be a picture?
+
+## F8 — Digital signatures
+
+`signatures` block: presence, field name, and whether byte ranges structurally
+cover the file. The bundled script does not verify the signature value,
+certificate chain, revocation status, or trust anchor; it reports
+`cryptographic_validation: not_performed`. Use a trusted signature verifier
+before rating F8 PASS or FAIL.
+
+- A cryptographically valid signature covering the full file from the issuing
+  bank is the strongest possible PASS; this lifts the
+  `NO_EVIDENCE_OF_MODIFICATION` confidence cap (see rubric).
+- Signature present but broken byte range / document modified after signing →
+  FAIL, decisive, only after a signature verifier confirms the failure. A
+  malformed-looking byte range from the extractor alone is FLAG.
+- No signature → NA for most retail statements (banks rarely sign customer
+  PDFs); FLAG only if the claimed issuer is known to sign — check the
+  signature table in `issuer-profiles.md` (Verified rows only) or a verified
+  local sample before flagging absence.
+
+## F9 — Structural anomalies
+
+Grab bag from `structure` and `annotations`:
+
+- **FreeText / Square / Ink annotations** overlapping content → text placed on
+  top of the page. FAIL if over a value, FLAG if marginal.
+- **Redaction annotations** (`/Redact`) → content was masked. FLAG minimum.
+- JavaScript, launch actions, embedded files → not typical of statements;
+  FLAG (and a mild malware caution to the analyst).
+- Broken xref rebuilt by the library, objects claimed but missing, garbage
+  after `%%EOF` → hand-edited or corrupted; FLAG→FAIL with corroboration.
+- `pikepdf` repair warnings surface in `structure.repairs` — quote them.

package/skills/compliance/doc-authenticity/references/image-signals.md

@@ -0,0 +1,114 @@
+# Image Authenticity Signals — Interpretation Guide (I1–I9)
+
+Use these checks for JPEG, PNG, WebP, TIFF, BMP, and other Pillow-decodable raster images.
+The goal is to detect evidence of editing or recomposition, including traces
+from Photoshop and other image tools. No individual metadata or pixel test can
+prove originality: editors can strip metadata, and legitimate messaging or
+export workflows routinely recompress images.
+
+## I1 — Container integrity
+
+- PASS: the decoder accepts the file, declared format matches magic bytes, and
+  the marker/chunk stream terminates normally without unexplained trailing data.
+- FLAG: extension and magic disagree, non-zero payload follows JPEG EOI, or the
+  decoder reports repairable corruption. Innocent causes include transfer damage.
+- FAIL: embedded active payload or a deliberately deceptive polyglot is found.
+
+## I2 — Editor metadata and signatures
+
+Inspect EXIF `Software`, XMP `CreatorTool`/history, IPTC, PNG text chunks, JPEG
+APP13 `Photoshop 3.0`/`8BIM`, APP14 Adobe markers, and raw strings.
+
+- PASS: source-native capture/export tooling is identified and no editor trace exists.
+- FLAG: Photoshop, Lightroom, GIMP, Canva, Affinity, Pixelmator, ImageMagick,
+  or another editor is named. The trace proves tool contact, not a deceptive edit;
+  resizing, color correction, and metadata work are innocent explanations.
+- FAIL: editor history records a material post-capture composite/change and the
+  user requires an unedited original, or editor evidence corroborates a pixel splice.
+- NA: metadata is absent or stripped. Never treat absent editor strings as PASS.
+
+## I3 — Capture-device provenance
+
+- PASS: coherent camera/device make, model, lens, and capture settings are present,
+  or a platform-native screenshot marker is independently verifiable.
+- FLAG: mutually inconsistent make/model/software fields or camera metadata on a
+  purported screenshot. Re-encoding can copy stale metadata, so seek corroboration.
+- NA: device metadata absent. Messaging apps commonly strip it.
+
+## I4 — Timestamp consistency
+
+Compare EXIF original/digitized/modify times, filesystem times, visible timestamps,
+and the claimed event date. Filesystem timestamps alone are weak transfer evidence.
+
+- PASS: embedded capture chronology is possible and agrees with the claim.
+- FLAG: modify time is later than capture, with export or messaging as an innocent cause.
+- FAIL: impossible chronology directly contradicts the claim and is corroborated.
+- NA: no embedded timestamp or no claimed event time.
+
+## I5 — Encoding and quantization
+
+Record baseline/progressive mode, chroma subsampling, JPEG quantization tables,
+quality estimate, PNG chunks, and encoder comments.
+
+- FLAG: unusual or mixed encoder signatures, thumbnail/main-image mismatch, or
+  repeated-save indicators. Social platforms and format conversion are common causes.
+- FAIL only with independent evidence of a material edit.
+- NA when the format or available tooling cannot expose the signal.
+
+## I6 — Recompression / error-level consistency
+
+Open `ela.png` and inspect the numeric tile errors in `image-forensics.json`.
+Compare like regions: text against text, flat background against flat background.
+Naturally detailed edges always produce more error than flat areas.
+
+- PASS: comparable regions have broadly consistent error and no material area is isolated.
+- FLAG: a semantically important region has a sharply different error profile.
+- FAIL: a localized error boundary exactly surrounds altered material and is
+  corroborated by I2, I7, or content inconsistency.
+- NA: lossless source, uniformly flattened/re-exported image, or inadequate resolution.
+
+ELA alone must never produce LIKELY_MODIFIED. A full-image export after editing
+can normalize errors, while an untouched image can have nonuniform errors.
+
+## I7 — Splice, copy-move, and boundary evidence
+
+Inspect material regions at native pixels for hard seams, halos, mismatched blur,
+duplicate texture, inconsistent antialiasing, alignment, perspective, shadow, and
+noise. Automated copy-move matches need manual confirmation because repeated UI
+components and textures create false positives.
+
+- FAIL: a material value/object has a confirmed compositing boundary or duplicated
+  source patch with no plausible scene explanation.
+- FLAG: a visible anomaly is plausible but not conclusive.
+- NA: resolution/compression is too poor for reliable inspection.
+
+## I8 — Sensor, noise, and resampling consistency
+
+For camera photos, compare local noise, demosaicing/CFA behavior, sharpening,
+resampling grids, and depth-of-field. For screenshots, assess raster scaling and
+text antialiasing instead; camera sensor tests are NA.
+
+- FLAG: a material region has inconsistent noise/resampling.
+- FAIL only when localized and independently corroborated.
+- NA when the source type, resolution, or tools do not support the test.
+
+## I9 — Trusted provenance or signature
+
+The bundled script only scans for possible C2PA/JUMBF markers and reports
+`cryptographic_validation: not_performed`; marker presence is not validation.
+Use a trusted C2PA or signature verifier before rating I9 PASS or FAIL.
+
+- PASS: valid C2PA/Content Credentials or another trusted signature covers the
+  file and validates to the expected source.
+- FAIL: provenance exists but fails validation or the protected file was changed.
+- NA: no signed provenance. This is normal and not suspicious by itself.
+
+## Rating reminders
+
+- An editor name proves editor contact, not fraud.
+- Metadata absence means NA, not PASS.
+- A clean marker stream proves only that the current export is structurally clean.
+- A screenshot of a genuine page and a fabricated screenshot can look identical.
+- Prefer the original file from the capture device or source application. Comparing
+  hashes, native exports, adjacent frames, chat exports, or issuer-side records is
+  stronger than analyzing a forwarded JPEG.