Identity first
Production users require real authentication, controlled invitations, session protection and stronger verification for sensitive actions.
Protect each company. Recover the right company.
A real multi-company last-mile platform needs identity, tenant isolation, role enforcement, audit records, platform disaster recovery and a tested way to recover one company without damaging the others.
This page defines required architecture and launch gates. It does not claim that every control is already production-certified.
Request boundaryRequired architecture
01Identity and MFAWho is the user?
02Membership and roleWhich company and authority?
03API authorizationCan this action run?
04Tenant-owned dataWhich records are visible?
05Object and audit boundaryWhich files and events?
Tenant isolation
Company switching cannot be a browser parameter.
Every request must prove the signed-in identity, active company membership, allowed role and ownership of the requested record or object.
Membership is server-side
The API decides which company a user belongs to. A query string, browser storage value or changed URL cannot grant another tenant’s data.
Least-privilege roles
Platform administrator, company operator, DSP manager and driver permissions stay distinct, with high-risk actions requiring explicit authority.
Objects follow the tenant
POD photos, exports and attachments need tenant ownership, signed access and deletion rules—not public file URLs.
Significant actions are auditable
Membership changes, exports, route reassignment, POD decisions, restore approvals and security changes need durable audit events.
Backup architecture
Company-level recovery and platform disaster recovery solve different problems.
A company does not always need its own physical database. It does need provable isolation, a tenant-scoped recovery package and a restore procedure that cannot overwrite unrelated tenants.
Tenant-scoped backup package
Export the company’s relational records, object manifest, configuration and audit references with a consistent recovery point. Encrypt it, record integrity checks and restore it into an isolated environment before approval.
Full database and object recovery
Protect the entire platform with automated database backups, object-storage versioning or replication, infrastructure configuration and a tested platform restoration plan.
Physical database separation remains an option when contract, regulation, risk profile or scale requires it. It should be an architectural decision, not a substitute for authorization and recovery design.
Restore runbook
A backup is useful only after a successful restore drill.
The recovery process must prove scope, integrity and approval before restored data returns to production.
Declare the incident
Record affected tenant, time window, systems, suspected cause and the authority requesting recovery.
Select a recovery point
Verify backup integrity, object manifest and whether the selected point contains the required records.
Restore in isolation
Recover into a quarantined environment, validate tenant boundaries and reconcile orders, events and objects.
Approve and cut over
Use documented approval, protect newer valid changes, monitor the cutover and preserve the audit record.
Production launch gates
These controls must be verified, not assumed.
The current public demo is useful for workflow evaluation. Production onboarding requires evidence that the operational and recovery controls actually work.
| Control | Evidence required | Why it matters | Gate |
|---|---|---|---|
| Authentication and MFA | Real identity provider, protected sessions, invitation and recovery workflow | Prevents shared demo identity from becoming production access | Required |
| Tenant authorization tests | Automated negative tests across API, database and object access | Proves one company cannot read or change another company | Required |
| Monitoring and alerts | Request, job, integration, backup and security telemetry with owners | Makes silent failure visible before operations drift | Required |
| Backup and restore drill | Automated backup evidence plus successful tenant and platform recovery tests | Proves data can be recovered within the agreed operating target | Required |
Security FAQ
Recovery has to be designed before the first incident.
Clear tenant and recovery boundaries are part of the product architecture, not an emergency feature added later.
Can each last-mile company be backed up and restored independently?
The architecture can support tenant-scoped recovery packages and targeted restore. The restore must be tested in isolation, validated and approved before production cutover.
Does a separate database automatically make a tenant secure?
No. Physical separation can reduce some risks, but authentication, authorization, object access, secrets, audit, backups and operator procedures still need correct controls.
What RPO and RTO does NaviBatch promise?
No public production target is promised yet. Recovery point and recovery time objectives must be agreed for the operating scope and proven through backup monitoring and restore drills.
Evaluate security and recovery before real orders arrive.
A production pilot should agree identity, tenant boundary, backup scope, recovery targets and acceptance evidence in writing.