Atlas Proofing Pipeline
Keeping a proofing result tied to the pages and reference data it checked.
Innovation & Strategy Analyst · Atlas contributor · 2026 · V2 contributions in August
I built durable processing, matching evidence and partial-result handling for Atlas’s print-proofing workflow.
In sixty seconds
I built durable proofing jobs, matching evidence and partial-result handling for a workflow used since January.
- was
- A reviewer compares a print proof with its reference data.
- now
- Snapshotted inputs, persistent jobs and explicit partial results keep findings tied to the work performed.
- the decision
- Freeze inputs and give workers bounded ownership; keep findings separate from coverage.
- the run
- Print Proofer demo →
- where it sits
- the map →
Opened · The proof and its reference
A reviewer needs to know what the PDF says and what it was supposed to say.
Atlas compares a print proof with reference data and presents page findings for review. Proofing has been used since January 2026, according to my account of the workflow. This study follows my later V2 processing and matching contributions: how a result stays tied to its inputs, and what a reviewer sees when only part of a job succeeds.
A plausible model response is only one part of a usable result.
Blocked · Work that outlives the request
An interrupted run still needs a record of what finished.
A browser request is a poor home for long-running page processing. Workers can stop, references can change, and the model can omit a page or contradict its terms evidence. I needed execution state that survived the request and validation that distinguished a document finding from a result we could not trust structurally.
The job needed its own identity and state.
Reassigned · Freeze inputs; bound ownership
I separated the inputs, the worker’s ownership and the evidence it returned.
I added a persistent job API and a planner, worker and finalizer flow. Jobs snapshot the proof and decoder reference with their generations, hashes and configuration. Transactional leases give each batch bounded ownership; committed batches can be reused when their input identity matches. This adds storage and recovery logic, but makes interrupted work inspectable.
Stable inputs make recovery meaningful; contracts make results usable.
In progress · Evidence with its gaps intact
Page 1 of 8 read against the merchant grid, 0 for a person.
the grid · Northeast · Week 03 · Jan 20
- Orchard Subs
- Harbor Grill
- Summit Burger
for a person0
- Nothing yet.
Scripted simulation on an invented mailer. The technical walkthrough below illustrates V2 failure handling.
Useful page findings survive a partial failure, with the error still visible.
The processor validates result structure and page coverage before reconciling batches. I changed the report path to preserve successful merchant and terms evidence when a job retains errors. Matching adds candidate evidence and ambiguity states; a common national merchant alone cannot establish a local assignment. Geographic influence is opt-in, with shadow evidence available without changing assignment.
One decisionSnapshots distinguish changed inputs from retries. Leases and committed-result replay reduce conflicting work, but do not guarantee exactly-once model calls.
What brokeA required terms clause returned as not_applicable could fail the whole batch. I normalized that contradiction to a failed page check and recomputed its outcome, while keeping malformed schema and missing coverage strict.
When it breaks
- A worker loses its lease
- the system It cannot commit under expired ownership; eligible unfinished work can be claimed within the attempt limit.
- seen by Job state and the reviewer’s report
- Some page ranges fail
- the system Retain successful results and failed-range errors. Complete coverage is required for a fully completed result.
- seen by The reviewer
- Selected inputs change
- the system Compare the selection with stored input identity before reusing a job.
- seen by The reviewer resuming work
Coverage and findings have to remain separate answers.
Closed · The merged implementation
Durable execution and explicit partial results are the demonstrated change.
My merged contributions establish the implementation trail for snapshots, worker ownership, matching evidence and partial-result presentation. The inspected V2 test source covers leases, cancellation, contradictory terms and missing coverage. January proofing use does not date the V2 rollout, and I do not present a measured accuracy rate or monthly savings here. The legacy verifier has different failure behavior.
The next result to measure is what reviewers can reliably accept.
Next
Do again
Make a result explain what ran, what it used and what remains unresolved.
I would evaluate false passes, false flags and unresolved pages on a labeled document set, then measure the review work around the run. This is the kind of operational AI engineering I want to keep doing.
Execution and failure walkthrough
Simplified implementation diagram. The examples below are synthetic, manually selected scenarios; they do not run Atlas or reproduce a production incident.
- 1Authorize user and team
- 2Snapshot proof and reference
- 3Plan ranges and lease batches
- 4Read pages and validate contracts
- 5Reconcile coverage and errors
- 6Present findings for review
Synthetic walkthrough · Interrupted batch
- Input
- Synthetic proof: 6 pages. Pages 1–3 committed; pages 4–6 unfinished.
- Failure or finding
- The worker for the second range stops before committing.
- Implemented response
- After its lease expires, eligible unfinished work can be claimed within the attempt limit. A committed batch can be replayed only with matching input identity.
- Limit
- A retry may call the model again. This is not an exactly-once guarantee.
System diagrams · Carl Illustration Engine
Static implementation models, with no runtime telemetry. Expand a view to inspect its branches; scroll wide diagrams sideways or open the SVG at full size.
Proofing matching: identity evidence and ambiguity
Proofing V2: inputs, execution and result coverage
Proofing V2: retry, changed inputs and terms contradictions
Broader contribution history
Selected source-reviewed contributions from distinct revisions. Diagrams and walkthroughs use abstract or invented inputs.
The reference data is also an engineering workflow
My proofing contributions start before a page is checked. The earlier history includes decoder generation, merchant classification, logo preparation, report export, TypeScript migration and wizard decomposition. Those changes improve different parts of the workflow. They are not repeated evidence of the same V2 result.
In the selected September merchant mapper, target stores are resolved against a master catalog and optional supplemental data. Supplemental store IDs take priority over master IDs, followed by brand resolution. A brand with competing logo URLs can remain ambiguous; a clean master brand can recover an ambiguous supplemental match.
Identity is the first boundary.
I also contributed a filename-collision rule: rows losing a collision have their output filename cleared and enter review. A single-store brand match is flagged separately. The generated review rows expose those conditions; I do not describe them as a universal approval gate that blocks every download or delivery action.
Inspect: Merchant preparation and separate delivery outcomes
The selected delivery path can generate or update Decoder and Missing Merchant Sheets, then attempt logo batches in Drive. The one-click interface sequences those actions. It does not create a transaction spanning Sheets and Drive. Per-logo saved, skipped and failed counts remain meaningful when only part of delivery finishes.
A mapping result and a delivered asset are different records.
The selected mapper retains owner-scoped run results and exposes missing brands, collisions and review rows. Its authored tests exercise matching and delivery contracts, but I did not run an employer provider workflow here. These September changes do not revise the earlier V2 job specification by implication.
A second print-review contract
My later source-code QC contribution uses a different reference: filtered ship-tracker rows. It extracts proof units from PDF text and compares source codes, printed URLs and placement expectations. Findings retain proof-page and tracker-row references so the reviewer can locate a mismatch.
The contract needs more than a matching code.
In the inspected September revision, empty expected groups or extracted proof units block the comparison. Missing or unapproved placement formats require review. A matched group can still have URL, duplicate-code or placement findings, and warnings affect the auto-cleared count. Those states keep incomplete extraction from becoming an implied print approval.
Inspect: Expected codes, extracted evidence and reviewer handoff
Release evidence needs its own review.
I later added the reviewer-action packet to the saved handoff set and its content checks. That contribution makes proposed fixture review and scale decisions inspectable. A generated packet or a passing content check does not establish that a reviewer signed off, that the feature was released, or that a real print sample met the contract.
I would demonstrate the difference with an invented tracker containing two expected codes. One proof matches; the other uses a format without an approved placement rule. The walkthrough should retain the review state rather than declare the whole mailer ready. An empty extracted proof set should remain blocked.
The fixture must preserve partial outcomes.
For the merchant walkthrough, I would use invented stores with one exact ID match, one ambiguous brand and one filename collision. I would then reconstruct a successful Sheet operation alongside a failed logo upload. The output should expose both outcomes. No real customer files or provider writes are needed to explain the recovery problem.
How the contribution developed
My captured merged history moves from decoder/export and UI repairs through runner decomposition and asynchronous processing, then into durable V2 evidence and later merchant preparation and source-code QC. The complete chapter history retains the smaller fixes, rollback, closed proposal and release/test changes. Dates and merge states describe the contribution trail; they do not establish continuous deployment or measured accuracy.
The interview question I would prepare for is why the evidence contract changes between these workflows. Merchant preparation resolves reference assets. V2 checks document pages against frozen references. Source-code QC compares extracted units with tracker expectations. Each needs its own coverage, ambiguity and human-review boundary.
Explore all Atlas contributions →Ask me about
- Does complete coverage mean the proof is correct?
- No. Coverage validates that the expected pages are represented. It does not measure whether the model read them accurately or whether the document is acceptable.
- What authorizes access to a V2 job?
- The application establishes user and team scope and checks ownership on the job API. A job identifier alone is not authorization.
- What happens if every batch fails?
- The aggregator records a failed job rather than publishing an empty successful manifest. The interface also rejects an empty completed result.
Built with
Hire me
I'd build this for your team.
I am looking for an applied-AI engineering role at a company with real operations to automate. The résumé is one page.