Documents

Performance and Data Handling, Measured Results

Tracepoint · A&R Strategic Solutions Measurements taken 25 August 2026. All data used in these tests is synthetic. No real audit data was used or represented.

What was measured

Every number below comes from running the product's own code. The benchmark calls the same CSV parser, the same guarded engine actions, and the same export-package builder that the application uses when a person clicks Import and then Export. Nothing is stubbed, simulated, or estimated.

The benchmark runs in two places so the results can be checked two ways:

• A scripted harness that runs outside the browser. This gives a reproducible number that anyone can re-run from a command line.
• The browser itself, which is where the product actually runs. This confirms the scripted numbers hold in the real runtime.

Test machine: 8-core Apple Silicon Mac, Node 22.17.0, Chromium browser engine. A government workstation of similar specification should produce comparable results. The application runs entirely on the local machine, so no network time is involved.

Each figure below is from a single recorded run, and the raw output of that run is saved in the repository. Repeating a run moves the timings by a few percent, as it would for any measurement of this kind. The results are not averaged, because averaging would hide that variance rather than disclose it.

Scale results

Each run takes a source file of audit findings, reads and maps it, creates every finding with an attested audit-trail entry, and builds the complete export package.

Throughput at the largest scale: 11,962 rows per second read and mapped, 20,027 findings per second created and attested.

The same runs inside the browser:

The browser is slower than the scripted harness, which is expected. Both produce the same package: the same 45 artifacts at the same sizes. The benchmark compares the artifact names and sizes in each ZIP. The two files are not byte-for-byte identical, because the package ID, the export time and the time on each trail row come from the machine's clock during the run.

For context on the scale: GAO reported 3,322 Notices of Findings and Recommendations open across the Department of Defense at the end of FY2023. The 10,000-finding test is roughly three times the entire reported DoD backlog, processed on one laptop in under six seconds.

Peak memory at 10,000 findings was 310 MB, which is within the normal working range of any modern workstation.

What the package contains

At every scale the export package contained 45 artifacts, and the validation gate confirmed the package assembled with checks passed. The five largest artifacts at 10,000 findings:

The interoperability folder also carries an OSCAL POA&M, an eMASS POA&M CSV, and an ODCFO corrective action plan export. Their presence is verified as part of the benchmark rather than assumed.

The provenance file is large on purpose. Tracepoint keeps the original source row for every finding it creates, so a reviewer can compare what the product produced against what the source file actually said.

Handling imperfect data

Audit files arrive incomplete, inconsistent, and duplicated. A tool that quietly cleans these problems up hides them from the reviewer. Tracepoint discloses them.

A 500-row file was built with deliberate defects. The expected handling for each defect was written down before the test was run. Results:

Every expectation was met exactly. Across the 477 rows the product recorded 376 individual conversions, each one retained in the export package alongside the original source value.

Three points matter more than the counts:

1. Nothing is created until a person confirms it. The import preview shows what will be created, what will be defaulted, and what will be refused, before anything is written.
2. A missing value is never invented. A blank fiscal year stays blank. Tracepoint does not guess a year, and no view displays a guessed year as though it were real.
3. A default is always labelled as a default. When the product cannot recognise a classification, it applies one and says so on the record and in the export.

What the benchmark hardened

The benchmark runs on every build, and three behaviours in the current release were shaped by it.

• The eMASS CSV export carries its warnings with it. The export function returns the CSV together with any warnings, both call sites write the CSV, and the warnings travel into the package as their own file.
• Large imports commit as one batch. Overlay writes are batched into one write and one redraw per import. In-browser creation runs at 10,617 findings per second, and a 10,000-row import completes in one pass.
• Repeated source IDs are caught inside the file as well as against the workspace. The importer checks both, and the preview says which kind of repeat it found. The 33 repeats in the test file were each flagged.

How to read these numbers

• They measure one laptop. The same harness runs on any workstation, so an organization can confirm performance on its own hardware in minutes.
• They use synthetic data generated from a fixed seed, so every run is repeatable and every expectation is written down before the run.
• They show that the product processes the data it is given at scale and discloses every conversion and refusal. The judgment of which findings belong in the register stays with the organization, as it should.
• The datasets, the harness, and the result files ship in the repository, so any party can reproduce the runs from two commands.

Reproducing these results

From the application directory:

npm run bench:data      # generate the synthetic datasets
npm run bench -- 100    # or 1000, 10000, or messy

Results are written to tools/bench/result-<scale>.txt. The dataset generator uses a fixed seed, so the same files are produced on every machine. The browser version of the same benchmark is available at /bench.html?n=10000 while the development server is running.