Someshwara SoftwareRequest a discovery call
← Back to the receiving demonstration

Engineering evidence · Synthetic structured data

A check you can inspect.
A result you can reproduce.

The receiving demonstration uses a deterministic validation component. This report compares its output with independently specified expected outcomes for a small, fixed set of carton-quantity cases.

Evaluated 3 October 2026Dataset 1.0.0Engine 1.0.0
Try the checks Download the results (JSON)

What this run measured

Expected behaviour.
Compared with actual output.

Each fixture defines the expected status, totals, discrepancy and field-level issues. A case passes this evaluation only when those outputs match. A document correctly sent for review is a successful test outcome.

Fixtures matching expectations
12 / 12
Expected to clear the checks
3
Expected to need review
9

This measures the validation component on these fixtures. It does not measure AI extraction accuracy, real-world document coverage, staff time saved or a production integration. Sample edits and local approval are not durable operational records.

Results for the fixed synthetic test set
CaseProduct A / B / printed totalExpected routingMatches expected output
Totals match"60" / "40" / "100"Checks passedYes
Quantity mismatch"60" / "40" / "98"Review requiredYes
Missing quantity"60" / (missing) / "100"Review requiredYes
Missing total"60" / "40" / (missing)Review requiredYes
Negative carton quantity"-5" / "40" / "35"Review requiredYes
Fractional carton quantity"60" / "40.5" / "100"Review requiredYes
Quantity includes text"60 cartons" / "40" / "100"Review requiredYes
Surrounding whitespace" 60 " / "40" / " 100 "Checks passedYes
Explicit zero is present"0" / "40" / "40"Checks passedYes
Scientific notation blocked"6e1" / "40" / "100"Review requiredYes
Quantity exceeds demo limit"1000001" / "0" / "1000000"Review requiredYes
All counts missing(missing) / (missing) / (missing)Review requiredYes

Inputs are whole carton counts. The downloaded results include expected and actual values, issue codes and individual pass/fail outcomes. Case coverage is finite; additional customer rules need their own fixtures.

Method and boundaries

Know what the
evidence covers.

Two fixed synthetic product lines and a printed carton total. Expected statuses, totals, discrepancies and issue codes are handwritten independently of the validator.

Checks in the component

  • Require both line quantities and a printed total; whitespace-only values are missing.
  • Accept digits-only whole counts including zero. Reject negatives, decimal notation, text, signs, formulas and scientific notation; surrounding whitespace is trimmed.
  • Each count must be a safe integer from 0 to 1,000,000.
  • Compute the line-item sum and its signed difference from the printed total only when the required counts are valid; any difference blocks approval.

What remains outside this test

  • These 12 authored synthetic cases test a deterministic validation component, not AI extraction accuracy, real documents or customer outcomes.
  • A fixture pass means the actual status, totals, discrepancy and issue field/code pairs match its handwritten expectation. Review-required cases are expected successful test outcomes.
  • Coverage is limited to two whole-carton quantities and one printed total. Item identity, units, document authenticity, physical delivery, duplicates, taxes and purchase-order matching are not checked.
  • The local approval checkbox is a demonstration, not an authenticated identity, durable audit trail or production authorization control.
  • No model, upload, API, WMS/ERP integration, throughput benchmark, latency measurement, ROI estimate or production SLA is included.
  • The handwritten examples are not a representative or held-out customer data set; passing them does not establish general production reliability.

Inspect or reproduce the run

Download the cases and results, or run the standalone JavaScript file locally with Node.js. The runner contains the compiled validation component and the fixed expected outcomes; it needs no network connection.

node receiving-validation-reproduce.mjs
Test cases (JSON) Evaluation results (JSON) Reproduction runner (JavaScript)

From a component to your workflow

Build the next evidence
around your documents.

A paid assessment establishes the baseline and the evaluation needed for your receiving process. Agree the data-handling approach before sharing representative samples.

  1. Agree the sample set

    Document types, layouts, languages, expected values and real exception patterns. Keep a separate set for evaluation where feasible.

  2. Measure the whole workflow

    Extraction correctness, validation, staff review, turnaround and operating cost. Include failures and corrections.

  3. Set the acceptance decision

    Define thresholds, system-access prerequisites and responsibilities before delivery. Use the results to decide whether to proceed.

Request a discovery call Use the workflow value worksheet