data-reconciliation-exceptions

Reconciles data sources using stable identifiers (Pay Number, driving licence, driver card, and driver qualification card numbers), producing exception repor...

Security Scan

The skill is an instruction-only reconciliation helper whose requested inputs and included artifacts match its stated purpose and it does not ask for credentials, installs, or unexpected permissions.

Purpose & Capability

The name/description, SKILL.md, and the two included reference files all describe the same reconciliation task (matching by Pay Number and secondary document numbers, producing exceptions). There are no extra environment variables, binaries, or unrelated requirements that would be inconsistent with the described purpose.

Instruction Scope

Runtime instructions are narrowly scoped to normal reconciliation steps (normalize, validate keys, join, produce exception reports, stop-and-ask gates). The SKILL.md does not instruct the agent to read unrelated system files, environment variables, or contact external endpoints. It explicitly recommends read-only behavior and stopping for ambiguous cases.

Install Mechanism

No install spec and no code files are present (instruction-only). Nothing will be written to disk or downloaded by the skill itself, minimizing install risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. The reconciliation task legitimately requires access to input datasets (CSV/XLSX) but nothing else is requested.

Persistence & Privilege

always is false and the skill does not declare persistence or attempt to modify other skills or system-wide settings. Model invocation is enabled by default (normal) but without additional privileges or credential access this is not a concern.

Assessment

This skill appears coherent and instruction-only, but it will need access to whatever CSV/XLSX files you want reconciled. Before installing or running: (1) confirm the agent/process will only be given the datasets you intend to share (these files contain sensitive PII like pay numbers and driving licence numbers); (2) run the skill on a small anonymized sample first to verify outputs and reason codes; (3) ensure your environment or agent connector will not exfiltrate data to external services; and (4) review and adapt the exception reason codes and stop-gates to match your operational tolerances. If you require formal data-handling guarantees (retention, logging, audit), verify those at the platform/connector level because the skill itself does not enforce them.

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.