TARE

clock_comparison · evaluate · results_only

tare evaluate --holdout --no_method_disclosure

Request evaluation

TareWatch

A witness layer on top of a Tare-corrected reference. You compare an independent incoming stream; if they drift apart long enough, you get an alarm. This is not standalone anti-spoof — if you do not need a Tare-class reference, you do not need TareWatch.
TareWatch does not replace signal authentication or cover every RF threat. It answers one question: does this independent path still match the reference we trust?

What it is

  • Reference path — corrected outputs from Tare (or an equivalent contracted service). Typical holdout remainder lands in the 17–22 ns class where Tare applies.
  • Incoming path — your separate GNSS-derived or agreed timing stream, evaluated as-is. We do not re-run the same daily Tare fit on live attacked data.
  • Alarm — when reference and incoming stay far enough apart for long enough, you get a flag. Short blips get filtered out.

What it is not

  • Not a replacement for Tare — the reference is the product.
  • Not OSNMA, not wideband jammer mitigation, not a military threat catalog.
  • Not a claim that a cheap USB dongle alone gives you nanosecond witness resolution — room demos use coarse thresholds so you can actually see a spoof.
  • Not a how-to on Tare correction — we describe architecture here, not the recipe.

Why the layout matters

If you pipe incoming data through the same correction fit as the reference, a constant offset can vanish in both paths — and your witness goes blind. Production setup keeps a trusted Tare reference separate from an independent incoming stream. We validate that split under contract; we do not teach the correction on this page.

Try it (synthetic demo)

Step 1 shows what Tare delivers. Step 2 shows what happens when incoming drifts from that reference. Both panels use made-up data — not customer files or internal holdout exports.

TareWatch is only as good as the reference. First, what Tare actually delivers: on holdout, typical ~45% RMS reduction and post-correction remainder in the 17–22 ns class where Tare applies.

SYNTHETIC DEMONOT REAL RUN DATA

On holdout, the uncorrected line swings (~30 ns class). After Tare, it sits tighter (~17–22 ns class). The curves are drawn to match our published typical ranges — not copied from any one export.

What clocks say (raw)After Tare correction
Typical RMS · beforelow 30s ns
Typical RMS · holdout after17–22 ns
Typical Δ RMS~45%

You get corrected outputs and agreed summary metrics — not our fit recipe. For pinned runs, null tests, and the full protocol, see the evidence room.

Proof for the reference

TareWatch is only as good as the reference behind it. Holdout protocol, pinned runs, and null tests live on the evidence page — results only, no fit.

Tare evidence →Pilot overview →

Get evaluated

We prefer a fixed-scope audit: your incoming stream, our reference path, agreed alarm metrics under NDA. If you already run Tare (or plan to) and have an independent stream worth watching, reach out.

Request evaluationTareProgram@Banlys.com

Patent pending. Tare correction method is confidential. TareWatch is described at architecture level only. The demo uses synthetic offsets — not customer data.