Skip to content
Portfolio/Capabilities

CAPABILITY 10 / 30

Pictures of prices became verifiable text

Parse, join to the authority, render, then verify every figure independently.

IN PRODUCTION

This runs in client systems today. The sample below was regenerated for a fictional company.

Partner price lists arrive as flat documents nobody can search or check. This rebuilds them: repairs the extraction, matches every row to an authoritative catalogue, renders a clean sheet, and then re-reads the output and compares it back to the authority figure by figure. If anything disagrees, the build stops.

TRY IT / RUNS IN YOUR BROWSER

Use it here.

The mechanism is the production one. The company, the catalogue, and every figure are fictional.

Price list rebuild

A flat price list goes in. Text that agrees with the catalogue, cell by cell, comes out.

A partner sends a price list as a flat document. Nobody can search it, and by the time it arrives some of the prices are out of date. This rebuilds it: repair what the extraction broke, match every row to the catalogue, write the catalogue's own figures out, then check the result back against the catalogue with a separate reader that shares nothing with the step that produced it.

The extraction step here reads a prepared fixture rather than running document recognition in your browser. Everything after it, the repair, the join, the render and the verification, is the real mechanism running on this page, on the same two files the build ran against.

Reading the sheet and the catalogue.

    Row inspector

    The rules that made the changes

    THE OUTPUT / GENERATED FOR APEX INSTRUMENTS

    What comes out.

    CSV
    The catalogue the rebuild has to agree withData · 440 rows: sku, item, category, list_price, partner_price, uom, effective_date. This is the only source of truth for a price. 36 of these rows never appear in the output, because the partner sheet did not carry them, and the verification stage says so by name.Open the file ↗
    JSON
    The run, in fullData · Per stage counts, all 19 rules with what each one does and how often it fired, all 820 corrections with the line, the field, the before value, the after value and the rule that made it, every unmatched row with its reason, the 36 catalogue rows missing from the output, the 5 codes the catalogue does not have, and the verification result including the corruption drill.Open the file ↗
    MJS
    The pipeline, four named stagesData · Node ESM, no dependencies. Reads the fixture, runs parse, join and render, writes each stage's output, then re-reads the written output and the catalogue back off disk before verifying them. Exits non-zero if anything disagrees. The block between the two PRICE REBUILD CORE markers is pure JavaScript and is what widget.html runs; node rebuild.mjs --sync-widget copies it across and verify.mjs asserts the two copies are identical.Open the file ↗
    JSON
    The sheet as the extraction step handed it overData · 420 rows with a line number and six cells each. This is the one prepared part of the demonstration: it stands in for a 14 page flat document, so nobody has to run document recognition in a browser. Everything downstream of it is real.Open the file ↗
    JSON
    The rebuilt price listData · 404 rows with the catalogue's sku, item, category, list price, partner price, unit and effective date, plus the sheet line each row came from and how it was matched. This is the file the verification stage re-reads.Open the file ↗
    JSON
    Stage 1 outputData · 422 records: the 420 lines in, plus the two extra products recovered from the merged lines, each with its repaired values and the events that produced them.Open the file ↗
    JSON
    Stage 2 outputData · Every match with its method and confidence, and every unmatched row with the reason it could not be identified.Open the file ↗
    MJS
    The fixture generatorData · Seeded, so both input files are reproducible. Every defect is derived from the true catalogue value by a named function, which is what lets the pipeline's repairs be checked against the number they were meant to reconstruct rather than taken on trust.Open the file ↗

    THE MECHANISM / SHOW THE SHAPE, NOT THE SOURCE

    How it works.

    What a skill is
    1. 01Parse

      Mechanical extraction damage is repaired by named rules. What cannot be repaired is marked.

    2. 02Join

      Every row is matched to the authority by code, then by name, with the method and confidence recorded.

    3. 03Render

      The output is written with the authority as the source of truth for every price.

    4. 04Verify

      A separate pass re-reads the output and compares every figure back to the authority.

    5. 05Report

      Corrections, unmatched rows, and missing products are all listed, not summarised away.

    WHAT IT READS

    • The incoming list, however it was extracted
    • The authoritative catalogue
    • Repair rules with a reason each
    • A verifier that does not trust the renderer

    WHAT IT CHECKS BEFORE IT SHIPS

    • Every printed figure is compared back to the authority
    • A correction names the rule that made it
    • Rows the authority does not have are reported, never invented
    • A mismatch fails the run instead of shipping
    In production: a rebuild of 1,107 rows produced 223 corrections, and every one verified clean.

    The mechanism runs inside client systems. Everything on this page was regenerated for Apex Instruments, a company that does not exist. Client names, source files, and internal wording stay private.

    What it producesWhat is being built next