Identity stays bound to the reservation
Guest, room, booking, conversation, Task, Hold, receipt, and Ledger evidence retain one consistent identity.
Trust, without theatre
Every automated action needs authority, evidence, and a safe stop.
Renavo is designed to turn guest communication into accountable hotel work. This page separates the controls you can inspect today from the property-specific connections that must be configured and accepted during a pilot.
Updated 19 July 2026
0
success claims without proof
A system write needs a receipt and readback; uncertainty becomes an incident.
1
operation identity per write
Retries recover the same outcome instead of silently repeating the action.
2
first-class product languages
Arabic and English cover the guest and operations experiences.
Controls built into the operating model
Money has a code-enforced boundary
Property policy decides what may execute. Approval-first mode stages the exact change and waits for a hotel decision.
External writes are verified
Supported actions carry an idempotency key, provider receipt, post-write readback, and explicit uncertainty handling.
Access is role and tenant scoped
Owner, manager, and staff permissions are separated. One-time invitations, TOTP MFA, hashed recovery codes, and device-labelled session revocation are built in; pilot readiness stays non-green until privileged staff enroll.
Privacy is operational, not a PDF promise
Owner-only export, erasure, retention pruning, and a daily retention worker are part of the product.
Failure remains visible
Provider timeouts, ambiguous outcomes, delivery failures, and recovery attempts become owned incidents and Ledger events.
Capability boundary
Working in the synthetic product showcase
- Server-backed guest and owner experiences with realtime synchronization
- Tasks, Holds, approvals, receipts, incidents, and a verified Ledger chain
- Approval-first late checkout against a persistent synthetic hotel-system provider
- Arabic and English product journeys, including deterministic safety and money language
- Test PMS and controlled computer-use acceptance tooling
Configured and accepted for each property
- The hotel's approved guest channel, number, domain, and consent model
- The authorized PMS API or allow-listed portal workflow and least-privilege credentials
- Property policies, money limits, staff accounts, MFA, escalation paths, retention, and support ownership
- Provider fault tests, monitored production acceptance, and hotel sign-off
- Voice and real computer use only after the exact property workflow passes acceptance
Infrastructure and subprocessors
The exact set depends on the deployment. A provider is not treated as a live hotel connection merely because an adapter or account exists.
| Provider | Purpose | Boundary |
|---|---|---|
| Vercel | Application hosting and delivery | Production application traffic and runtime logs |
| Supabase | PostgreSQL authority and realtime | Tenant-scoped operational state and Ledger evidence |
| Google Cloud / Vertex AI | Language-model processing when enabled | Real guest turns only under the configured deployment |
| Cloudflare | Recovery scheduling, monitoring, signed Ledger witnessing, and configured email ingress | Bounded health/recovery calls, append-only Ledger heads, and channel metadata |
| E2B | Disposable computer-use environments | Allow-listed synthetic or explicitly authorized portal workflows |
| Twilio / Meta / LiveKit | SMS, WhatsApp, and voice when commissioned | Disabled until the property channel is configured and accepted |
| Sentry | Error and performance monitoring when enabled | Redacted diagnostics; secrets and unnecessary guest content are excluded |
| Mailjet or configured mail provider | Transactional email and lead notifications | Used only when delivery credentials and sender identity are accepted |
Inspect the controls, then scope one real workflow.
The public showcase is synthetic by design. A pilot starts with one property, one channel, one system path, and explicit acceptance criteria.