Platform vision · in development
Dependability starts
under the surface.
The engineering direction is built around bounded authority, traceable state and recovery when the outcome is uncertain. These are design principles, not a security certification.
Permissions follow the role
Guide, staff, customer, administrator, service and AI access are intended to follow least privilege. Viewing, operating and financially modifying a booking are different capabilities. Unknown permission should not become authorization.
Repeated events shouldn’t repeat the effect
Idempotent workflows are designed to handle duplicate, replayed and out-of-order events without creating repeated bookings, payments or messages. When an external action may already have happened, reconciliation should precede another attempt.
Unknown is a state worth preserving
Payment, inventory, communications and import outcomes can be ambiguous. The goal is to stop or reconcile when a protected action cannot be established safely, rather than guessing an unknown state into success.
History explains the present
Actor attribution, audit records and ledger-style financial, communication and loyalty histories are intended to retain causes, timing, adjustments and reversals. Signed waiver truth and payment history should not be casually overwritten.
AI uses the same boundaries
Automation is planned through a controlled operations interface and the same authorization and business rules as normal tools. It should not become an unrestricted route to databases, payments, refunds or guest information.
Each operator’s business remains their own
Commercial isolation requirements span data, permissions, travelers, payments, waivers, loyalty, files, reports, credentials, providers, webhooks and AI. These requirements need validation across the whole platform as commercialization progresses.
The standards behind the operating day.
These engineering principles guide the platform we're building. They support the operating experience described elsewhere on the site.
The price and the place are checked.
Availability can be quick to browse while the booking process rechecks the actual inventory and protects temporary holds. Prices and totals come from the platform, using exact money calculations, rather than independently calculated website or channel prices.
The aim: a consistent price and inventory picture, even when customers book at the same time.
A success screen isn't a payment record.
Payment confirmation is designed to rely on verified payment-provider evidence. A browser redirect, callback or confirmation page can't declare a booking paid. Analytics follows confirmed booking activity; it doesn't create financial truth.
Interrupted sessions and duplicate or out-of-order events need deliberate handling, not assumptions.
“Accepted” isn't the same as “delivered.”
The communications vision keeps intent, consent, recipient eligibility, delivery evidence and history together. Email and text providers deliver the messages; the platform retains the operating record.
If a send might already have happened, the design calls for checking and reconciling before trying again. Staff should be able to distinguish queued, accepted, delivered, failed and suppressed messages.
A transition that preserves your history.
Legacy and supported third-party guests should join the same manifest while keeping their original commercial source, external identifier and payment history. Migration planning includes validation before import, duplicate prevention, repeatable imports and reconciliation.
During a cutover, inventory must be reduced and verified in the old system before the same allocation is added to the new one.
The right access. A record of the action.
Guides, staff, customers and services are intended to have access appropriate to their role. Individual waiver access belongs to the intended traveler and can be revoked without rewriting signed records.
Important changes should retain who acted, when and why. Ledger-style financial, communication and loyalty histories preserve adjustments and reversals. Staff closeout should complete the operating day without rewriting payment or waiver history.
Automation with boundaries.
AI assistance is planned through the same permissions and business rules as other tools. Operational answers and specifically approved actions shouldn't require unrestricted access to databases, refunds or guest information.
As the platform grows to serve independent operators, each business's customers, payments, loyalty, files, integrations and credentials must remain isolated. If a protected action's state or permission is unclear, the design calls for stopping and reconciling.
This page describes TourFoundry's product direction. Availability, integration support and production readiness are subject to development and validation.