Back to buildsBUILD RECORD

Campaign Record Validator / Campaign validation tooling / 2026

Checking that campaign approvals still match the selected media.

A Python CLI rebuilds approval fingerprints from current campaign fields and verifies the pinned release and creative, exposing disagreement across the local records.

Confidential work. Names and identifying business details have been changed.

ROLE
Software engineering
STATE OF THE BUILD
In progress
RECORD UPDATED

THE WORK

The project.

Campaign Record Validator checks whether a campaign's current settings, selected creative and recorded approval still describe the same material. It rebuilds the fingerprint input from the campaign, canonicalizes the JSON and compares its SHA-256 with the approval and confirmation records. A supplied hash can't pass just because it is mathematically correct for some different input.

The CLI also follows the exact Asset Release Registry manifest and selected creative through an implemented local file integration. That connects the campaign's references to the release and media hashes they name. This anonymized case study covers local validation, not platform operation: the tool reports inconsistent records, and reconstructed audit fingerprints must explicitly disclaim new publication or reuse authority.

IMPLEMENTATION

Design choices.

  1. The checker rebuilds the material before checking its hash. Hash equality is useful only when the approval file contains the same release, creative and campaign fields the checker expects now.
  2. The manifest and selected creative are both pinned. The release record and media bytes both contribute to identifying the material; a changed discovery pointer shouldn't silently substitute another asset.
  3. Reconstructed fingerprints have an explicit scope. They can support a consistent later account, but must state that they don't prove a pre-existing fingerprint or grant another publication or reuse decision.
  4. Schemas check individual shape; Python functions check cross-file relationships. A valid record can still disagree with its companion files, and an orderly event sequence still isn't immutable history.
  5. Campaign review records stay separate from accounting and private platform identifiers. This tool checks its local records and references; it doesn't become the accounting ledger or a platform operator.

HOW IT FITS TOGETHER

Architecture.

  • The registry derives campaign and review paths from stable keys and resolves them inside the workspace. A supported schema subset checks each record's shape before dedicated Python functions compare facts across files.
  • Fingerprint validation rebuilds the expected material from current campaign fields. It sorts object keys recursively, preserves array order and hashes compact UTF-8 JSON with SHA-256, giving comparisons a consistent representation.
  • The media reader follows the exact Asset Release Registry manifest and selected creative. It compares release identity, asset identity, filename and content hash, rather than treating a mutable current-release pointer as sufficient identification.
  • Approval and event checks reconcile the campaign with companion files, including fingerprint type, algorithm and reconstruction status. Event checks also require file-ordered contiguous sequence numbers, unique IDs and the matching campaign identity.
  • Platform identifiers belong in a designated private file. Field and text scans reject obvious sensitive material outside it. Validation returns errors or a local result; the script contains no platform client or write operation.
Explore the architecture map9 components · 12 connections

Campaign validation across records, releases and approvals

The checker compares campaign records with release files and approval evidence, then returns errors or a success status.

Direct callResponse / returnBlocked / denied
Local input records
Read-only checks
CLI result

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (12)
  1. 01 · Campaign registry and records → 04 · Schema and registry checksload local records · Direct call
  2. 04 · Schema and registry checks → 05 · Media identity checksselected references · Direct call
  3. 02 · Pinned asset release → 05 · Media identity checksmanifest and creative bytes · Response / return
  4. 01 · Campaign registry and records → 06 · Cross-record consistencystate and events · Direct call
  5. 03 · Approval evidence → 06 · Cross-record consistencyapproval material · Direct call
  6. 05 · Media identity checks → 06 · Cross-record consistencyasset check outcomes · Response / return
  7. 06 · Cross-record consistency → 07 · Sensitive-data scancontinue repository checks · Direct call
  8. 04 · Schema and registry checks → 08 · Failing exit statuscollect schema or path error · Blocked / denied
  9. 05 · Media identity checks → 08 · Failing exit statuscollect identity error · Blocked / denied
  10. 06 · Cross-record consistency → 08 · Failing exit statuscollect record mismatch · Blocked / denied
  11. 07 · Sensitive-data scan → 08 · Failing exit statussensitive material found · Blocked / denied
  12. 07 · Sensitive-data scan → 09 · Local consistency reportall checks free of errors · Response / return

MADE WITH

Python · JSON Schema · JSONL · SHA-256 · Decimal · CLI

ACCESS & INPUT

Security controls.

  • Field and text checks look for obvious credentials, payment-card material and long platform identifiers outside the designated private file. These are limited detectors, not proof that every sensitive value is absent.
  • The checker derives expected approval material from the current campaign before comparing fingerprints. Changed fields can't pass solely by retaining an old hash or supplying a valid hash for different material.
  • The script doesn't call an advertising platform or alter records. Its unkeyed hashes don't authenticate a human decision, and someone with enough file access could rewrite the records and hashes together.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

  1. Code and development records reviewedReviewed

    The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

    Scope of this check
    Code review, not a fresh run of the app

NEXT

Still to work through.

The validator makes changed inputs and contradictory records easier to identify, but matching files can't prove who approved them or when. Synthetic cases for changed creatives, altered approval fields and incorrect event order are still needed. This account uses the schema and validator source only: campaign records, media and external accounts were excluded, and the validator and tests weren't run.

FROM THE SAME WORK

Technical note

What an approval fingerprint can say about changed inputs