Criticality Tiers
Every device declares a criticality tier in its /capabilities response. This determines how ZenEdge handles failures.
Tier Definitions
| Tier | Guarantee | Failure Behavior |
|---|---|---|
| CRITICAL | Must work for the booking to succeed | Retry with grace period. Alert admin immediately. May block booking access. |
| STANDARD | Important but non-blocking | Booking proceeds. User notified of degraded service. Background retry. |
| OPTIONAL | Nice-to-have | Silently degraded. No user impact. Logged for review. |
Examples
| Device | Typical Tier | Rationale |
|---|---|---|
| Door lock | CRITICAL | Guest can't enter the room without it |
| Wi-Fi hotspot | STANDARD | Meeting can proceed without Wi-Fi |
| Ambient lighting | OPTIONAL | Cosmetic feature |
| Smart fan | OPTIONAL | Comfort feature |
| Camera | OPTIONAL | Monitoring only |
Impact on Booking Access
When a booking.start event triggers magic link issuance:
- ZenEdge checks health of all devices in the physical space
- CRITICAL devices must be healthy — if not, retry logic activates
- STANDARD devices are included if healthy, skipped with notification if not
- OPTIONAL devices are included if healthy, silently skipped if not
Declaring Criticality
In the /capabilities response:
{
"devices": [
{
"device_id": "ada-lock-001",
"type": "lock",
"criticality": "CRITICAL"
},
{
"device_id": "ada-wifi-001",
"type": "wifi",
"criticality": "STANDARD"
}
]
}
Next Steps
- Capability Discovery — Full capabilities schema
- Health & Heartbeat — Monitoring details