Risk Flag: an automatic indicator that something in an asset's maintenance history warrants attention—computed algorithmically from signed events, not manually flagged by humans.
Key Takeaways
- 1Risk flags are computed automatically from signed maintenance events
- 2METER_ANOMALY detects rollbacks, impossible jumps, and telematics mismatches
- 3OVERDUE_PM flags assets that have exceeded maintenance intervals
- 4Evidence flags (MISSING_EVIDENCE, EVIDENCE_TAMPERED) ensure document integrity
- 5Flags include severity levels and link directly to affected events
Why automatic risk detection matters
Traditional due diligence requires hours of manual investigation: calling service providers, cross-referencing documents, spotting inconsistencies in spreadsheets. Most anomalies go undetected because humans can't efficiently analyze hundreds of maintenance events.
UMP risk flags change this equation. Because every maintenance event is a signed, timestamped credential with structured data, the system can automatically detect patterns that would take humans hours to find—and surface them instantly during verification.
Computed, not claimed
Risk flags are derived from signed events, not self-reported by asset owners. The system computes flags based on mathematical analysis of the maintenance history. You can't remove a flag without addressing the underlying data issue.
METER_ANOMALY flag
The METER_ANOMALY flag detects irregularities in hour meter or odometer readings across maintenance events. It catches issues that often indicate data manipulation or recording errors.
Meter rollback (HIGH severity)
A later event shows a lower meter reading than an earlier event. This is physically impossible under normal circumstances and often indicates tampering or data entry fraud.
Impossible meter jump (HIGH severity)
The meter increased faster than physically possible (e.g., 10,000 hours in one month). Indicates data entry error or potential fabrication.
Telematics mismatch (MEDIUM severity)
The reported meter reading differs significantly from telematics data for the same timeframe. The threshold is typically 5% deviation.
| Aspect | Severity | What it means |
|---|---|---|
| HIGH | Meter rollback or impossible jump | Investigate immediately |
| MEDIUM | Telematics mismatch > 5% | Review source data |
| LOW | Minor discrepancy 2-5% | Note for context |
Real-world example
An excavator shows 8,500 hours in a January service record, then 7,200 hours in a March inspection. The system flags this as METER_ANOMALY (HIGH) with a direct link to both events. A verifier sees this instantly instead of discovering it after purchase.
OVERDUE_PM flag
The OVERDUE_PM flag tracks preventive maintenance schedules and alerts when an asset has exceeded its recommended service interval. This helps verifiers understand whether maintenance schedules have been followed.
Interval tracking
The system tracks hours/miles since the last PM event against the asset's recommended interval (e.g., 500-hour oil change).
Severity escalation
Flags escalate from LOW (slightly overdue) to MEDIUM (significantly overdue) to HIGH (severely overdue) based on how far past the interval.
Multiple interval types
Tracks different PM types separately: engine oil, hydraulic fluid, filters, inspections. Each has its own interval and flag status.
PM event recorded
A signed maintenance event establishes the baseline: 'Oil change at 5,000 hours, next due at 5,500 hours.'
Usage continues
Subsequent events or telematics data show the meter advancing toward the due point.
Threshold crossed
When the asset exceeds 5,500 hours without another oil change event, OVERDUE_PM flag is set.
Flag appears in verification
Verifiers see the flag with severity level, hours overdue, and link to the last PM event.
Not necessarily bad
An OVERDUE_PM flag doesn't mean an asset is damaged—it means the maintenance schedule wasn't followed as documented. Some operators run equipment beyond intervals intentionally. The flag ensures this is visible to counterparties making decisions.
Evidence integrity flags
Beyond meter and maintenance tracking, UMP flags issues with the evidence files attached to maintenance events. These flags protect against document manipulation after the fact.
MISSING_EVIDENCE
An event references evidence files that cannot be retrieved from storage. The record exists but the supporting documentation is gone.
EVIDENCE_TAMPERED
The hash of a retrieved evidence file doesn't match the hash recorded when the event was signed. The file has been modified.
These flags are computed during verification by re-hashing evidence files and comparing against the original hashes stored in signed credentials. Because evidence is stored in WORM (Write Once Read Many) storage with Object Lock, tampering requires significant effort—and will always be detected.
How flags help different roles
Risk flags create value for every party in an asset transaction:
Buyers and inspectors
Instant visibility into potential issues before purchase. No more discovering meter fraud after the deal closes. Flags provide specific events to investigate, not vague concerns.
Lenders and insurers
Objective risk indicators for underwriting decisions. A clean passport with no flags represents lower risk than one with multiple HIGH severity flags.
Sellers with clean histories
Zero flags become a competitive advantage. When your passport shows no anomalies, buyers trust your asking price. The 'discount for uncertainty' disappears.
Verification in seconds
A verifier scans a passport and immediately sees: 47 events, 0 risk flags, all evidence verified. Or they see: 52 events, 2 METER_ANOMALY (HIGH), 1 OVERDUE_PM (MEDIUM). Either way, they know what they're dealing with before making a decision.
Technical: How flags are computed
Risk flags are computed at two points in the credential lifecycle:
On issuance
When a new event is signed, the system checks it against existing events for the asset. If the new event creates an anomaly (e.g., meter lower than previous event), the flag is attached to the credential.
On verification
When a passport is verified, all events are re-analyzed together. Flags are computed fresh based on the complete history, catching issues that span multiple events.
Flags reference specific event IDs, so verifiers can click through to see exactly which records triggered the flag. The computation is deterministic: given the same signed events, any verifier will see the same flags.
| Aspect | Flag type | Computation basis |
|---|---|---|
| METER_ANOMALY | Meter readings across events | Time-ordered comparison + telematics |
| OVERDUE_PM | PM events + intervals + current meter | Interval math against last service |
| MISSING_EVIDENCE | Evidence URIs in credentials | Storage retrieval attempt |
| EVIDENCE_TAMPERED | Stored hashes vs computed hashes | SHA-256 comparison |
What flags won't tell you
Risk flags are powerful but not omniscient. Understanding their limitations helps you use them appropriately:
Quality of work performed
Flags detect data anomalies, not whether a repair was done correctly. A signed event proves work was claimed, not that it was good work.
Completeness of history
Flags analyze what's recorded. If maintenance was performed but never entered into UMP, the system can't flag its absence.
Future reliability
A clean passport doesn't guarantee future performance. Flags indicate historical data integrity, not mechanical predictions.
Intent behind anomalies
A METER_ANOMALY might be fraud or might be a data entry error. Flags surface issues; humans determine causes.
See risk flags in action
Ready to see how risk flags work in practice?
For verifiers
See how risk flags appear in verification results and what actions they suggest.
Learn more