Enrolled record sets. Separation health — computed from each catalog's own scans at enrollment — predicts its accuracy regime before any match is run.
Drop each stone's polish scans (.dpt / .csv / .txt / OPUS .0, any wavenumber grid, or one .zip). Stone IDs come from filenames: <stone>-<scan>.dpt. At least 2 scans per stone; 5 recommended.
Machine-invariant enrolment appends synthetic far-machine scans to each stone's record, so the catalog can match queries scanned on instruments it has never seen — in production, the checking machine is never the enrolment machine. Measured on two never-enrolled field instruments: naming went from 6–10 of 25 to 22–23 of 25 at the standard bar, with same-machine naming unchanged or better (22→25/25) and foreign rejection of non-twin substitutes unaffected (100%). The trade: substitutes that are spectral twins of an enrolled stone (cut from the same rough) match at group level more often — they were never separable by spectrum and resolve by weight or sealed mode, as twin naming already does. Off by default while field evidence accumulates — tick it whenever the checking machine may differ from this one.
Open batch is the default: any stone may be foreign, and one global assignment resolves the batch — two stones can never claim the same record.
Sibling-blind accept bar. By default each stone's bar is calibrated against impostors outside its own spectral-twin group, so stones cut from the same rough don't reject one another. That lowers the bar — and a lower bar is easier for a substitute to clear too. On a sibling-dense field catalog (30 stones, 8 twin groups, discount 0.176) the default admitted about 1 substitute in 10 at 10–27% contamination, against none when sibling-blind. Lot mode does not need the discount: the assignment already separates siblings, because a complete lot contains both and they claim different records — on that catalog sibling-blind named the same 30/30 with no twin-set ambiguity left. Tick it when the catalog has real twin structure — watch the discount in the hint above, ≥0.05 is the regime that leaked. Leave it off otherwise: on a cross-machine parcel with a negligible discount it buys nothing (rejection was already 100%) and costs 1–2 named stones a session.
No contamination escalation. Normally, when more than a fifth of records go unclaimed, the run reads that as substitution and re-solves at a much stricter bar. That pays off where genuine scores cluster tightly (corpus at 25% substituted: rejection 89.5% → 98.4%). It backfires where the genuine distribution has a long tail and honest stones already sit near the bar — tightening then rejects them: on the sibling-dense field catalog it took naming from 94% to 40% to add one point of rejection it did not need. Tick it if a heavily-substituted lot comes back with naming collapsed, or together with the sibling-blind bar on a catalog with a wide genuine spread. Escalation is already skipped when the batch looks drifted (a different instrument) rather than substituted, never arms below 20% unclaimed, and is disarmed automatically whenever the FAR target is pinned.
Adaptive accept bar. Normally the bar is an absolute cosine calibrated on the machine the catalog was enrolled on. If the batch was scanned somewhere else, that whole machine shifts the scores down and the bar can end up above the batch's median genuine score — rejecting honest stones wholesale while still ranking every one of them first. A real parcel on a fourth, never-enrolled instrument scored 10 of 25 that way, with rank-1 at 100%. Ticking this anchors the bar to this batch's own median best score instead, so it travels with the instrument: the same parcel goes to 22 of 25. Lot mode licenses it for the same reason it licenses batch alignment — the batch is declared to BE the catalog — and contamination cannot move a median until it passes half the batch. Across 18 corpus catalogs it also beat the absolute bar on substitute rejection by 5–10 points at every contamination level, for 0.8–1.4 points of naming. Tick it whenever the checking machine is not the enrolment machine — in production that is always. It re-anchors the bar your FAR target already selects, so FAR and the sibling-blind box keep working exactly as before; only the anchor moves.
All three default to today's behaviour — an untouched run is identical to before these existed. Neither is a validated default yet: they measure better on a sibling-dense catalog and worse on a drifted cross-machine one, so they are exposed per run while more field parcels accumulate. Each run records which policy it used.
The FAR target sets how hard a stone must beat the catalog's own impostors to be auto-accepted. In batch modes the dial is nearly free — measured on 3,600 genuine / 2,138 stranger queries (cat-100): auto-accept 93.8% → 97.6% → 98.9% at 1% / 10% / 30%, with zero wrong names at every setting and stranger acceptance rising only 0.33% → 0.51%; the batch assignment, not the threshold, is what keeps strangers out. In single-stone mode the dial behaves normally and costs real security: stranger acceptance 3.7% → 12.9% → 31% over the same range. Loosen freely for batches; keep 1–2% for single stones.
A parcel of roughs scanned at intake (≥6 scans per stone); arriving polish is resolved with no manifest and no prior polish scans. Verdicts come ranked by foreign probability with an estimated foreigner count. Numbers: see Docs / PROMISE.
Retain each adjudicated batch's polish here — they are guaranteed strangers to every future parcel. ≥200 stones enables vault calibration.
Generation 3 (2026-08-24) uses the W4PROD encoder + mixed-cohort policy: on the RES-8 client population it lifts membership from ~5% to ~28–39% at 98–99% foreign rejection. Standard populations must stay on generation 2 — the same pair measured 2–7 points WORSE there.
One polish scan set vs one claimed rough scan set — MATCH / NO_MATCH by 3-encoder fusion. At the default setting ~98% of wrong-rough claims are rejected and ~92.7% of genuine ones confirmed (td-population calibration; the P(match) shown is calibrated at a 50:50 prior). Borderline claims are best read via P(match), not the bare verdict. Not for 4/cm-class populations.
One click reruns our validation on YOUR stones: each stone's last enrollment scan is held out as a returning query, and a chosen fraction of stones are removed from the records entirely — their queries are foreign by construction. No uploads needed.
Every verify-match claim submitted through the v1 API, newest first, with verdicts, calibrated P(match), scan hygiene, and decoy-shopping flags (a polish scan set probed against 3+ distinct roughs). Operator-only: requires the admin token.
One named key per machine/integration — claims are attributed to the key's name in the table below and in telemetry. Revoking a key stops its access immediately; its historical claims remain attributed. The full key is shown ONCE at creation.
Absolute thresholds are population-specific: on a fresh population the shipped defaults measured ~3 points looser than their label. Each population's own API traffic re-derives its ladder (impostor pairs are built by cross-pairing every claim's polish against the other stored roughs — no ground truth needed). Nothing is applied automatically. Wait for mature and a small spread before approving; an early bank is often one homogeneous batch and reads too strict.
One polish scan set submitted against several claimed roughs. On a production key this is a breach of one-claim-per-stone, and it is flagged whether or not any of the attempts was confirmed. Grouped by stone where the submission carried filenames, by content digest otherwise. Requires the admin token.
Every accuracy figure this service publishes assumes one claim per stone. The menu describes random wrong claims; a claimant who retries one polish against rough after rough is selecting for a pass. That difference is large and measured — a random wrong claim is rejected about 98% of the time, the best of 29 chosen decoys only 59–68%. So probing defeats the promise whether or not it succeeded on the attempts we happened to see, which is why these are flagged on the access pattern and not on the outcome.
probe multi accept means more than one rough was confirmed for the same polish. At most one can be the true source, so at least one of those confirmations is wrong — breach plus damage.
Identical traffic means the opposite thing on a key marked
role=test: an internal replay or evaluation harness should work this
way, and those groups are listed as evaluation and kept
out of the breach count. If a client legitimately needs to evaluate against a panel of
their own roughs, issue them a test key — that keeps their production stream clean
and keeps this page meaningful. A tight top-to-second margin, separately, usually means a
genuine near-tie between similar stones: a discrimination limit rather than an access
problem.
Operator view over everything the deployment has logged: event volumes, the match-verifier's score-drift check against its calibration baseline, decoy-shopping flags, and a browsable stream of recent events. Requires the admin token (shared with the API claims view).
A separate experiment from the polish catalogs and rough parcels in the other tabs: different instrument class (FTIR microscope), different question (“are these the stones of this lot?”), and its own encoder. LUMOS lots and ALPHA catalogs cannot be scored against each other — the encoder pin enforces it.
Drop each stone's scans. Stone IDs come from filenames: <stone>-<scan>.dpt. 3 scans per stone — the protocol the bounds are measured at.
Present the returning stones — 3 scans each. Scored at the shipped policy (lot mode, twin-aware bar, FAR 10%); there is no dial to turn, because the bounds are measured at that point and nowhere else.
Runs the substitution construction against the enrolled records — your stones, the shipped policy, no scans to upload. Use it to show a client what the bounds mean on their own goods.
All API documentation lives at reid.diadna.cloud/api-docs — share that link with integrating developers. It is rendered from API.md in the repository, so it is the single source of truth and cannot drift from the code. Covers: auth and key handling, both request formats, the full reject_target ladder (0.90–0.99, with the sub-0.95 rungs marked experimental), what an uncalibrated population actually delivers, response fields, warnings and diagnostics, data requirements, errors, a worked Python integration, the /api/v1/expected ground-truth endpoint, and the LUMOS declared-lot API. The same text is available as raw Markdown at /api-docs.md, and the live machine-readable contract at /api/v1.
Validated on production data (18 disjoint 100-stone catalogs, multi-scan records and queries, thresholds self-calibrated per catalog):
| mode | metric | measured |
|---|---|---|
| sealed batch | identity mapping | 100.0000% (1,800/1,800) |
| open batch (α=0.01) | foreign/stranger detection | 100% (630/630) |
| open batch | wrong name to a genuine stone | 0.00–0.07% |
| open batch | genuine auto-confirmed | 93–94% (rest → review) |
| per-stone | Top-1 / Top-3 | 99.1–99.6% / 99.94% |
Rough-parcel mode (no polish records, no manifest, catalog-30, heavy-contamination validation): foreign rejection 99.0–100%, wrong identities ≤1.5%, ~50% auto-identified at the cascade point, foreigner count estimated to ±4 stones, vault-calibrated thresholds valid on any population. Full table: PROMISE.md.
NO_MATCH is a review flag, not a foreign verdict. For a genuine member the true record appears in its top-3 ≈ 99.9% of the time — review the candidates.
Separation health (shown at enrollment) predicts the regime: CLEAN → headline rates; TIGHT (e.g. a stone population far from the encoder's training corpus) → the security promises hold but more stones route to review. First fix: more scans per stone.
Known limits: an absent sibling (same rough) of a catalog stone is the hardest impostor (~90% rejection stand-alone); keep sibling sets enrolled together. Scans should follow the enrollment protocol; multi-year instrument drift is outside the validated envelope — re-enroll periodically.
To verify on your data: enroll with scans held out, present them later as a batch with known truth (including FOREIGN stones), and compare the scorecard — the full protocol is in VERIFICATION.md.