Travel and itinerary planning

An example app for saved itineraries, shared trips, permissions, scheduling, and AI-assisted planning.

Example app Built from planned modules. Not a customer. Not a supported app today.

Illustrative rule: trip members can edit, guests can only view

AgentEdit edict.yaml+13illustrative
Illustrative rule: trip members can edit, guests can only view. Line number, change, code. Lines under modules are added.
1modules:
2+Added data:
3+Added trips:
4+Added owner: user
5+Added roles:
6+Added member: [read, write]
7+Added guest: [read]
8+Added stops:
9+Added belongs_to: trips
10+Added fields:
11+Added place: text
12+Added arrives_at: timestamp
13+Added ai_planner:
14+Added requires_plan: premium

Placeholder values and unfinished syntax. Not a released feature.

What is the Travel and itinerary planning example app?

A traveler builds a trip as a list of days and stops. They invite friends, who can edit or just look. The app reminds everyone before a flight or a reservation time. A premium feature drafts a plan from a short description of the trip.

This category is a design target. It is not a claim that Edict already supports a complete travel app.

What backend does the Travel and itinerary planning example need?

  • Saved itineraries.
  • Shared records.
  • Permissions.
  • Scheduling.
  • AI planning.
  • Optional external location services.

How do the planned modules compose in the Travel and itinerary planning example?

The database is designed to store trips and stops as related records. Authentication and the database’s access rules would decide who is a member and who is a guest. Roles are stated once, and the backend is designed to check them on every request.

Background jobs are planned to send reminders at the right local time for each stop. For planning help, Authentication, Subscriptions, and the AI gateway are designed to work together, so only subscribed users can request a plan and each request counts against an allowance.

Optional location services, such as place search, are a separate matter. They would be controlled calls to an outside service and each one would be declared, not hidden.

What would an illustrative rule look like in the Travel and itinerary planning example?

The configuration above defines two roles on a trip and gates the planner behind a premium plan. The key names and the syntax are placeholders and are not final.

What is example and what is planned in the Travel and itinerary planning example?

All modules named here are planned and in development. No location or travel-data integration is listed as active, and none is promised. Your app owns the planning experience, the choice of any outside map or booking service, and the accuracy of what it shows. AI-generated suggestions need to be checked by the traveler.

See the Database and AI gateway module pages for the planned design. Join the beta waitlist to follow progress.

These share the most modules with this one.

See all example apps

Get an invitation when the beta opens.

Joining gets you email updates while Edict is built, and an invitation to the hosted beta when it opens.

Building now. No launch date yet.