Travel Advisor iQ is a body of hard-to-find, verified facts about the places and businesses luxury travel advisors sell, built so an advisor can stand behind every line of it in front of a client. The six pages that follow lay out that vision: starting from the advisor's side, then how we know what we know and how our own team keeps it honest, then the system underneath — architecture, data model, and how machines gather the facts. Each page stands on its own; the numbers below are the recommended reading order.
The other pages describe what we know and how we come to know it. This one is the advisor's side: what they are trying to do, what they see, and what they never have to think about.
Who the advisor is. A working luxury travel advisor with a client on the phone. They are paid for knowing things the client cannot easily find out: how many loungers are on the beach and whether they can be reserved, whether there is a hospital within twenty minutes, whether the kids' club runs in October. Today that knowledge lives in their head, in old emails, and in hours of calling resorts.
What the product is to them. A body of facts about the places and businesses they sell, with a chat as the main way in. Every place and business has its own page, and the catalog can be browsed and searched like any reference, but most of the time they simply type a place, a business, or a question in their own words and get an answer built only from facts we have published, each with a trust label and the date it was last confirmed. The answer is made of pieces, a fact, a business card, a map, a comparison, not a wall of text. When we do not have something, the product says so rather than guessing.
What they do with it. Open a business and read every fact about it. Put the places and businesses for a client into a trip, with dates, and turn the trip into a report with their own name on it. Keep the regions and partners they always sell on a watchlist and get told when a fact changes. Keep their own notes on any place. Tell us when they saw something different on the ground.
What it is not. It does not hold their clients' details and it does not contact anyone for them. It is the advisor's internal tool: a place to pull knowledge from, in whatever form they need to take it elsewhere.
What they never think about. Where a fact came from, who checked it, or whether it is current. The label and the date carry that. Advisors never see sources, quoted pages, or reviewers, and never see that a fact was ever questioned.
Words used below. A fact is one checkable statement about one place or business, with conditions such as season. The three trust labels an advisor sees, strongest first: Certified (the property said it), Verified (our team confirmed it), Corroborated (two independent sources agree). Facts with less support are not shown. A trip is a named bucket of places and businesses, with optional dates.
1The advisor
The product is built for one kind of user, and admitting only that kind is what makes it worth paying for.
Who gets in. Working travel advisors, and no one else. Sign-up looks like any product, but an agency is created by its first member and cites the accreditation it operates under; other members join by invite. Every application is checked before approval, and the applicant hears back within two days. Hosts, consortia, and larger agencies can bring every advisor in under one agreement, with the same facts delivered into the tools their advisors already use.
Why it is closed. An advisor's value to a client is knowing what the client cannot easily find out. A knowledge base anyone could open would hand that away and defeat the person we are building for. Keeping it to verified advisors is what makes it a professional tool the advisor relies on, and what lets it carry the price of one. Luxury travel is sold on access and discretion, and the tool advisors use to sell it should feel the same way: something few people have, worth more for that, and never a cheap, widespread lookup that erodes the advisor's edge and their client's reason to use one. Exclusivity is not a restriction on the product; it is the product's promise to the advisor.
What they get for it. Facts that are hard or slow to find, gathered to a depth no advisor could keep up alone, each one labeled and dated so it can be repeated to a client with confidence. And a place to put them to work: a trip, where the places and businesses for one client's travel are gathered with dates and turned into a report that carries the advisor's name and stays current. The rest of this page is what that looks like day to day.
2The loop
The same cycle, many times a week. The menu is five items: Home, Chats, Explore, Trips, Watchlist. Everything else appears inside one of those.
Brown: the client's requestNavy: asking and readingGreen: what the advisor hands over and keeps watchingGrey: what comes back to us
3It is a chat
Home is a dashboard with one input. Typing in it starts a chat. Chats lists the past ones, with a dot when something in one has changed.
The advisor asks in their own words. "Riviera Maya." "Casa Azul." "Adults-only resorts in Cabo with more than 200 beach loungers, good in June." Turning that into a search happens underneath and is never shown. If the answer misses the point, the advisor says so, the way they would to a colleague.
The answer is made of pieces. A sentence with its label and date. A fact row. A business card. A grid when the question is a comparison, each row a business and each column a fact, sortable, with more columns addable. A map when the question is about where. A report preview when the advisor asks for one. The product picks the pieces the question needs; the advisor never picks a mode.
Any piece opens at full size. A card becomes the business page. A grid becomes a comparison the advisor can keep working in. A map opens in Explore. Closing any of them returns to the chat.
Explore is the other way in. A high-performance globe and map with the places we cover as pins, layered by kind of business, and a details panel beside it that fills in as the advisor moves around. It is for finding things without asking: browsing a coast, seeing what sits near a resort, discovering what we cover in a region. Anything found there can be opened, added to a trip, or carried into a chat.
Filters, when wanted. A fixed set the advisor can learn once: where, kind of business, awarding body, brand or group, minimum trust label, freshness. Anything more specific, the advisor just says in the sentence.
"We don't have that yet." A legitimate answer, given plainly. Beside it: watch for it, so the advisor is told when the fact arrives, and request it, which tells us where to look next. The product never fills a gap with a guess, because the advisor is going to repeat the answer to a client with their name on it.
4Reading a place
Every business, ship, brand, and place has one page. The page is the facts; there is nothing else on it.
A business pageName and where it sits (country, region, town). Facts grouped by theme: beach, pool, rooms, dining, family, essentials nearby. Each fact shows its value, its conditions ("high season", "suite guests"), its label, and its last-confirmed date, with a thumbs up and a thumbs down beside it. Awards such as a Michelin star or a Forbes rating are badges. Facts are shown in the brand's own words where it has them: on an Explora ship a cabin is a suite, because that is the word the client will hear.
What is inside, and what it is inside ofA resort lists every restaurant, bar, and spa it contains, by name, grouped by kind with counts. A restaurant says which hotel it is in. All of it is a link. Nothing is hidden for being unremarkable; an advisor booking the hotel wants all four restaurant names, not the one with a star.
Places and regionsMarketing names such as "Riviera Maya" work as well as the ones on the map, because we store which real places they cover. A fact stored on a region, such as a hurricane-season advisory or the nearest international hospital, shows on every resort inside it, marked as inherited from the place.
5Trips, reports, watchlist, notes
The advisor's product is their advice. Ours is what makes it defensible, and a trip is how the two meet.
Trips and reports
A trip is a bucket. A name, optional dates, and the places and businesses for one client's travel, added from anywhere in a chat. Active or archived, nothing more. It holds places, never facts, and never the client's details.
Dates make the facts specific. Facts carry conditions such as season. With June dates on the trip, the advisor sees the June lounger count, the beach club closure that week, the festival that always falls on that weekend. Asking the chat for the critical information on the trip works over those same facts, selected for those dates.
A report from a trip. Every place and business in it, each fact with its label and date, the advisor's name, agency, and logo, and "Facts presented by Travel Advisor iQ." The advisor chooses which facts appear, and whether their own or their agency's notes go in. Two forms: a live link that stays current as facts change, or a PDF, which is a snapshot because paper is.
A report from one page. Any single business or place becomes a report in one click, as a snapshot. Live links exist only for trips.
Watchlist and notes
A trip watches what is in it. When a fact changes on anything in an active trip, the advisor is told, with a link back to the trip. Archiving the trip ends those watches, so a finished trip stops making noise. Anything the advisor had on the global watchlist before stays watched.
The watchlist is global. An advisor who sells one coast, or works with the same partners every season, watches them whether or not a trip is live. One feed shows both kinds, each item marked global or linked to its trip: what changed, old and new, label and date. A dot on the menu when there is something new.
Notes on any business or place, in two scopes: private to the advisor, or shared with their agency. Independent of trips. Never visible to another agency, never part of anything we license, never used to change a fact unless the advisor chooses to submit it as one. When building a report, the advisor can choose to include their own notes or their agency's, the same way they choose which facts appear.
Their own AI assistant. Any account can connect the assistant they already use and ask it questions that come back with our facts and labels. Same rules, same "we don't have that yet."
6Giving back
Advisors are on the ground more than we ever will be. The product treats what they saw as a source, with rules.
Thumbs upAsks one question: "did you see this yourself?" A yes counts as an independent source and can raise a fact's label. A no is recorded and changes nothing.
Thumbs downRequires a reason. It never changes a label by itself; it sends the fact to our team, and the advisor sees it marked "being re-checked".
A correction or a note submitted as a factGoes to our team as a candidate marked as coming from an advisor. The advisor sees it as pending, published, or declined with a reason. Nothing they submit is shown to other advisors until it has been through that.
7Where this could go
Not a requirement, and a direction we could drop entirely. Worth naming because the advisor would feel it first.
Everything above is a knowledge base: it exists to get facts out. A trip is the one thing in it that looks like planning, and it is kept deliberately thin so that it stays a bucket for a report.
The same trip could grow. Contacts on a trip, and sending the report to them directly. Day-by-day itineraries. Tasks with due dates. Invoices. A view of every client and every trip, which is to say a CRM built around the places advisors actually sell. At that point the product is a planning tool that happens to have the best facts in the industry underneath it, and it would be an upgraded tier, priced separately, with the knowledge base still whole on its own.
The line between the two is simple to hold: a feature is knowledge base if it gets facts out, and planning if it stores the advisor's own operating data. We are building the first. The second is a possibility the design leaves room for, and nothing more.
8Still to decide
Whether a business gets a summary score (the familiar 1 to 5) at all, and in what form. Trust labels are the only mark every fact carries; a score, if kept, would be computed from the facts underneath.
What an advisor may edit in a report beyond branding, the title, and which facts to leave out.
Whether a fact ever shows how many advisors confirmed it first-hand.
Live trip links: expiry, revocation, and whether we track opens.
Provisional access while a sign-up is being checked: a sample of destinations with no export, or nothing until approved.
Units, language, and currency in what advisors see: loungers versus sunbeds, metric versus imperial, local prices.
For the technical reader: names and choices behind this page
The chat
One query layer over published claims. An agent over a small tool set: search facts, get subject, compare, generate report, watch, note, add to trip. Every sentence grounded in a published claim with its tier and date inline. Answers render as typed pieces (fact row, subject card, grid, map, report preview) chosen by the agent. Query translation (place coverage, business kind, fact-type predicates with qualifiers, tier floor, freshness) is internal and never shown. MCP exposes the same tools to the advisor's own assistant.
A page
The subject document: published claims per fact type plus inherited ancestor-place claims, nearest wins. Never includes evidence. Containment from the "part of" edge; counts derived, never stored.
Trips
Agency-scoped entity: name, optional dates, Active or Archived, members are subjects (never claims). No contact or client fields at MVP. Dates select qualified claims by season and effective period in code; the trip screen's briefing (date-specific facts, changes since the last report, weak or missing facts) is built by code. There is no separate AI trip summary: a trip is selectable as chat context, and a briefing is an ordinary chat turn over its members and dates. No model call in the advisor product runs without an advisor action. Implicitly watches its members. Pending: add to the ERD and the data-organization page.
Reports
A stored list of the claim versions included, generated-at, renderer (web or react-pdf), optional trip reference. Live, self-updating share links only for trip reports; everything else is a snapshot.
Watch and notes
Watch is a consumer of published-claim changes, global or via trip membership, one feed; archiving a trip removes its implied watches and leaves explicit global watches untouched; delivery beyond in-app designed separately. Reports may include the advisor's personal or organization annotations, selected at generation like facts. Annotations at personal or organization scope on subjects, never in the licensed content set; "submit as claim" creates a candidate with advisor evidence.
Accounts and tiers
Organization (created by first user, accreditation type and number, accredited-under a host), Membership with role and branding overrides, Entitlement per plan or enterprise deal. Knowledge Base and Planning Tool are Entitlements; nothing to build for the second now.
The product is a body of knowledge about places and the businesses in them, where every single statement carries its evidence and a trust label. This page walks through how that knowledge is structured, top to bottom, using one resort as the running example.
What Travel Advisor iQ is. A body of destination knowledge for luxury travel advisors: resorts, restaurants, hospitals, pharmacies, transfers, ships, and the places they sit in. Advisors subscribe to it, put their name on reports built from it, and eventually other platforms and AI assistants license it. The data is the product; the website, the reports, and the API are ways of showing it.
How it is organized. Places nest inside places (country, state, metro area, city, district), and every business sits inside the smallest place that contains it, so a fact stored once on a region applies to everything below it. Marketing names like "Riviera Maya" are labels that cover several real places.
What a fact is. The unit of everything we sell. A fact is one specific, checkable statement about exactly one thing: a resort, a restaurant, a hospital, a ship, a brand, or a place. Not "Casa Azul has a great beach," but "Casa Azul has 200 daybeds on its beach, in high season, for hotel guests." Every fact carries five things with it: the subject it is about; the kind of fact it is (daybed count, reservation policy, nearest hospital), which sets how it is checked and how often it goes stale; the conditions it applies under, like season or who it applies to, so two true facts about the same beach can sit side by side; its evidence, meaning who told us, where it came from, and when; and its trust label, earned from that evidence. When a fact changes, the old version is kept, so we can always say what we believed and when. Everything else in the product, the search, the reports, the scores, the API, is just a way of showing facts.
How much to trust it. Every fact wears one of four labels, earned by its own evidence: Certified, Verified, Corroborated, and Reported. A resort is never certified as a whole; each statement about it is. Only the top three are ever shown to customers, and only a person or the property itself can raise a fact to the top two. Trust ages and gets re-checked on a schedule.
Where facts come from. Mostly AI research running continuously, plus our own team, the properties themselves, and advisors reporting what they saw. Everything enters as a candidate, gets its label from its evidence, is compared with what we already say, and is published or parked. A human looks before anything replaces a certified fact.
Where things stand. This is the proposed design, before any code. The label names are placeholders. The resort in the examples is fictional; the geography is real.
1The world we describe
Everything starts with geography. Places nest inside places, and businesses sit inside the smallest place that contains them. First the structure with our own labels, then the same structure with a real place.
The structure
Countrycurrency, entry rules, emergency numbers
Region / state / provinceseasonality, regional rules
Metro areahow advisors and clients refer to a destination
City / townthe legal locality; where hospitals, pharmacies and transfers actually are
District / neighborhoodwalkability, character, dining clusters
Businesskind: lodging
a resort, hotel, or villa collection
Businesses inside it, each its own thing:
Businessspa
part of the resort
Businessrestaurant
part of the resort
Businesspharmacy
standalone, nearby
Businessrestaurant
standalone, nearby
Businesshospital
standalone, nearby
Businesstransfer
any kind at all
Three more things live alongside the tree. A marketing region is a label that covers one or more of the places above; it is a place too, just outside the chain. A brand is the chain or group a business belongs to, and brands have parents. A ship is a business that moves between places on a route.
Marketing names. "Riviera Maya" and "Tampa Bay" are not cities. They are labels that cover several real places. Searching one finds everything inside the places it covers, pharmacies included, without anyone maintaining a list per business.
Not every place has every level. Monaco has no state; the Maldives is country, atoll, island-resort. The tree bends to real geography instead of forcing fake levels.
Knowledge flows downhill. A hurricane-season fact stored once on Quintana Roo applies to every business inside it. We store it once and every profile below inherits it.
Brands and loyalty
A brand is the name a business operates under, and brands have parents: a hotel flag sits under a hotel group, a cruise line under a cruise company, a restaurant under a restaurant group. We record the chain so an advisor can search by the name a client recognizes and so facts that are true of a whole brand (a kids policy, an all-inclusive definition) can be stored once and apply to every business under it. Who legally owns the building, and which parent company holds the brand, is not something we track beyond that chain; a parent is shown only when it means something to a traveler. Brands also get their own dictionary: Explora calls every cabin a suite, Virgin Voyages calls passengers Voyagers, and we say it their way whenever we are talking about them, while keeping our own word underneath so facts stay comparable across brands.
A loyalty program is tracked separately, because it does not follow ownership. Two lines under one parent can run different programs, and an independent hotel with no brand at all can belong to one. So a program is its own small list, and we record which brands and which individual businesses participate. Participation flows down the brand chain, with a business able to opt out or join on its own.
The question a client actually asks is "does this earn my points," and that is the question this answers.
Ships
A ship is treated like a resort that moves. It has the same kinds of facts a resort has (pool seating, dining, kids' clubs), the same evidence and trust labels, and it belongs to a cruise line the way a resort belongs to a hotel brand.
What makes it different is geography. A resort sits in one place. A ship follows a route: an ordered list of ports with a day for each, and a port is just a place we already know. A sailing is one run of that route by one ship on one departure date. Because every port is a place in our system, a sailing automatically comes with the destination knowledge for every stop, and the ship's home port is worked out from where its sailings begin rather than typed in by hand.
The line between a ship and a business: if it moves between places overnight with guests aboard, it is a ship. A sunset sail or a brunch cruise that returns the same day is a business in its home town.
2A fact, with receipts
We don't store "Casa Azul has a great beach." We store one specific, checkable statement at a time, about one thing, with the conditions it applies under and the evidence behind it.
AboutCasa Azul Beach Resort
Certified by the property
Daybeds on the beach: 200
Item: daybedSeason: high seasonFor: hotel guests
Holds since January 2026 · Published March 4, 2026 · Last confirmed March 4, 2026 · Re-check due yearly
The same resort has a separate fact for its 300 plastic loungers, and another for daybeds in low season. Different things, different numbers, different service. We never squash them into one "beach chairs" number.
Evidence (internal, never shown to advisors)
Email from the resortRooms director confirmed the count on March 4, 2026. Email on file internally. Marked as coming from the property.
AI research pass, Feb 20, 2026Read the resort's website and one travel publication; both said 200.
Earlier version, now retired"180 daybeds" from a 2025 review site, replaced when the property confirmed.
One fact, one thingEvery fact is about exactly one place, business, ship or brand. No vague "this area is nice."
Conditions travel with itSeason, who it applies to, which kind of item. That's how two true facts about the same beach coexist.
Nothing is deletedWhen a fact is replaced, or taken down because we learned it was wrong, the old version stays in history with the reason. We can always say what we believed and when.
Evidence stays insideEvery fact keeps its own receipts: who told us, where it came from, when, and what document backs it. Advisors see the label and the date those receipts earned, never the receipts themselves.
Words matter. "Sunbed," "lounger" and "beach chair" are one thing with three regional names, so we treat them as one. A daybed or a cabana is a different thing, so we never merge it in. Every time we decide two words mean the same thing, a person makes that call with a reason written down.
3How much to trust it
Every fact wears one of four labels. The label is earned by the evidence behind that fact, and only that fact. Nothing is ever below Reported, because a fact cannot exist without someone or something having put it there. A resort is never "certified" as a whole; each statement about it is.
Shown to customers.
Certified
The property itself told us: directly, through our team confirming it came from them, or in plain words on the property's own website (with the sentence saved). One exception: an award like a Michelin star is certified by the awarding body's own official list, for a short list of bodies we specifically recognize. Customers see "certified" and nothing more about how.
Only the property: its own site, or our team relaying it
Verified
Someone on our team checked it themselves: a site visit, a cross-check of independent sources.
Only our team
Corroborated
Two genuinely different sources agree: AI research on two different kinds of site, an AI pass plus an advisor who saw it first-hand, or two first-hand advisors. The same web page read twice does not count.
Highest a machine can assign; the lowest label customers ever see
Internal only, never shown to customers.
Reported
One source says so and we have not checked it yet. Tagged internally with where it was reported from: AI research, an advisor, or the web. Not shown to customers until a second source agrees or a person raises it.
AI research, advisor submissions; staff only
Separately from its label, a fact can stop being live. Every one of these keeps its history and its reason.
SupersededA newer fact took its place: 150 daybeds became 200. The old one stays in history.
RetractedWe learned it is wrong and have nothing to put in its place, so nothing shows for now.
DeclinedA suggestion that never made it in, closed with a reason. The person who raised it sees why.
🔒
The fixed rules. Customers only ever see Corroborated, Verified, and Certified facts. AI can fill an empty slot with a corroborated fact and can strengthen a fact up to Corroborated, but it never changes a published answer on its own before that fact is due for its re-check, and Certified and Verified facts are only ever changed by a person, with the reason written down.
⏳
Trust ages. Each kind of fact has a re-check rhythm matched to how fast it changes, from weekly to seasonally; we set and tune those. When the window lapses, the fact goes into the re-check queue and advisors see how old the confirmation is.
🧑💼
Our team can always override, with a reason that is recorded. Every label on every fact can be explained from its history.
4How facts get in and stay current
Most facts will be found by AI research running continuously. People handle the exceptions and the promotions.
Where information comes from
The propertyAn email, a call, a form, or plain words on its own website. The only route to Certified.
Our teamResearch, site visits, cross-checks, and the review of everything below. The route to Verified.
AI researchAlways running. Reads approved sources and proposes facts with the evidence attached. Never publishes over a person.
AdvisorsFirst-hand confirmations, disputes, and corrections from people who were actually there.
How the AI research worksNot one big crawl but small processes, one per kind of fact, each on a re-check rhythm matched to how fast that kind changes (weekly to seasonally; regional events right away). Each run looks only at what is due, reads only approved kinds of sources, records where everything came from, and produces candidates with receipts, never published facts on its own authority. Cost follows what is due, not the size of the catalog.
Disputes and correctionsAnyone who can see a fact can push back. A thumbs down with a reason flags it for a person; it changes nothing by itself. A correction with a new value becomes a candidate through the normal review. Our team can check any fact at any time, and every check is kept as evidence so we can watch accuracy by kind of source and tighten things when a number slips. Whoever raised a flag sees what happened to it.
The path a new piece of information takes
Something comes inAn email from a resort, a phone call written up by our team, an AI research pass, or an advisor's note.
It becomes a candidate: not yet visible to customers.
It gets its labelThe evidence decides the trust label automatically. Who said it and where it came from.
Certified, Verified, Corroborated, or Reported (with its origin).
Compared with what we already sayIf it agrees, it strengthens the current fact. If it disagrees, it waits: nothing automatic changes a published answer before its re-check date, and a person decides anything that touches a Certified or Verified fact.
Once a fact is due for re-check, a better-supported corroborated answer can take over.
Published or parkedOnly Corroborated or better ever publishes on its own. The winner becomes the current fact; the previous version is kept as history; rejected candidates are closed with a reason.
Scores, like the 1–5 beach rating, recompute from the facts underneath.
Re-checked on scheduleEach fact comes up for review on its own cadence. Only what is due gets re-researched, which keeps AI costs proportional.
Advisors always see "last confirmed."
The beach chair test: two ways the same fact gets challenged
Casa Azul's beach has a certified fact: 200 daybeds in high season. The resort's rooms director confirmed it by email in March. Two things happen later in the year.
An advisor's client comes home and says there were only 100. The advisor types that into a note and submits it. It becomes a candidate fact, labeled Reported and marked as coming from an advisor. It does not touch the certified 200, because nothing automatic is allowed to replace a certified fact. Someone on our team looks. They call the resort, or check the advisor's dates against anything else we have, and learn the resort had half the beach closed for a private event that week. The candidate is closed with that reason written down. The advisor sees "declined: one-off event" on their submission. The certified 200 stands, and if this keeps happening the team can add a separate fact about private-event closures so future advisors are warned.
In November the resort announces a new beach policy on its website: daybeds are now reserved for suite guests only. Our AI research reads it on the resort's own site. That counts as the property speaking, so the candidate is Certified from the moment it is captured, with the exact sentence saved as its receipt. It still does not replace the March fact by itself: a certified fact is only ever changed by a person. A team member reads the announcement, agrees, and publishes it as the new certified fact for that condition. The March fact is retired but kept in history, so a report generated in June still shows what we believed in June, and anyone can see exactly when and why the answer changed.
The point: the system never silently believes the last thing it heard, and it never silently ignores it either. Every challenge is recorded, a person decides the ones that matter, and the reason is kept.
5Who uses it, and how
The same facts, rendered different ways. Nothing is built for one channel.
Advisors and agencies
Sign up like any product, but only working travel advisors get in: every account cites the accreditation it operates under and is checked before approval, within two days.
Ask in plain words, or by the names people actually use, and see every fact with its conditions, its label, and when it was last confirmed. The evidence behind the label stays with us.
Put the places and businesses for one client's travel into a trip, with dates. A trip is a bucket, nothing more: it holds no facts and no client details. Its dates pick out the facts that apply, so a briefing on the trip, in the chat or on the trip screen, is specific to when the client is going.
Keep private notes on any resort, for themselves or their whole agency. Never visible to anyone else, and never part of the licensed data.
Connect their own AI assistant. Any account can plug the intelligence into Claude or a similar tool and ask questions that come back with facts and labels.
Give feedback on any fact. A thumbs up on something they saw first-hand counts as a source. A thumbs down with a reason sends the fact for review; it never changes a label by itself.
Suggest a correction. It becomes a Reported candidate from an advisor, enters the same review path as everything else, and the advisor sees it as pending, published, or declined with a reason.
Watch a resort or a destination and get told when a published fact changes. An active trip watches what is in it; archiving the trip ends those watches, and anything on the advisor's own watchlist stays watched.
Reports
From one page. From any city, resort, or business, one click makes a snapshot of all its published facts, with the option to leave specific facts out.
From a trip. Every place and business in the trip, with the facts that apply to its dates, the same ability to omit facts, and the option to include the advisor's own notes or their agency's. Two forms: a live link that stays current as facts change, or a PDF snapshot. Live links exist only for trips.
Branded. An organization can put its own branding on downloaded PDFs. Every report still carries a "Facts presented by Travel Advisor iQ" mark, so the source of the intelligence stays visible.
A snapshot is what was published at the moment it was generated. Facts change; the labels and dates say so, and Watch tells the advisor when to regenerate.
Enterprise and licensing
Host agencies and consortia. A deal with a host like Fora or a consortium gives every advisor in it access under one agreement, at volume pricing, without each advisor signing up and being verified on their own.
Into their portal. The same facts, labels, and dates delivered through the API into the tools their advisors already use, white-labeled if they want, and never the evidence.
Platforms. Travel software and AI products that license the data outright, metered by use.
Brands. Hotel groups, cruise lines, and other suppliers who want to see how they compare to competitors on the facts advisors actually use, and partnerships where a brand certifies its own facts across every property it operates, so everything about them carries the top label.
6Why it is built this way
The data is the product
A website with a database behind it cannot later become something you license. A body of attributable facts can be rendered as a website, a report, an API or an AI answer with no rebuild.
Labels make claims usable
Advisors put their names on this in front of high-value clients. A per-fact label with a date is something they can stand behind. A resort-wide badge is not.
Rebrands and reorganizations don't break anything
Every place, business, ship and brand keeps one permanent identity with its name history. A resort that changes its name, or two records that turn out to be the same resort, keep working.
Honest about AI
Most facts will start as Reported, found by AI research. Hiding that would leave the product empty; showing the origin plainly is more credible than implying a person checked everything.
For the technical reader: what these are called in the data model
Places, businesses, ships, brands
Subjects. Anything a fact can be about, sharing one permanent ID space with name history and merge records.
Marketing names that cover real places
Places of kind "marketing region" with a covers relationship.
A fact
A Claim whose status is Published. Candidates, superseded and retracted versions are Claims too.
Conditions on a fact
Qualifiers: item type, season, guest segment. Part of what makes a claim unique.
Receipts
Evidence, owned by the claim: who produced it, which type of trusted source it came from plus the page URL, whether the property or a first-hand witness stands behind it, and whether it supports or disputes the fact.
Thumbs up / thumbs down
Advisor feedback: evidence with outcome supports or disputes. First-hand confirmations count as a source.
Trust label
Trust tier, computed from the claim's evidence. Admin overrides are themselves evidence.
Kinds of fact and their schedules
Fact types: the rulebook, stored as data.
Private notes, watching
Annotation and Watch, on the accounts side, never in the content set. Annotations may be included in the advisor's own reports.
A trip
Trip: an organization-scoped bucket of Subjects with optional dates and an active or archived status. A Report may reference it; live share links exist only for trip reports. Never holds claims or client data.
Full diagram: erd.html (conceptual ERD). The AI research pipeline: pipeline.html. How our team makes and checks facts: admin.html. How an advisor uses the product: advisor.html.
Most facts will be found by machines. This page is about the admins, our own team: what they enter by hand, what they review, how they keep the machine honest, and the tool they do it in. Advisors never see any of it.
Two flows, one set of rules. The AI pipeline reads approved websites on its own schedule and proposes facts with receipts. Admins enter facts by hand, decide what the machine could not, and check the machine's work. Both produce the same thing, a fact with evidence attached, under the same publishing rules. The difference is who is allowed to do what.
The rule that matters most. Only an admin, or the property itself, can raise a fact to Certified or Verified, and only an admin can change a fact that already carries one of those labels. The machine can fill an empty slot and add agreeing evidence, and nothing more.
Where the work happens. A separate internal tool behind a separate login, with four parts: an entry screen, a review queue, spot checks on published facts, and the list of website kinds the machine may read. Advisors see a fact's value, conditions, trust label, and last-confirmed date. Who entered it, what page it came from, who reviewed it, and why stay inside the tool.
What it costs. Machine reads cost a fraction of a cent. A queue item costs minutes of an admin's time. The queue, not AI usage, is the operating cost of the content side, and the team size follows it.
Words used below. A fact is one checkable statement about one thing, with conditions such as season. Evidence is who told us, where, when, and the receipt. The trust labels, strongest first: Certified (the property said it), Verified (an admin confirmed it), Corroborated (two independent sources agree), Reported (one source, unchecked, never shown to customers). A candidate is a fact that has arrived but is not published.
1The two flows
The admins' flow is drawn in full. The AI pipeline is the box with the double edges, the flowchart symbol for a process defined elsewhere. Only the arrows between the two are spelled out.
Brown: where information comes fromNavy: admins at workGreen: what advisors seePurple: the AI pipeline, on its own pageGrey: what admins feed back
The hand-offs
AI to adminsA read that disagrees with a published fact, comes back with low confidence, touches a Certified or Verified fact, or needs someone to confirm a website is the property's goes to the queue with the side-by-side already written.
AI to advisors, on its ownWithin the rules the machine publishes unwatched: it fills an empty slot with a Corroborated fact and adds agreeing evidence. Never past Corroborated, never over a published value before that fact comes due.
Admins to AIFour things: the approved kinds of source, spot-check results, "re-check this region now", and AI-found facts that have come due.
Admins to advisorsA fact entered on the entry screen publishes on save with the label its evidence earns. Saving is the decision. Replacing a Certified fact asks for an explicit confirm.
Advisors to adminsA thumbs down with a reason, a correction, or a private note submitted as a fact lands in the queue as a candidate from an advisor. A first-hand thumbs up needs no review; it counts as one more source.
Re-check, split by labelWhen a Certified or Verified fact comes due an admin re-confirms it. When anything else comes due it goes back to the machine. Advisors keep seeing the fact with its last-confirmed date meanwhile.
2What arrives by hand, and the label it earns
The label is computed from the evidence, never chosen. The question at the entry screen is "who stands behind this?", not "how confident are we?"
What comes in
What the admin records
Label
The property tells us directly
An email, a call written up, a form, or a page on the property's own site. Channel and contact recorded internally; attachment or quoted sentence kept when there is one.
Certified. Customers see only "certified by the property."
An admin checked it
A site visit, a call to someone who would know, or a cross-check of two sources. What was checked and how.
Verified
A recognized awarding body lists it
A Michelin star or a Forbes rating read from the body's own official list. The list of recognized bodies is short and deliberate.
Certified, the only third-party route to it.
An advisor confirms it first-hand
A thumbs up that answers "did you see this yourself?" with yes. Attributed to the agency, shown to no one.
One independent source. Two of these, or one plus a machine read, make Corroborated.
An advisor disputes or corrects it
A thumbs down with a reason, or a suggested new value. Goes to the queue.
Reported until an admin acts. The advisor sees pending, published, or declined with a reason.
Existing data is imported
A spreadsheet or export, with the label the batch starts at declared up front.
Whatever the batch declares.
3The queue and the entry screen
One list of everything that needs an admin's decision, and one screen for everything an admin enters. Every action records who, when, and why; nothing closes without a reason.
What lands in the queue
A disagreement. The machine found something that contradicts a published fact. Both sides arrive laid out: current fact, new reading, quoted sentences, and the machine's guess at why (a real change, a seasonal condition, or two pages that are not independent).
A low-confidence read. A value the machine is not sure it read correctly.
Anything touching Certified or Verified. Even a confident, well-supported read waits for an admin.
"Confirm this website." A likely official site found on one signal only.
A dispute or correction from an advisor.
A Certified or Verified fact that has come due.
A "worth a look" suggestion. Optional: a short rotating list weighted toward new kinds of fact, new kinds of source, and the most-viewed resorts.
What an admin does with an item
Publish the candidate. The old fact is kept as history.
Decline with a reason category and a note. Whoever raised it sees the outcome.
Correct it with the admin's own checking as evidence. That makes it Verified.
Ask the property and come back with the answer. That makes it Certified.
Re-confirm a fact that has come due.
The entry screen
Subject and kind of fact. A resort, restaurant, ship, brand, or place; then the kind, from the list the product already knows.
Value, conditions, dates. In the shape that kind expects, plus season, room category, or who it applies to, and when it holds.
Evidence. Channel, kind of source, property contact, attachment or quoted text. The admin's identity is recorded automatically.
The label, computed. Shown before saving. An admin can override it only by writing down why; the override is stored as evidence.
Save. Publishes, unless it contradicts a Certified fact, in which case the screen asks for an explicit confirm.
The queue is the budget. One continent of beach resorts at full depth means a few hundred items as the catalog fills; launch scope, several thousand. The dials are upstream: how sure the machine must be before it proposes a fact, which kinds of source it may read, and how many facts come due in a month. Also behind this login: advisor sign-up checks (each application arrives with an AI summary sorted into approve, needs a look, or reject; every one read by an admin at first, about a minute each, with a 48-hour promise to the applicant) and a view of the machine's runs, which is the observability tool's own screens. Not here: editing the kinds of fact, which is a code change, and advisors' private notes, which are theirs.
4Keeping the machine honest
Two controls, both in admins' hands: what the machine may read, and how much its reads are trusted.
The approved kinds of source. A list of a few dozen lines, by kind, not by website: the property's own site, the property directly, the Google listing, named travel sites considered one at a time, the recognized awarding bodies, advisor feedback, admin checks. Each line carries whether it is allowed, what its terms of service permit, and the credibility it has earned. Adding a kind is a one-line decision by an admin. Never on it: forums, social media, review aggregators, booking sites, online travel agencies. Pages from anywhere else land in a low-credibility "other web" bucket that can never certify or corroborate.
Spot checks. Any admin can open any published fact, look at the receipt (the stored page, the quoted sentence, the date read), and mark it correct, wrong, or unclear with a reason. A wrong mark with the right value becomes a Verified correction on the spot. Checks roll up by kind of source: a kind that keeps coming back wrong loses credibility and needs more agreement before it publishes; a reliable kind gains it. No one adjusts those numbers by hand. Every judged example joins the test set the machine must pass before any change to its instructions or model goes live. Nothing retrains a model; the checks change what the machine is allowed to publish.
5A reviewer's morning
Three items from one queue. Casa Azul Beach Resort is fictional.
A disagreement
Overnight the machine read on Casa Azul's site that daybeds are now reserved for suite guests, contradicting the Certified fact that they are open to all guests. Certified, so the machine could not act. The admin sees both sentences and the machine's note that this looks like a policy change, agrees, and publishes the new fact as Certified, since it came from the property's own site. The old fact goes to history. Three minutes.
An advisor's dispute
A client reported 100 daybeds, not 200. The admin checks the dates against a note on file: half the beach was closed that week for a private event. Declined as "one-off event", the advisor sees that outcome, and the admin adds a private-event-closure fact so the next advisor is warned. Five minutes.
A Verified fact come due
"Waiter service on the beach: yes" was Verified by phone nine months ago. The admin calls, hears it is now high season only, and enters the corrected fact with the condition attached, this time Certified because the property said it directly. Four minutes, mostly on hold.
Twelve minutes, three decisions, each with a reason on record. Meanwhile the machine read forty other resorts overnight and published what it was allowed to.
6Still to decide
Build the tool or generate it. An admin framework gives list views, filters, roles, and audit trail for free and leaves the review workflow to build; a custom build gives total control at more upfront cost. A one-day trial against the real data model once the first dataset is in hand.
Team size. Follows the queue: items per week and minutes per item from the proof-of-concept scope.
Whether a fact's displayed label drops when it comes due, or only its last-confirmed date ages.
Whether advisors ever see how many first-hand confirmations a fact has.
Provisional access while a sign-up is being checked, or nothing until approved.
For the technical reader: names and choices behind this page
The internal tool
Separate app behind staff SSO on the same API as everything else. Open: Payload CMS generating the admin shell versus a custom Next/React build; one-day spike after the first data review.
Entry screen
Creates a Claim (status candidate) with one Evidence record (kind, actor, source type, attestation, artifact, contact). Tier computed by the single tier function; a manual tier is an admin-assessment Evidence record with a required reason.
Review queue
A query over candidate claims and disputes ordered by wait time and support, not a separate entity.
Spot checks and sources
Evidence records of kind "check"; roll up to Source bank credibility per source type; judged examples become the Langfuse dataset for prompt and model evals. The pipeline whitelist-checks every URL against the Source bank before fetching.
Sign-up checks
Accounts-side verification record (signals, AI summary, three-bucket score, decision, reason), separate from content evidence; one switch for auto-approval of the clear bucket.
The data model (erd.html) says what we store. The research pipeline (pipeline.html) says how machines find it. This page is the rest: one deployment, one database, and the handful of vendors around them, and why. For a technical reader; nothing here is built yet.
One app. A single Next.js codebase on Vercel serves the marketing site, the advisor portal, the admin tool, the REST API, and an MCP server for advisors' own AI tools — one deploy, one place to enforce login and entitlements.
One database. Neon Postgres, through Drizzle, holds everything: the content side (places, businesses, claims, evidence) and the account side (users, organizations, entitlements) in separated schemas, plus pgvector for search. Nothing else keeps its own copy of the truth.
A pipeline that runs on its own. The AI research pipeline (pipeline.html) is a scheduled background process, not application code — nothing an advisor does triggers a live web crawl. It writes into the same database everything else reads.
Five vendors carry the rest. Cloudflare in front for CDN and DNS, Better Auth for identity, Stripe for billing, Resend for email, and Langfuse/Sentry/PostHog watching everything. First-party integrations, no glue code holding them together.
Why it looks this plain. Two people are building this. The stack optimizes for the fewest seams, not the most control — see why this stack for the tradeoffs and the one still open.
1The stack, layer by layer
Seven layers, roughly the order a request passes through them. The AI pipeline is the one exception — it runs on a schedule, not a page load, and joins the database from the side.
Whoadvisors and staff in a browser, a public visitor on the marketing site, a partner or licensee's server, or an advisor's own AI assistant
Sendsa page view, an API call, or an MCP tool call — all HTTPS
Lands onthe same API underneath, whichever door they came through
One thing to secure and version. Partners and licensees get metered API access; an advisor's own AI tool reaches MCP with the same login and entitlements as their portal account.
Cheap, first-party, and keeps a door open: moving heavy API traffic to Cloudflare Workers later becomes a routing change, not a rebuild.
3. App — Vercel, one Next.js appTypeScript
Inrequests that need code: pages, API routes, MCP calls
Doesmarketing, the advisor portal, admin, the REST API, and the MCP server all live in one deployment
Outreads and writes Postgres, calls Better Auth and Stripe, renders reports
One codebase, one deploy, one place to enforce access and entitlements — the right shape for two people. The API is typed handlers on Drizzle, so it can lift out to Workers or a container later without moving the model underneath it.
4. Identity & billing — Better Auth, StripeVendor
Insign-up, sign-in, plan changes
DoesBetter Auth: email/magic link, social login, enterprise SSO, API keys, organizations. Stripe Billing: plans and usage metering, via Better Auth's own plugin
Outa session or API key the app trusts; a plan the app checks against
Identity and money are the two things least worth building ourselves. Both are first-party integrations into the same app, not separate services to babysit.
5. Data — Neon Postgresvia Drizzle
Ineverything the app and the pipeline read and write
Doescontent (subjects, claims, evidence) and accounts (users, orgs, entitlements) sit in separated schemas, so copying content down to staging is a scripted, safe operation that never touches real people. pgvector lives alongside for search.
Outthe subject document — one document per place or business, published claims only — that the API, search, MCP, and reports all read the same way
Postgres regardless of vendor. Neon over Supabase or RDS because branching supports staging and copy-down, read replicas cover international later, and pgvector avoids standing up a second store. Report PDFs and media sit in object storage alongside it, not in Postgres itself — leaning Cloudflare R2 for its zero-egress reads on links that get shared and reopened; Vercel Blob is the alternative. Not yet decided.
6. AI research pipelineBackground
Inthe fact-type rulebook and what's missing or due for a re-check
Doesruns on its own schedule (Trigger.dev or Inngest), outside the request path. Firecrawl fetches pages; OpenAI reads and reconciles them into candidate claims. Full detail: pipeline.html
Outcandidate and published claims, written into the same Postgres content schema the app reads
A separate scheduled process, not application code, so a slow crawl never blocks a page load, and cost scales with what's due, not with traffic.
7. Observability & opsWatching, not writing
Inevery model call, every request, every email send
DoesLangfuse traces every OpenAI call, pipeline and chat alike, tagged by component/org/user; Sentry and PostHog watch the app; Resend sends transactional email
Outdashboards and alerts — nothing here writes back into the product
When a fact is wrong, or a page is slow, there's one place to look, not a guess.
2Where things run
Three environments, and a compliance posture set from month one rather than retrofitted later.
Dev, staging, prodNeon branches per feature; Vercel previews per branch. Prod is the source of truth.
Content copies down, accounts don'tPlaces, businesses, and facts copy to staging after releases, with a scrub step. Orgs and users never do. Dev gets occasional copy-downs.
Compliance-friendly by defaultSOC 2 and GDPR will matter fast: audit logs on every change, soft deletes with retention, no PII in logs, secrets in a vault, staff SSO. A Vanta/Drata-style tool documents this later; it doesn't create it.
3Why this stack
The reasoning behind the choices above, and the ones still open.
Boring and cohesiveTwo-person team, fewest seams wins. Five vendors, first-party integrations, no glue code.
Neon over Supabase or RDSPostgres regardless; Supabase's bundled value drops once you're not using its generated API. Branching and read replicas matter more here.
Vercel over Cloudflare WorkersEdge helps marketing and report links; it helps far less for a logged-in portal that round-trips to Postgres anyway. This keeps Cloudflare for DNS/CDN so the heavy pieces can move later.
API and MCP first-classThe API is versioned, scoped, rate-limited, and metered from day one — the moat. MCP is cheap once the API exists.
One AI vendorOpenAI end to end for anything a customer reads; not Anthropic (cost per turn), not a multi-vendor gateway. Switching is configuration; an eval decides. See pipeline.html.
Admin: open decisionPayload CMS (generates admin UI, roles, drafts from our schema) versus a custom Next/React admin. A one-day spike is planned once the data review is done.
Object storage: open decisionLeaning Cloudflare R2: S3-compatible, zero egress on signed-URL reads, which fits reports built to be shared and reopened as links. Vercel Blob is the alternative — simpler (no separate vendor keys), but private delivery routes through a Function and bills both hops. Decide before build.
4Still open
Payload vs. custom admin — a one-day spike against the real data model, once it's open to review.
Object storage: Cloudflare R2 vs Vercel Blob — leaning R2 for zero-egress reads on shared report links; a technical decision to make before build, not locked.
When to add a Neon read replica and a second Vercel region, for EU/APAC licensees.
Whether and when heavy API traffic moves to Cloudflare Workers, if Vercel pricing gets ugly at scale.
When a Vanta/Drata-style compliance tool gets added, once SOC 2 work starts in earnest.
The entities and relationships behind everything on the other pages: what we keep, what points at what, and the rules that hold it together. Key attributes only; no column types or implementation detail. Nothing is locked, and the trust-label names are provisional.
Subject. Anything a fact can be about: Place, Business, Ship, Brand. One permanent ID space with a name history, external identifiers (Google Place ID, legacy IDs), and a merge record, so an ID resolves forever through rebrands and duplicates.
Place. A containment tree of variable depth; every place has a kind (country, region, city, district, island, marketing region) rather than a fixed level. "Covers" lets a marketing name such as Riviera Maya span real places. Facts inherit down the parent chain, nearest wins.
Business, Brand, Ship. A business is any venue with one location, nested with "part of" (a spa inside a resort). A brand has a parent chain and can carry facts of its own that inherit to its properties. A ship is a subject that moves: routes are ordered place stops, sailings are dated routes.
Claim. One typed, dated assertion about exactly one subject, with conditions (season, guest segment, item type) that keep "200 daybeds in high season" and "120 in low season" apart. Exactly one published claim per subject, fact type, and conditions at a time. A "fact" is a published claim. Old versions are kept; nothing is deleted.
Fact type. The rulebook, stored as data: value shape, which kinds of subject it applies to, which conditions it supports, re-check rhythm, allowed source kinds.
Evidence. Owned by its claim; every claim has at least one. Who produced it, which kind of source, the page URL, who stands behind it (the property, an awarding body, a first-hand witness, or no one), whether it supports or disputes, and the artifact. Internal only: never shown to advisors, reports, the API, or partners.
Trust tier. Lives on the claim only, computed by one function over its evidence: Certified, Verified, Corroborated, Reported. Customers see the top three. An admin override is itself an evidence record with a reason.
Glossary term. Synonyms merge (sunbed, lounger, beach chair); subtypes do not (a daybed is narrower than beach seating). Brands carry their own preferred labels; claims store the canonical term.
Accounts and output. Organization, Membership, User, Entitlement. Annotation is a private note, never licensed. Watch follows a subject. Trip is a bucket of subjects with optional dates; a Report is a point-in-time bundle of claim versions, optionally from a trip. Only trip reports get live links.
2Still open
Which conditions, exactly. Item type, season, guest segment to start; room category likely fourth. Decided against the first real dataset.
Starting tier for imported scores, declared per batch once the data is inspected.
Whether the displayed tier drops when a fact comes due, or only the last-confirmed date ages.
Route stops as their own entity when ships are built.
Whether a first-hand advisor count or origin is ever shown to customers. Evidence itself never is.
Most of the intelligence will be found by machines. This page walks the path from "we need to know this" to a published fact: who does each step, the rules that keep a machine from publishing something a person would not stand behind, and what it costs.
What it is. Small automated jobs on their own schedules. Each one knows which facts are missing or due for a re-check, reads the business's own website and a few approved travel sites, turns the text into typed facts with the exact sentence quoted, compares them with what we already publish, and applies the publishing rules. People handle the exceptions.
Who does what. Plain code decides what to look for and where. A fetching service turns web pages into clean text. A cheap AI model reads that text into facts. A stronger reasoning model steps in only when sources disagree. Code applies the rules. Nothing is published because a model felt confident; it is published because the rules were met.
What we go after. Depth, not breadth: the facts that are hard or slow for an advisor to find. How many daybeds, whether they can be reserved, waiter service on the sand, what seaweed season does to the beach. Scope is set by region and kind of business, and every business in scope gets the full set of facts for its kind. Proof of concept is every beach resort in one continent at full depth; launch is earned when the rest of the world's resorts and top hotels are done the same way.
What comes out. Candidate facts with receipts: which page, which sentence, when. The receipt earns the label. A fact read plainly from the property's own site is Certified; one read from an approved travel site is Reported until a second, independent source agrees, which makes it Corroborated. Only Corroborated or better is ever shown to an advisor, and only a person can change a Certified or Verified fact.
What it costs. A fraction of a cent per fact. A deep read of one resort is about two and a half cents; the whole proof of concept about forty dollars; launch a few hundred to build and under a thousand a year to keep current, on about $100 to $160 a month in subscriptions. The real cost is the people who review what the machine cannot decide.
Not on this page. The human side, where facts also arrive from the property, our team, and advisors and every one passes through a person: admin.html. Notifications and alerts, which consume published facts and are designed separately.
1The path, end to end
Seven stages. The colored edge says who runs it: code is predictable and free, the two AI models are the only places judgment happens, and the stronger one is used sparingly. One fact at a fictional resort follows the path.
CodeFetching serviceOutside sourcesCheap AI modelReasoning AI modelObservability
1. Decide what is neededCode
Inthe rulebook, every business's current facts, each fact type's re-check rhythm
Doeslists which facts are missing or past their re-check window; adds regional events when they happen
Outa queue of work items: this business, these fact types
Only what is missing or due is researched. Each kind of fact has its own rhythm, weekly to seasonal, so cost follows what comes due, not the size of the catalog. A hurricane, a border change, or a strike pushes a whole region to the front of the queue.
Casa Azul Beach Resort
No high-season daybed count has ever been captured, so that fact is due now.
2. Decide where to lookCode
Ina work item for one business; what we already know about it; the approved kinds of source
Doespicks the pages to read, in order of trust: the business's own website first, then a few approved travel sites
Outa short list of page addresses we are allowed to read
The official website is found once from the Google listing (or one checked search), stored, and reused. When two signals agree it is the site, for example the listing names it and the phone number matches, it counts as the property speaking and plain statements on it can be Certified; with one signal, a person confirms it once, only when a Certified fact is waiting on it. A model never decides where to crawl.
Casa Azul Beach Resort
The beach page on the resort's confirmed site, plus one article from an approved travel site. A review site that came up is dropped before anything is fetched.
3. Fetch what is dueFetching service
Inthe page addresses from stage 2; the Google listing when its basics are due
Doesfetches each page past scripts and bot blockers and returns clean text; reads PDFs too
Outevery page stored on our side as a receipt, with time and fingerprint
We rent this rather than build it. Everything downstream reads our stored copy, never the live web: a page that has not changed is not read again, and no advisor question ever triggers a call to a website.
Casa Azul Beach Resort
The beach page, stored 2026-09-10, reads in part: "...our beach club offers 200 daybeds for resort guests during high season, with an additional 300 loungers available..."
4. Read pages into factsCheap AI model
Inthe stored page text, plus the definitions of every fact type for this kind of business
Doesreads the pages once and pulls out every fact it can find, with its conditions and the exact sentence
Outcandidate facts with receipts attached
One rule: only what the page says, quoted, with the conditions (season, who it applies to, which kind of item) and a score for how sure it is. If the page does not say it, the model says nothing. One read pulls every fact; the model is never asked thirty questions about the same page. Each brand's own vocabulary is applied first, so "suite" on a cruise line's page is understood as their word for a cabin.
Casa Azul Beach Resort
Two candidates from the property page: daybeds, high season, hotel guests, 200 (sure: 0.96); loungers, 300 (sure: 0.93). The travel article says "plenty of daybeds" with no number, so nothing is taken from it.
5. Compare with what we already sayReasoning AI model
Inthe new candidates; the fact we currently publish, if any; other candidates for the same fact
Doesdecides whether the new information agrees, disagrees, or is not about the same thing
Outstrengthen, wait, replace, or send to a person
Agreement is handled by code: the receipt is added as evidence, and agreement from a different kind of source raises Reported to Corroborated. Only genuine disagreements, about one pass in five, reach the stronger model, which decides whether it is a real change, a seasonal condition, or two sources that are not independent, and writes the side-by-side a reviewer would see. A disagreeing candidate waits until the published fact comes due; if the published fact is Certified or Verified it always goes to a person.
Casa Azul Beach Resort
No published daybed fact exists yet, so there is nothing to compare.
6. Publish or parkCode
Inthe decision from stage 5 and the publishing rules
Doesapplies the rules; publishes, retires the old version, or sends the item to the review queue
Outthe current fact advisors see, or a review-queue item for a person
No judgment, only rules: fill an empty slot with a corroborated fact; add agreeing evidence up to Corroborated; never change a published value before its re-check; after it, replace only with something at least as well supported; Certified and Verified change only by a person. Old versions are kept in history, never deleted. The minimum label the machine may publish is one setting, Corroborated today.
Casa Azul Beach Resort
Property site, plainly stated, model sure: Certified, published. Advisors see "Daybeds on the beach: 200, high season, hotel guests, certified by the property, confirmed 2026-09-10." Three months later a travel site says 150; because the fact is Certified, a person reads the side-by-side and declines it in two minutes. The 200 stands.
7. Watch and learnObservability
Inevery model call, every published fact, every staff check
Doesrecords what the models saw, produced, and cost; turns staff checks into accuracy numbers
Outthe dials we turn: which kinds of source to trust, where to demand more certainty
When a fact is wrong we can open the exact page and instructions the model had. Staff spot checks roll up into accuracy by kind of fact and kind of source; each kind's credibility rises or falls on its record, and judged examples become the test every change to a model must pass before it ships. Nothing retrains a model.
Casa Azul Beach Resort
A staff member checks the daybed fact against the stored page and marks it correct. Property-website reads gain a little credibility, and this page joins the test set.
2Where we look, and the guardrails
A short list of kinds of source, maintained by people, and eight rules that make it safe to let machines do the volume.
Approved kinds of source
The business's own website. The property speaking; can Certify. Most of the research happens here.
The property directly. Email, call, or form, relayed by our team.
Google business listings. Hours, address, phone, website, read on first add and on rhythm.
Named travel sites we have reviewed, one entry each, terms of service noted.
Recognized awarding bodies, a short guarded list: the Michelin Guide's own list certifies a Michelin star, the only third-party route to Certified.
Advisor feedback and staff checks. People, attributable.
Never read
Reddit, forums, and social posts
Review aggregators
Booking sites and online travel agencies, whose terms forbid it
Anything not on the list. An unknown site lands in a low-trust "other web" bucket that can never certify or corroborate; a person decides whether it deserves an entry.
Code drives, models readA model never decides where to crawl. It is handed the text of approved pages and nothing else.
Receipts or nothingEvery candidate carries the page, the sentence, and the time. No page, no fact.
Corroborated floorOne source is never enough to publish. Two independent kinds, or a person, or the property.
Humans own the topCertified and Verified facts change only by a person with a recorded reason.
No answer engines as evidenceTools that blend many pages hide which page said what. They may help find pages; they never produce facts.
No model memoryThe model is never asked what it knows about a resort. Only what the page in front of it says.
One read per page setEvery fact in one pass, never one question per fact. Thirty questions would cost thirty times as much.
Receipts stay insideAdvisors, reports, and partners see a fact's value, conditions, label, and date. Nothing else.
3What it costs
Flat subscriptions for the fetching service, the job runner, and observability, about $100 to $160 a month between them, plus AI usage billed by the text the models read and write. The unit of AI work is a pass: one business read to full depth. Today's list prices; the shape will not move.
Kind of pass
What it reads
Facts out
AI usage
Beach resort, full depth
About 12 pages: every beach fact type plus on-site dining and service. The reasoning model on about one pass in five.
about 100
2.5¢, or 1.2¢ overnight
Restaurant, full depth
About 6 pages.
about 40
1.2¢, or 0.6¢ overnight
Essentials business
Pharmacy, hospital, transfer operator: 2 or 3 pages, mostly the Google listing.
about 15
0.5¢
Per fact, any kind
about 1/40 of a cent
Milestones, and what each costs
Milestone
Earned when
Businesses
AI to build, once
AI ongoing
Proof of concept
Every beach resort in one continent at full depth. Nothing is live.
about 1,500
about $40
about $7 a month
Launch
The remaining continents; all resorts and the four- and five-star hotels advisors book; a light layer of medical and emergency essentials, possibly Michelin-listed dining. Going live is what finishing this earns.
about 30,000
about $450
about $75 a month
Scale
Begins at launch, lasts years: more kinds of business and more regions, each at full depth.
to 100,000
to $1,500 over years
to $250 a month
Enterprise
Brand and host-agency partnerships feeding facts directly instead of being read from the web.
100,000 and up
partly replaced by partner feeds
depends on partners
Ongoing research is the re-check rhythm running forever, about twice the build cost per year, spread evenly. Overnight pricing halves AI usage and should be on from day one, since nothing here is time-sensitive.
The real budget line is the review queue. At one pass in five needing a look, the proof of concept creates a few hundred review items and launch several thousand, and the deep facts are the ones most likely to need one. That is people's time, not model usage, and it is the reason the rules exist.
4Still to decide
The full beach-resort fact list, with conditions and re-check rhythms, written against the real data. Depth is decided here.
Which continent the proof of concept covers, and exactly which kinds of lodging and business are in launch versus scale.
The initial list of approved source kinds, with the terms-of-service note for each named travel site.
How sure the reading model must be before a plainly stated value on a property's own site certifies without a person looking.
Confirming the cheap model reads real pages accurately before relying on it; the fallback is the same vendor's mid-tier model at roughly ten times the reading cost, still small.
How regional events reach the queue: a monitored news source, a manual trigger, or both.
For the technical reader: names and choices behind this page
Fetching service
Firecrawl: map, search, scrape to markdown, PDF parsing, content fingerprint. Whitelist enforced before every call.
Cheap AI model
GPT-5.6 Luna, structured output, fact-type definitions in a cached prefix, batch API. Fallback GPT-5.6 Terra.
Reasoning AI model
GPT-5.6 Terra. Single vendor for simplicity; Sonnet 5 is the first alternative to test if reconciliation quality lags.
Places data
Google Places API, read on first run and on its re-check rhythm; results stored as facts and identity fields (Place ID as an external identifier for dedup). Never called at read time.
Job runner
Trigger.dev or Inngest: cadences, fan-out, retries, concurrency caps, resume-from-step.
Observability
Langfuse: traces with cost, scores from staff checks, datasets and evals.
Approved source types
The Source bank: generic types with allowed/ToS status and earned credibility; the URL on each evidence record carries the page.
Candidate facts, receipts, labels
Claims with status candidate; Evidence records owned by the claim; trust tier computed from evidence. Full model in erd.html; plain-language companion in model-explainer.html.