privacy-claims-field-classifier

Classify observed data fields against privacy and encryption claims in an evidence-backed field matrix.

2|Updated May 6, 2026
One-click install
npx skills add https://github.com/bpcakes/jig-skills --skill privacy-claims-field-classifier-bpcakes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: privacy-claims-field-classifier
Source: https://github.com/bpcakes/jig-skills/tree/main/plugins/jig-privacy-audit/skills/privacy-claims-field-classifier
Command: npx skills add https://github.com/bpcakes/jig-skills --skill privacy-claims-field-classifier-bpcakes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Products often claim "end-to-end encrypted", "zero knowledge", or "not logged", but verifying those claims requires tracing every field through code, storage, logs, and traces. This Skill maps observed fields to those claims and classifies each one with evidence, exposing plaintext leakage that contradicts the stated privacy model. ## Core Features & Use Cases - Field Classification Matrix: Assigns each observed field one of five classes (encrypted_content, encrypted_metadata, plaintext_operational_metadata, avoidable_plaintext_leakage, unknown) with evidence references, confidence, and retest actions. - Multi-Surface Evidence Collection: Guides inspection of schemas, DB migrations, crypto call sites, logs, traces, analytics, HAR captures, and sentinel/differential tests to link the same field across surfaces. - Findings with Severity: Emits findings using a shared schema with PCFC-prefixed ids and severity mappings from critical to informational. - Use Case: While auditing a notes app that claims zero-knowledge encryption, you discover note titles appear in plaintext in server logs and search indexes; the matrix records each field, its readers, and the claim conflict as a high-severity finding. ## Quick Start Ask the agent to map the fields in this repository against the product's end-to-end encryption claim and produce a privacy field matrix with findings.

Frequently Asked Questions about privacy-claims-field-classifier

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify an end-to-end encryption claim in a codebase?

Trace each field from creation through serialization, encryption, transport, storage, and logging, then check whether server-side artifacts contain recoverable plaintext. TLS alone does not prove field-level encryption; keys must be unavailable to the audited server or operator.

How to detect plaintext leakage in logs and traces?

Run sentinel tests with unique content values, exercise sync, search, share, and error flows, then search logs, traces, analytics, and crash reports for exact, encoded, truncated, or hashed forms. Secrets, tokens, and user content in any of these sinks are findings.

What is the difference between encrypted content and encrypted metadata?

Encrypted content means user-authored payloads are ciphertext before reaching the server. Encrypted metadata means titles, sender info, thumbnails, or relationship data are also hidden from the service beyond what routing requires; many protocols encrypt content while leaving metadata visible.

When should a field be classified as unknown instead of passing?

Mark unknown when only generated code or type names exist, key ownership is unverified, no runtime artifacts were captured, or redaction cannot be distinguished from plaintext. Unknown is not a pass; list the missing artifact or test under Open Evidence Needed.

What are the limitations of static privacy review?

Static review cannot prove runtime encryption or the absence of plaintext in unseen environments, and sentinel absence only shows the tested value was not found. Key custody, recovery flows, server-side rendering, and third-party SDKs can change classification.