Method
How it works, honestly
Two stages. Stage-1 asks “is this part abnormal?” against a set of the tenant's own known-good photos. Stage-2 asks “which ISO failure mode is it?” and forces a choice from the catalog for that part family. A confidence gate sends the uncertain ones to a human, whose call is authoritative.
Stage-1 is a memory bank, not a deep model
The anomaly detector is PatchCore's shape, a memory bank of normal patch features scored by nearest-neighbour distance, but with cheap local patch statistics instead of a deep backbone. A real timm backbone (torch) does not fit a serverless function's size limits, so it is honest to say this is a classical-feature detector today. It runs as a Python function that holds no state and touches no database.
Stage-2 forces a choice
Given an anomalous crop, Stage-2 must return one code from the part family's ISO catalog. A hallucinated code is discarded. Without an API key it uses a deterministic heuristic; with an OpenRouter key it routes to a vision model. Either way the confidence gate, not the source, decides whether a finding auto-files or waits for review.
The gate is one number, and it is published
A stage-2 confidence at or above 0.70 auto-files the record. Anything below it waits for an inspector. The threshold lives in one constant, CONFIDENCE_GATE in src/lib/stage2.ts, so there is no second, quieter rule somewhere else in the pipeline.
The inspector is the source of truth
Model output is a suggestion, kept immutable for provenance and as one half of a future training pair. The inspector's confirmation or correction is the authoritative classification, and it is what flows into the fleet analytics.
Data we are not built on
No synthetic defect data. Training reference sets are the tenant's own photographs of good parts, enrolled per part family. The bundled dataset registry excludes anything without a redistribution-clean licence, and EfficientAD is deliberately excluded on patent grounds. See the model card for specifics.
Capability coverage
What is live, what is optional, what is not built.
Common questions
- How does Witness classify a damaged part?
- In two stages. Stage 1 asks whether the part is abnormal, scoring it against a memory bank built from the tenant's own photographs of known-good parts. Stage 2 asks which ISO failure mode it is, and must return one code from the part family's catalogue: ISO 15243 for rolling bearings, ISO 10825 for gear teeth. A confidence gate at 0.7 auto-files the confident records and sends the rest to a human review queue.
- Is the Witness anomaly detector a deep learning model?
- No. It has PatchCore's shape, a memory bank of normal patch features scored by nearest-neighbour distance, but it uses cheap local patch statistics instead of a deep backbone, because a torch backbone does not fit a serverless function's size limit. It is honest to call it a classical-feature detector today.
- Can the model invent a failure mode that is not in the standard?
- No. Stage 2 is a forced choice against the part family's ISO catalogue, and a code that is not on the list is discarded. Without an API key the stage runs a deterministic heuristic; with an OpenRouter key it routes to a vision model. The confidence gate, not the source, decides where a finding lands.
- Who has the final say on a classification, the model or the inspector?
- The inspector. The model output is a suggestion that is kept immutable for provenance and as one half of a future training pair. The inspector's confirmation or correction is the authoritative classification, and it is what flows into the fleet analytics and the warranty reports.
- What data is Witness trained on?
- The tenant's own photographs of good parts, enrolled per part family. There is no synthetic defect data. The bundled dataset registry admits only licences that are clean for redistribution, and EfficientAD is excluded on MVTec patent grounds.