Digital thread management
01
What exactly is stored in a DUST digital thread, and how is it structured?
A DUST digital thread is a structured, append-only record associated with a unique physical object identity. It has two layers. The identity layer stores the enrolled DUST fingerprint, the substrate and formulation metadata, the enrollment timestamp, the location and operator who performed enrollment, and the unique object identifier. The data layer stores everything else: every scan event with its timestamp, location, operator, and match confidence score; every custody transfer with sender, receiver, and transfer documentation; every structured data field defined for the deployment (serial number, part number, lot number, material specification, manufacturing date, and so on); every document attachment (certificates, inspection reports, photographs, videos, purchase orders, shipping records); and every data field appended by downstream supply chain participants with permissions to write. The record is append-only — existing entries cannot be modified, only new entries can be added — creating a tamper-evident history. The structure is defined at deployment configuration and can be customized per object class, with different field schemas for raw materials, manufactured components, assemblies, and finished goods.
02
How does the DICE platform manage the lifecycle stages of a digital thread from enrollment through end of life?
The DICE platform defines lifecycle stages that can be customized to each customer's operational context. In a typical aerospace deployment, a thread passes through seven stages: raw material enrollment (identity created at melt or forge, material certification attached); manufacturing in-process (machining operations, inspection events, quality holds); finished goods release (final inspection, certificate of conformance, export documentation); distribution (custody transfers, shipping events, customs documentation); operational installation (aircraft tail number, position, installation date, installing technician); maintenance (inspection findings, repair records, time-in-service data, airworthiness tag updates); and end of life (removal record, disposition — scrap or overhauled — and if overhauled, rebirth as a new thread linked to the parent). Each stage transition requires an authenticated scan to confirm the physical object matches its thread, and the stage change is recorded with the identity of the operator performing it. Lifecycle stage tracking enables real-time visibility across the supply chain — any authorized participant can see exactly which stage any enrolled object is currently in.
03
Can a digital thread survive part modification, repair, or overhaul?
Yes, through a parent-child thread architecture. When a part is substantially modified — machined from a billet, repaired and re-certified, or overhauled to a new configuration — the original thread is not altered. Instead, a new thread is created for the modified or overhauled part, with a permanent, immutable link to the parent thread it was derived from. This preserves the full material lineage: the child thread carries forward the parent's material certification, original manufacturer, and enrolled identity, while establishing its own independent record from the point of modification. For aerospace, this is critical: a forged part that was derived from certified raw material retains provenance to the certified billet, but the machining and inspection records for the specific part are independently authenticated. Parent-child chains can be arbitrarily deep — a billet can be a parent to a forging, which is a parent to a machined component, which is a parent to a repaired-and-re-certified part — and the full lineage is traversable in the DICE interface.
04
How does DICE handle objects with multiple DUST markings — assemblies made of multiple enrolled components?
Assemblies are managed through a composition model: an assembly thread is created that references the threads of its constituent components, establishing a permanent assembly record that captures which specific serialized parts went into which specific serialized assembly. Each component retains its own independent thread with its own scan history; the assembly thread links to them and adds assembly-specific events: installation configuration, assembly inspection, final test results. This enables bidirectional traceability — given a component, you can see every assembly it has ever been part of; given an assembly, you can see the full provenance history of every component it contains. For aircraft maintenance, this is the basis for configuration tracking: the exact parts configuration of a specific airframe at any given time is recorded and verifiable, with each component independently authenticated by its DUST marking.
User permissions and access control
01
How does the DICE platform manage user permissions across a multi-tier supply chain?
DICE implements a role-based access control model with granular permissions that can be defined at the platform level, the organization level, the object class level, and the individual object level. At the highest level, the object owner — typically the OEM or brand that enrolled the object — defines which downstream participants can see the thread, which can scan and authenticate, which can append data, and which can transfer custody. These permissions are granted per organization (a distributor, an MRO, a retailer) and can be time-bounded, transaction-bounded, or permanent. Within each organization, the administrator defines which of their users can perform which operations — a receiving inspector can scan and authenticate but not append documentation; a quality engineer can authenticate and append inspection records but not transfer custody; a program manager has read access across the portfolio but no write permissions. Every permission grant and revocation is logged in the platform audit trail with timestamp and authorizing user identity.
02
How does a brand or OEM control what data downstream supply chain participants can see?
Data visibility in DICE is governed by a layered disclosure model. The object owner defines, for each data field and document class, which participant tiers can read it. A luxury brand might make the authentication fingerprint and manufacture date visible to all supply chain participants and consumers, while restricting material specification and supplier identity to direct partners only, and keeping cost and margin data entirely private. An aerospace OEM might make part number, serial number, and certification status visible to all authorized supply chain participants, while restricting detailed material traceability to their direct suppliers and internal teams. These visibility settings are enforced at the API level — participants receive only the data fields they have been granted access to, regardless of how they query the platform. The object owner can modify visibility settings at any time, and changes apply immediately to all future queries. The append-once, tamper-evident record means that data already written cannot be retroactively hidden — but future data writes can be access-controlled going forward.
03
What happens to data access when an object changes ownership — for example, when a part is sold from a distributor to an MRO?
Custody transfer in DICE is a documented event that transfers operational control of the object's thread from one organization to another, while the original enrolling organization retains a permanent, read-only view of the full thread history. At transfer, the DICE platform records the transferring and receiving parties, the date and time, the associated transaction documentation (purchase order, shipping record, certificate package), and the authentication scan confirming the specific enrolled object was physically transferred. After transfer, the new custodian gains write access to append their own events to the thread — incoming inspection results, storage records, further transfers — and can grant their own downstream participants access to the portions of the thread they have disclosure rights to. The original enroller's data remains visible to the new custodian as configured by the disclosure model, and the enroller retains read access to the thread's continued history, giving OEMs and brands persistent visibility into how their parts and products move through the world.
04
Can end consumers scan and authenticate a DUST-marked product without having an enterprise DICE account?
Yes. Dust Identity supports consumer-facing authentication through a public verification interface that can be accessed via QR code, NFC tap, or a brand's own mobile application. When a consumer scans the DUST marking on an enrolled product, they receive a confirmation that the specific physical item matches its enrolled record, along with whatever information the brand has chosen to surface publicly: manufacture date, material provenance, sustainability credentials, resale authentication history, and brand storytelling content. This consumer-facing layer is separate from the enterprise DICE platform: consumers see the data the brand has designated as public-facing, with no access to internal supply chain data, business relationships, or proprietary documentation. For luxury brands, this consumer verification capability is a direct engagement channel with buyers of both primary and secondary market products — every scan is an authenticated brand touchpoint.
Data transfer and interoperability
01
How does DICE integrate with ERP, PLM, and MES systems already in use?
DICE exposes a REST API and event-driven webhooks that allow authentication events, custody transfers, and thread data to flow bidirectionally between DICE and enterprise systems. Pre-built connectors are available for SAP HANA Cloud, Oracle SCM, PTC Windchill, and Siemens Teamcenter, with additional connectors in active development. The integration pattern is typically: authentication events in DICE trigger webhooks that write to the enterprise system's quality or inventory records; purchase order and shipping data from the enterprise system is pushed to DICE to populate transfer documentation on thread records. For organizations that prefer a lighter integration, DICE also supports CSV export and import, enabling manual data exchange with systems that lack API capabilities. The API documentation is publicly available and Dust Identity's integration engineering team provides support for custom implementations.
02
How does DICE handle data sovereignty and cross-border data transfer for global supply chains?
DICE is available in regional cloud deployments that keep data within specific geographic boundaries — US, EU, and Asia-Pacific deployments are currently available — to satisfy data residency requirements under GDPR, China's PIPL, and other national data protection regimes. For customers operating under US defense data handling requirements, the GovCloud deployment option provides FedRAMP-aligned controls. For customers with the most restrictive data sovereignty requirements — classified programs, critical infrastructure — the on-premise and air-gapped deployment options keep all data entirely within the customer's own infrastructure, with no cross-border data flow at all. Dust Identity's data processing agreement templates comply with GDPR Article 28 requirements and are available for customer review and negotiation as part of the enterprise contracting process.
03
Can DUST digital threads be exported or migrated to other platforms?
Yes. All data in a customer's DICE deployment is exportable in standard formats — JSON for structured thread data, PDF for attached documents, and blockchain-anchored records for deployments that use Algorand integration. Dust Identity provides a documented data schema that third-party systems can use to ingest exported thread data. For customers who require portability guarantees before committing to DICE, Dust Identity offers a data portability addendum as part of the enterprise agreement, specifying export formats, timelines for data delivery on contract termination, and the retention period for exported data. The DUST fingerprint itself is not platform-dependent: the enrolled fingerprint data is included in the export and can be used to verify authenticity against any future platform that implements the DUST authentication specification.
AI-powered fraud detection in the DICE platform
01
What AI capabilities does the DICE platform include for fraud detection?
DICE incorporates AI-powered anomaly detection across three domains: physical authentication confidence, documentation analysis, and supply chain behavioral patterns. Physical authentication confidence monitoring uses machine learning models trained on scan data from millions of enrolled objects to identify scan results that, while technically within the pass threshold, show statistical patterns inconsistent with normal environmental variation — potentially indicating that a coating has been interfered with, that a non-enrolled object has been substituted, or that a scanner is being operated under adversarial conditions. Documentation analysis uses natural language processing and document forensics models to flag attached documentation — certificates, airworthiness tags, test reports, purchase orders — for indicators of generation by AI tools, digital manipulation, template reuse, or inconsistency with the object's physical authentication data. Supply chain behavioral analysis monitors patterns across the full thread portfolio to identify anomalous custody sequences, unusual geographic routing, timing inconsistencies between claimed and observed custody events, and statistically anomalous re-entry of parts that should have been retired.
02
How does DICE detect AI-generated or digitally manipulated aerospace documentation?
DICE's document forensics capability analyzes attached documentation at the time of upload using a multi-layer detection pipeline. The first layer is metadata analysis: PDF and image files contain creation metadata that frequently reveals inconsistencies — a document claimed to be generated by a specific quality management system may carry metadata indicating it was created in a consumer PDF editor, or a certificate dated three years ago may have a file creation timestamp from last week. The second layer is layout and typography analysis: genuine aerospace documentation from specific manufacturers and certification authorities has characteristic formatting, font usage, field placement, and serial numbering schemes. DICE's models, trained on large datasets of verified genuine and known fraudulent documents, score each uploaded document for consistency with the expected format for that document type and issuing authority. The third layer is content cross-referencing: values stated in the attached documentation — part numbers, serial numbers, material specifications, test results — are cross-referenced against the thread's physical authentication data and against known specification databases. A certificate claiming a material property inconsistent with the enrolled material specification, or a part number that does not correspond to the enrolled component geometry, triggers an alert. Flagged documents are not automatically rejected — they are escalated for human review with a detailed anomaly report highlighting the specific indicators that triggered the flag.
03
How does DICE's AI fraud detection handle the evolving capabilities of generative AI document forgery?
Dust Identity's approach to AI-generated document detection is explicitly designed as an arms-race-aware system. The document forensics models are retrained continuously on newly identified fraudulent documents, including AI-generated samples, and detection capabilities are updated as new generation techniques emerge. However, the fundamental architecture does not rely solely on detecting characteristics of generated documents — an approach that will always lag behind generation capability improvements. Instead, DICE cross-references document content against independently authenticated physical data: the document must be consistent with what the scanner confirmed about the physical object, not merely internally consistent as a document. A perfectly convincing AI-generated airworthiness tag that correctly states a part number, serial number, and manufacturing date still fails DICE's cross-referencing check if the physical DUST scan indicates a different enrolled identity — the physics overrules the document, regardless of how convincing the document appears. This physical anchor is what makes DICE's fraud detection qualitatively more robust than any document-only approach.
04
What specific fraudulent patterns does DICE's behavioral AI look for in aerospace supply chains?
Behavioral anomaly detection in DICE is tuned to the known fraud patterns documented in aerospace supply chain audits and regulatory enforcement cases. Certificate wash — where a part is sold to an intermediary, documentation is lost or replaced, and the part re-enters the supply chain with new, non-traceable paperwork — appears in DICE as an unexpected gap in custody history or a thread restart inconsistent with the part's age and condition data. Scrap re-entry — where parts removed from service and designated for destruction are returned to the supply chain — appears as a part with a prior end-of-life record reappearing in an active distribution thread. Time compression fraud — where certificates claim manufacturing or inspection events that occurred in an implausibly short timeframe — appears as timestamp sequences inconsistent with the documented process lead times for that part type. Geographic impossibility — where a part claims a custody chain that requires physically impossible transit times — appears as sequential scan events at locations that cannot be reached in the time between them. Each of these patterns generates a risk score and alert in the DICE platform, with the specific indicators surfaced for human review.
05
Can DICE's AI fraud detection be applied to documentation outside of aerospace — for example, in luxury goods, pharmaceuticals, or food safety?
Yes. The core detection architecture — metadata analysis, format consistency scoring, content cross-referencing against physical authentication data, and behavioral pattern monitoring — is domain-agnostic. Dust Identity has adapted the document forensics capability for luxury goods provenance documentation (certificates of authenticity, appraisals, auction house provenance records), pharmaceutical batch release documentation (certificates of analysis, manufacturing records, pharmacovigilance reports), and food safety traceability documentation (organic certification, geographic indication records, cold chain compliance logs). Each domain requires domain-specific training data for the format consistency models and domain-specific cross-reference databases for content validation, but the underlying detection pipeline is the same. For organizations deploying DUST in non-aerospace applications that need document fraud detection, Dust Identity's platform team configures domain-appropriate detection profiles during the deployment setup process.
06
How does DICE surface fraud detection findings to supply chain operators, and what actions can be triggered automatically?
Fraud detection findings in DICE are surfaced through three channels. Real-time alerts are pushed via webhook to connected enterprise systems and to the DICE dashboard — a failed authentication, a flagged document, or a high-severity behavioral anomaly triggers an immediate notification to defined recipients. The DICE dashboard provides a risk-stratified view of the object portfolio, with high-risk threads highlighted and drill-down access to the specific indicators that generated the risk score. For supply chain operators managing high volumes, a daily exception report aggregates all flagged events from the previous period with recommended actions. On the automated response side, DICE can be configured to place objects in a quarantine status on detection of specific event types — a part that fails physical authentication is automatically flagged as suspect in the connected ERP system, preventing it from being allocated to production orders until the discrepancy is resolved. For the most severe findings — a confirmed non-match indicating physical substitution, or a document flagged as AI-generated — DICE can trigger automated escalation workflows that notify quality management, compliance, and in defense applications, the appropriate regulatory reporting channels.
