Documentation contents
Get started
Using the platform
Help
Platform overview
Trust Quality Assurance is a manufacturing quality intelligence platform. It acquires inspection and process data at the edge, binds it to a governed object model, evaluates it with statistical and machine-learning services, and turns the result into owned, auditable action.
Updated July 2026 · 7 min read
Core concepts
Almost every question about behaviour resolves to the object model. Five objects carry the meaning; everything else is derived from them.
| Object | Definition | Why it matters |
|---|---|---|
| Asset | A physical resource: site, area, line, cell, machine, station or gauge. | Anchors process data and downtime to a location in the plant hierarchy. |
| Product & operation | What is being made and the routed step being performed. | Gives a measurement its engineering meaning and applicable limits. |
| Characteristic | A measurable property with specification limits, control limits and a sampling rule. | The unit of statistical control; shared definitions make plants comparable. |
| Lot & serial | Batch, lot, serial or web position identity, plus supplier lot linkage. | Enables genealogy, containment scoping and recall analysis. |
| Event | Downtime, changeover, alarm, approval, signature or operator action. | Explains why a process behaved the way it did at a point in time. |
What runs where
The platform is deployed as four layers. Latency-critical evaluation stays inside the plant network; cross-plant analytics and model training run in your cloud tenant.
| Layer | Runs on | Responsibility |
|---|---|---|
| Acquisition | Edge gateway in the plant | Protocol translation, context binding, local buffering, latency-critical inference |
| Governed data model | Regional or private cloud | Master data, measurement store, genealogy graph, immutable event log |
| Intelligence | Cloud, optionally edge | SPC engine, capability service, vision and anomaly models, risk scoring |
| Action & decision | Cloud application | Alert routing, NCR/CAPA/8D workflow, dashboards, audit evidence |
The architecture reference documents component-level detail, data residency behaviour and what happens when a link drops.
How evaluation works
Every incoming subgroup is evaluated against three independent mechanisms, in this order. Alerting never depends on a machine-learning model alone.
- 1Specification check — is the reading inside engineering tolerance for the applicable revision?
- 2Statistical rules — control limits plus the configured special-cause rule set (Nelson, Western Electric or a custom set).
- 3Model scoring — anomaly, classification and escape-risk models add context and cause ranking on top of the statistical verdict.
Where to start
Pick the path that matches your role in the evaluation.
Quality or process engineer
Start with the user guide to see the day-to-day workflows.
OpenProgramme or project lead
Start with quick start for the four-week pilot sequence.
OpenIT, OT or security
Start with security and deployment for the review artefacts.
OpenIntegration developer
Start with the API overview and the architecture reference.
OpenFull contents
Get started
- Platform overview
What the platform does, the object model and the core concepts.
- Quick start
From data access to a live control chart in four weeks.
Using the platform
- User guide
Day-to-day workflows for operators, engineers and managers.
- API overview
REST and streaming interfaces, authentication and rate limits.
Operations
- Architecture
Layers, components, data residency and failure behaviour.
- Deployment
Managed cloud, private cloud and air-gapped installation.
- Security & compliance
Controls, access model, standards mapping and evidence.
Help
- FAQ
Answers to the questions evaluation teams ask first.
Need something this page does not cover?
Solution architects answer technical questions directly — no ticket triage for pre-sales evaluation.