Talvionex Platform Guide

This is a working manual, not a marketing page. Each section follows the same shape — what it is, how it works, then how to use it as numbered steps — so you can read top-to-bottom the first time and jump back to a specific task later. If you only do one thing: follow Creating a new site, then come back for the feature chapters as you need them.

Talvionex is a multi-purpose AI website platform. It lets you spin up rich content and marketplace websites for any vertical, community, or niche - complete with AI-generated editorial pages, vendor listings, reservation/order workflows, and built-in SEO - in minutes instead of months.

Talvionex ships with 7 active verticals. Each has its own listing-type taxonomy, real-world schema fields (1,128 total across all verticals), and a dedicated public-side renderer that surfaces all the rich admin data on customer-facing pages. When you create a site, you pick the vertical and the platform configures the rest.

All 7 verticals share the same admin patterns, schema engine, vendor portal, reservation/order system, payments, and SEO surfaces. Switching verticals doesn't change how you operate the platform — only which listing types and fields appear in the admin forms and on the public pages.

The admin panel is organised into these main areas:

You can create a site in three ways. All lead to the same result — pick whichever suits your style.

The AI Builder is a one-prompt site generator. You describe what you want in plain language and it:

• Determines the correct site type for your vertical (island, portfolio, marketplace, retreat…)
• Decides which page types to create based on your vertical (home, recipes, portfolio, services, programs…)
• Writes full editorial copy for every page — intro, sections, FAQs, internal links
• Generates SEO titles, meta descriptions, and recommended URL slugs
• Creates a hero image prompt suggestion for each page
• Assigns quality scores and flags pages that need improvement

One prompt, two tools — combined build + content tasks

You can put content tasks directly in the build prompt. The Builder scaffolds the site from the brief, then detects the content instructions and runs them automatically as AI Jobs — so a single prompt produces a complete site (pages, places, listings, and articles), not just a skeleton. Each task uses the same engine as AI Activity. If a task can't be auto-applied (for example, real source-backed inventory that needs a research connector), it's staged in AI Activity for you to review instead of being lost.

Which lines become content jobs? Imperative instructions such as "Create 6 … listings", "Build a page 'Beaches' and create 10 places …", or "Create a … page about …". Your structured brief fields (Site name, Audience, Required output, Language, …) stay with the scaffold and are never mistaken for jobs. Tip: pick the "… + content tasks (build + AI Jobs)" recipe from the prompt dropdown for a ready-made combined example in your vertical. Keep using AI Activity after the build to add more pages, page groups, and listings whenever you like.

AI Activity is the tool for changing a site that already exists. Where the AI Builder generates a whole site from one prompt, an AI Job performs a focused, reviewable batch of edits — "add a Beaches page and the ten best beaches as places," "write content for the boat-tour listings," "translate everything to Greek." You describe the outcome in plain language; the platform turns that into a concrete plan of object changes, shows you the plan, and only touches your data when you approve it. Every job is recorded and can be undone.

The job lifecycle — step by step

This is the core loop. Preview is the safe default; nothing is written until you apply.

1. 1

   Describe the work. In the prompt box, name the exact objects and quantities you want. Be specific: "Build a page 'Beaches', create 10 places for the top 10 beaches with descriptions and photos, and add them to the Beaches page." Vague prompts produce vague plans. Tip: use the "Start from a predefined job prompt" dropdown above the box to drop in a vertical-specific starter, then edit it.

2. 2

   Click "Preview job". The AI reads your prompt, decides which objects to create or update, and returns a plan — a list of planned operations — plus a validation preview. Nothing in your site changes at this stage.

3. 3

   Review the planned operations. Each row tells you the action (create or update), the object type (page / place / listing / video / translation / menu group), the title and slug, and a short reason. For updates you also see a before → after snapshot, so you can confirm exactly what will change.

4. 4

   Apply the job. Click apply to commit the whole plan in one go. Newly created objects are added as drafts by default, or published immediately if you ticked "Publish created objects". Updates are written in place.

5. 5

   (Shortcut) "Run now" skips the preview and applies in a single step. Use it only for small, well-understood prompts — you lose the review gate.

6. 6

   Find it in the audit trail. The job appears in the AI Activity list with a status (completed / failed / needs review) and a timestamp. Click any job to re-inspect its operations.

7. 7

   Roll back if needed. Any job can be undone: created objects are deleted and updated objects are restored from their before-snapshots. Rollback is itself recorded, so the history stays honest.

What a job can create or update

Single page vs. pillar + cluster

The job decides its own shape from how broad your prompt is:

The guard rails

The same prompt skills drive both the AI Builder (a whole site from one description) and AI Activity jobs (specific objects on an existing site). The model fills any gap you leave with an assumption, so output quality tracks prompt precision: name the subject, the audience, the emphasis, and — for jobs — the exact object types and counts. This chapter gives you a formula, a weak-vs-strong rewrite, and a worked example for every vertical.

Anatomy of a strong prompt

Weak → strong, and why

Worked examples by vertical

Each shows a strong Builder prompt (whole site) and an Activity prompt (one job), plus what makes it work.

Builder prompts vs. job prompts

The Structured Builder uses guided forms instead of free text. It gives you more predictable output and is better suited when you know exactly which pages you want or when you are building a non-travel site.

After building with the Structured Builder, you can freely use all the same AI tools (per-page Generate, SEO Review, Quality Review, Fill Missing SEO) as with AI Builder sites.

A site isn't limited to the person who created it. You can invite collaborators, give each a role, and let them sign in with a password or with Google. This section covers how people get accounts and how you grant access to a site.

How people sign in

Self-signup & email verification

Public self-signup is off by default (the platform is invite-only). When an operator enables it, anyone can register at /admin/register:

1. 1. They enter their name, email, and a password. The account is created in a pending state and can't sign in yet.
2. 2. The platform emails a one-time verification link (valid 48 hours). Clicking it activates the account.
3. 3. Verification only confirms the email — it grants no access to any site. A verified user sees nothing until you invite them to a site's team (below).

The Team tab — invite collaborators

Open a site, then the Team tab. From there:

Who can manage the team? Only the site owner and Admins see the invite form and the role/remove controls. Editors can use everything else on the dashboard but not the Team tab's management actions.

Schemas let you define custom structured fields for marketplace listings. Instead of generic text boxes, vendors fill in typed fields specific to your niche - and visitors can filter the marketplace by those fields.

How to add a custom field — step by step

1. 1

   Open Admin → Schemas and pick the vertical and listing type you want to extend (e.g. Travel → stay).

2. 2

   Add a field and set its key (machine name, e.g. has_sea_view), label (what vendors see), and type — text, number, boolean, select, or tags.

3. 3

   Tick the behavior flags: Filterable (becomes a public facet), Visible on card (shows on listing cards), and for select/tags add the allowed options.

4. 4

   Save. The field now appears in the listing editor for that type — so every vendor creating that listing type gets the new input on the dynamic form.

5. 5

   Populate it on listings. Facets and card badges are built from real listing values, so a filterable field only appears publicly once at least one listing has a value for it.

Each vertical ships with a curated set of listing types, each with its own deep schema (real-world fields modeled after the leading platforms in that space). When you create a listing, the admin form changes shape based on the listing type — so a hotel room form looks like Booking.com, a food recipe form looks like NYT Cooking, a creator course form looks like Teachable.

Talvionex works best when each content type keeps its own job. This makes public pages easier to render, marketplace filtering more accurate, and future verticals easier to add.

Templates control the public look and structure of a site without changing its content, listings, pages, or public URLs. Use them to give each vertical a different visual system while keeping the same platform core.

Talvionex is not limited to travel. Any site that combines editorial content + a directory of suppliers or products can be built here.

Every vendor (the businesses, creators, providers, properties, or chefs you add to a site) gets their own self-service portal at /vendor. Vendors sign in with real scoped sessions and manage their own slice of the site — without touching the platform admin.

Reservations are the platform's full commerce primitive — they have check-in / check-out dates, guest counts, pricing snapshots, commission breakdown, and a payment lifecycle. The public booking widget creates a reservation, takes payment through Stripe Checkout, holds inventory until payment confirms, and releases availability if the checkout expires.

Any site can support multiple languages. The architecture stores translations in translations JSONB columns on pages, places, and supplier listings — meaning a single canonical record per entity, with per-field translations layered on top.

Beyond listings + reservations, each site has a stack of community surfaces — independently usable depending on what your business needs.

Before making your site public, make sure you've completed these key steps. The site dashboard has a live Launch Checklist that tracks your progress automatically.