grahama1970/anonymize-data

Daten anonymisieren

Betreiben Sie das kanonische oai-trial-Projekt. Duplizieren Sie nicht dessen Matcher, Formatadapter, Verifizierer, Schemata oder Fehlerbehandlung in diesem Skill. Die vorhandene argparse-CLI des Projekts wird absichtlich beibehalten; dieser Wrapper fügt keine Python-CLI oder -Dienst hinzu.

Einrichtung und Hauptbetrieb

ANONYMIZE_DATA_ROOT überschreibt den standardmäßigen primären Checkout oben. Die Einrichtung benötigt uv und installiert die deklarierten Entwicklungs-/Discovery-Erweiterungen des Projekts. Laufzeitoperationen benötigen keinen Speicher, keine Anbieteranmeldeinformationen, kein LLM, kein Netzwerk oder Datenbankdienst.

./run.sh setup
./run.sh --input /data/exports --policy /data/policy.json --output /data/release
./run.sh anonymize --input /data/export.sqlite --policy /data/policy.json --output /data/release

Die Eingabe ist eine .csv-, .json-, .txt- oder .sqlite-Datei oder ein Verzeichnis mit diesen Dateien. Die Richtlinie muss eine separate reguläre Datei sein. Verwenden Sie ein dediziertes leeres Ausgabeverzeichnis außerhalb der Eingaben. Originale werden in einen privaten temporären Schnappschuss kopiert; eine erfolgreiche Ausgabe enthält nur corpus/ und report.json.

Die vorhandene Bündelschnittstelle bleibt verfügbar:

./run.sh run --input /data/bundle --output /data/release
./run.sh verify --input /data/bundle --output /data/release
./run.sh inspect /data/release

Ein Bündel enthält policy.json und corpus/. Die Richtlinie, kanonische Identität, Regeln für geschützte Werte, typisierte Fehler und das Berichtsschema gehören dem Projekt. Lesen Sie dessen README.md, docs/ANONYMIZATION_SEMANTICS.md und schemas/report.schema.json, wenn Sie diese interpretieren. Deklarieren Sie keinen Erfolg allein aus einem Exit-Code: Lesen Sie den tatsächlichen Bericht, validieren Sie seine Bereitschaftsfelder und überprüfen Sie die Ausgabe auf das angeforderte Format. Beschädigte oder fehlende Berichte sind nicht BEREIT.

Optionale RapidFuzz-Erkennung: niemals automatischer Ersatz

./run.sh discover --input /data/exports --policy /data/policy.json --output /data/work/review.json
./run.sh approve-discovery --input /data/exports --policy /data/policy.json \
  --review /data/work/review.json --approve CANDIDATE_ID --output /data/work/approved-policy.json
./run.sh --input /data/exports --policy /data/work/approved-policy.json --output /data/release

Die Erkennung vergleicht ganze strukturierte Zeichenfolgenwerte und ganze Textzeilen mit Richtlinieneinträgen vom Typ name. Es handelt sich nicht um NLP-Spanextraktion oder einen allgemeinen PII-Scanner. Standardwerte: Ähnlichkeitsschwelle 90, Abstandsrand 5; konfigurierbar mit --threshold und --margin. Gleichstände, nahe Gleichstände, geschützte Werte, Werte, die Ziffern oder Identifikationszeichensetzung wie @, /, _ enthalten, sowie bereits bekannte Literale werden nicht vorgeschlagen. Apostrophe, Bindestriche und Punkte sind in namensförmigem Text erlaubt; Ähnlichkeit ist niemals ein Beweis, dass zwei Personen eins sind.

Bitten Sie den Bediener, bestimmte Kandidaten-IDs zu genehmigen. Genehmigen Sie niemals allein aufgrund des Ähnlichkeitswerts. Die Genehmigung leitet die Vorschläge gegen die aktuelle Richtlinie/den aktuellen Korpus neu ab, lehnt veraltete/bearbeitete Überprüfungen ab und erstellt eine exakte Übereinstimmungsrichtlinie. Nicht genehmigte Vorschläge beeinflussen die Anonymisierung niemals. release_ready: false ist bei Erkennungs-/Genehmigungsbelegen zwingend erforderlich.

Überprüfungs- und genehmigte Richtliniendateien enthalten Rohdaten-Namen: Halten Sie sie außerhalb von Veröffentlichungen, Protokollen und gemeinsam genutzten Berichten. Sie werden im Modus 0600 erstellt und überschreiben niemals eine vorhandene Datei. Temporäre Schnappschüsse standardmäßig auf dem Artefaktlaufwerk; überschreiben Sie mit ANONYMIZE_DATA_WORK_DIR, falls erforderlich.

Docker bleibt die eigenständige Schnittstelle

Ab dem Projekt-Checkout:

docker build -t anonymization-trial .
docker run --rm anonymization-trial
# Optionales, erkennungsfähiges Image; das Standard-Image hält die exakte Engine abhängigkeitsfrei.
docker build --build-arg INCLUDE_DISCOVERY=1 -t anonymization-trial:discovery .

Mounten Sie nur die angeforderte Eingabe/Richtlinie schreibgeschützt und ein dediziertes Ausgabeverzeichnis. Die gleiche Projekt-CLI wird im Image ausgeführt; der Evaluator benötigt dieses Skill nicht. Siehe das docs/DISCOVERY.md des Projekts für vollständige Befehlsbeispiele mit Mounts.

Fehler- und Nachweisgrenze

Der Wrapper bewahrt die Exit-Codes und bereinigten Fehlercodes des Projekts. Fehlerhaftes Projekt/Setup und falsche installierte Paketpfade schlagen vor der Verarbeitung fehl. Verwenden Sie --help für den tatsächlichen Argumentvertrag. Die Erkennung ist Überprüfungsmaterial, keine Veröffentlichung, Anonymitätsgarantie, Konfidenzwahrscheinlichkeit oder menschliche Autorisierung.

./sanity.sh führt echte positive, negative und adversarielle CLI-Prüfungen durch. Das beibehaltene fixtures/agentic_eval.json wiederholt diese und erfordert ein Zurücklesen der Artefakte. Eine vorherige Testqualifikation qualifiziert diese nachträglichen Erweiterungen nicht automatisch.

Darstellungsregel (Operator 2026-09-11)

PII muss gegen den Wert abgeglichen werden, nicht gegen die Zeichenfolge: Bevor ein JSON-/SQL-Skalar unverändert durchgereicht wird, stringifizieren Sie ihn kanonisch (telefonförmige Zahlen im E.164-Format) und führen Sie den Richtlinienabgleich auf der stringifizierten Form durch. Fixtures müssen jede PII-Klasse in jedem JSON- Skalartyp enthalten. Eine als ganze Zahl gespeicherte Telefonnummer ist dieselbe Telefonnummer, auch wenn die Richtlinie sie als formatierte Zeichenfolge wie 555-123-4567 schreibt und der Korpus 5551234567 speichert. Anfangsnullen oder präzisionsverlustbehaftete numerische Konvertierungen von Gleitkommazahlen müssen fehlschlagen, es sei denn, eine typspezifische kanonische Regel beweist eine sichere Äquivalenz. Siehe $best-practices-skills "Wertdarstellungsmatrix".

Härtungslektionen (lernen Sie diese nicht auf die harte Tour neu)

Der Test wurde disqualifiziert, weil eine als JSON-/SQLite-Ganzzahl gespeicherte Telefonnummer durch den reine-Zeichenfolgen-Matcher gelangte. Die Ursache war ein Prozessfehler: die Akzeptanzprüfung wurde auf der Grundlage dessen erstellt, was der Code tat, nicht abgeleitet von der gelieferten Spezifikation. Diese Regeln existieren, damit diese Art von Fehlern nicht erneut auftreten kann.

1. Leiten Sie die Prüfung aus der Spezifikation ab, nicht aus dem Code. policy.json listet die exakten vertraulichen Werte auf. Die korrekte Akzeptanzprüfung ist „keiner dieser Werte erscheint in der dekodierten Ausgabe, in keiner Darstellung" — lesen Sie die Werte aus der Richtliniendatei, niemals aus einer manuell erstellten Liste. Beweisen Sie, dass die Prüfung von der Spezifikation abhängt, mit einem Abhängigkeitstest (ändern Sie einen Richtlinienwert → das Ergebnis muss sich ändern). Referenzimplementierung: scripts/spec_derived_check.py des Projekts, eingebunden in scripts/verify.sh.

2. Der unabhängige Verifizierer darf keine Annahme mit der Transformation teilen. Der ursprüngliche Verifizierer hatte dieselbe reine-Zeichenfolgen-Blin​d​stelle wie der Produzent, sodass nichts fehlschlug. Das Verifikationsorakel muss darstellungsbewusst und unabhängig sein: JSON parsen (\uXXXX dekodieren), numerische Skalare auf ganzzahlige/dezimale Formen erweitern, beide Seiten NFC/NFD-normalisieren, SQLite-Tabellen+View-Zellen UND sqlite_master-DDL UND jeden Header- Ganzzahlwert scannen und die gesamte freigegebene Grenze einschließlich report.json scannen — nicht nur corpus/.

3. Die vollständige Darstellungsklasse ist eine Checkliste, kein einzelner Fehler. Jede dieser kann einen vertraulichen Wert an einem naiven Matcher vorbeitragen; das Projekt behebt und behält eine Wächterfunktion für jede bei: typisierte numerische Skalare (int/float, wissenschaftliche Notation), SQLite BLOB (fail-closed), Unicode NFC/NFD, View- Rekonstruktion, Freelist-Residuen, feindliche DB-Schemata (Ausdrucks-/Teil- Indizes, nichtdeterministische Views, berechnete DEFAULTs), Schema-DDL-Literale und persistente Header-Ganzzahlen. Siehe docs/SECURITY_REMEDIATION.md des Projekts für die vollständige Tabelle.

4. Beweisen Sie es über den echten Docker-Pfad, deterministisch. Verifikation muss ein festgeschriebenes Skript sein, das das Image erstellt, die genauen Befehle der Anweisung ausführt und die freigegebenen Bytes mit harten PASS/FAIL-Exits zurückliest — kein Agententext. Referenz: security/docker_brief_contract.py (Erstellung + beide Befehle der Anweisung

   • darstellungsbewusster Leck-Scan + Eingabevorbedingung) und security/docker_hardening_matrix.py (adversarielle Löcher durch docker run). Notieren Sie den Git-Commit und die erstellte Image-ID.

5. Umfang ehrlich angeben. Deterministische Pseudonyme aus öffentlichen Namensräumen legen Gleichheit/Häufigkeit offen und bieten keinen Widerstand gegen externe Verknüpfungen; der Ausführungsbericht gibt dies in key_mode und does_not_establish an. Ein Richtlinienwert gleich einer obligatorischen SQLite-Formatkonstante ist eine degenerierte Eingabe, keine echte PII; die Pipeline schlägt darauf fehl, und dieser Rückstand wird als eingegrenzt dokumentiert.