Data quality & reconciliation with exception

Reconciles data sources using stable identifiers (Pay Number, driving licence, driver card, and driver qualification card numbers), producing exception reports and “no silent failure” checks. Use when you need weekly matching with explicit reasons for non-joins and mismatches.

Security Scan

The skill's instructions, files, and requirements are coherent with its stated purpose (data reconciliation and exception reporting); it is instruction-only, requests no credentials, and has no install steps.

Purpose & Capability

Name/description describe reconciliation of datasets by stable IDs and the provided SKILL.md, matching-rules.md, and CSV template all implement that workflow. The skill requests no binaries, env vars, or installs — consistent with a guidance/template skill that operates on user-provided CSV/XLSX files.

Instruction Scope

Runtime instructions focus on mapping, normalization, key validation, joins, exception categorization, and stop-and-ask gates. They explicitly require user-provided datasets and do not instruct reading unrelated system files, environment variables, or contacting external endpoints. The guidance to be read-only by default limits destructive actions.

Install Mechanism

No install spec and no code files are included; this is an instruction-only skill. That minimizes the surface for arbitrary code execution or supply-chain risk.

Credentials

The skill declares no required environment variables, credentials, or config paths — proportional for a documentation/plan-style reconciliation skill. Note: the skill is designed to process sensitive PII (pay numbers, licence numbers etc.), so operational data-handling controls are important even though the skill itself requests no secrets.

Persistence & Privilege

always is false and the skill does not request persistent system privileges. Autonomous invocation (model invocation enabled) is the platform default and reasonable here; nothing indicates the skill needs elevated or permanent presence.

Assessment

This skill appears coherent and low-risk from a packaging perspective, but it will be used to process sensitive identifiers (pay numbers, driving licence/card numbers). Before using: 1) ensure datasets you provide are allowed to be processed by the agent and comply with your data-protection rules (consider anonymizing or using synthetic data for testing); 2) confirm where exception reports are written and that storage/access controls are appropriate; 3) verify the agent's runtime will not upload data to external services you don't control; 4) test the matching rules on a small sample to confirm the join priority and thresholds behave as expected; 5) if you need automated remediation, update the SKILL.md to document safeguards — otherwise keep it read-only and require explicit approval for any edits. If you want stronger assurance, request an implementation (code) that you can review or run in an isolated environment.

Data quality & reconciliation with exception reporting and no silent failure

PURPOSE

Reconciles data sources using stable identifiers (Pay Number, driving licence, driver card, and driver qualification card numbers), producing exception reports and “no silent failure” checks.

WHEN TO USE

• TRIGGERS:
  • Reconcile these two data sources and produce an exceptions report with reasons.
  • Match names and payroll numbers across files and flag anything that does not join.
  • Build a ‘no silent failure’ check that stops the pipeline if counts do not match.
  • Create a weekly variance report for missing records, duplicates, and date gaps.
  • Design a data quality scorecard with thresholds and red flags.
• DO NOT USE WHEN…
  • You need open-ended fuzzy matching without acceptance criteria.
  • There are no stable identifiers in any source.

INPUTS

• REQUIRED:
  • At least two datasets (CSV/XLSX) with Pay Number and/or driver document numbers.
  • Which fields must match (e.g., Name, expiry date).
• OPTIONAL:
  • Normalization rules (case, spaces, punctuation).
  • Thresholds for gates/scorecard (max % missing, etc.).
• EXAMPLES:
  • Payroll export + compliance register
  • Two weekly exports from different systems

OUTPUTS

• Reconciliation plan (matching rules, normalization, join strategy).
• Exceptions report spec (CSV columns + reason codes) and variance checks.
• Optional artifacts: assets/exceptions-report-template.csv + references/matching-rules.md. Success = every record is categorized (matched/missing/duplicate/mismatch/invalid) with an explicit reason; pipelines stop on anomalies.

WORKFLOW

1. Confirm sources and key priority (Pay Number → Driver Card → Driving Licence → DQC).
2. Normalize columns:
   • trim spaces; standardize case; strip common punctuation for document numbers.
3. Validate keys:
   • flag blanks/invalid formats; identify duplicates per source.
4. Join:
   • exact join on Pay Number; then attempt secondary joins only for remaining unmatched items.
5. Produce exception categories with reasons:
   • Missing in A/B, Duplicate key, Field mismatch, Invalid key.
6. “No silent failure” gates:
   • counts within tolerance; unmatched rate below threshold; duplicate spikes flagged.
7. STOP AND ASK THE USER if:
   • columns are not mapped,
   • multiple competing IDs exist with no priority,
   • expected tolerances are unspecified.

OUTPUT FORMAT

exception_type,reason,source_a_id,source_b_id,pay_number,name,field,source_a_value,source_b_value

Reason codes: MISSING_IN_A, MISSING_IN_B, MISMATCH, DUPLICATE_KEY, INVALID_KEY.

SAFETY & EDGE CASES

• Read-only by default; don’t auto-edit source data. Route exceptions to review.
• Deterministic matching rules first; avoid fuzzy matching unless explicitly requested.
• Always produce an exceptions report; never drop unmatched rows.

EXAMPLES

• Input: “Payroll vs compliance; match by Pay Number; flag name mismatch.”
  Output: join plan + mismatch reasons + exceptions report schema.

• Input: “Some rows have blank Pay Number.”
  Output: secondary key matching + invalid-key exceptions for truly unmatchable rows.