Identity before access
Authenticated workspaces resolve the person, organization, membership, and role before account-specific information is returned.
Security and service boundaries
Trust is a system of checks, not a badge.
Business travel combines identity, preferences, service records, and payment decisions. Our operating model separates what Tanya can assist with, what a person must approve, and what the platform must verify before it changes customer state.
Control model
Four controls shape every business workflow.
Server-side authorization
Sensitive reads and writes are checked at the server. A hidden button or client-side route guard is never treated as an authorization boundary.
Tenant-scoped data
Partner records are linked to an explicit tenant identity. Production activation requires positive and negative isolation tests, including denial across tenants.
Observable operations
Commercial offers, payment transitions, support handoffs, and consequential service actions are designed to leave an auditable state rather than a success-shaped message.
Clear authority at every handoff.
- Tanya can gather context and explain supported information; it does not invent prices, availability, refunds, or completed actions.
- An authorized operator approves the commercial offer, service scope, currency, terms, and activation decision.
- Payment or entitlement value is provisioned only from verified server-side evidence and idempotent processing.
- B2B2C remains a design-partner capability until tenant isolation, onboarding, support ownership, and paid activation are proven for that deployment.
Readiness by deployment
Scope first. Verify before activation.
Security, privacy, support ownership, integration access, and commercial readiness are reviewed for the proposed operating model. Capabilities that have not passed their real authenticated and payment journeys remain disabled or explicitly identified as design-partner work.
Product information updated 29 August 2026