How guest data stays separated
One guest asks for the Wi-Fi password. Another asks for the same Wi-Fi password without ever having set foot in that apartment. What separates them is not a rule in the prompt.
The first architectural decision in this project was made in week two and still carries everything: there are two knowledge areas, not one. Public Saas-Fee knowledge — restaurants, lifts, weather, events, the pharmacy, getting here — sits in a corpus anyone may query. Everything belonging to a particular apartment or hotel sits in a second corpus that is not read at all without valid guest access.
The distinction sounds obvious until you build the alternative. A single corpus with a prompt rule saying "only give property data to authorised guests" moves access control into a language model. That is not access control; it is a request.
What makes a guest a guest
Access arrives two ways: through a personal guest link issued by the property, or through a session verified by a one-time code over SMS. Both end in tokens, and tokens here follow one rule with no exception: only the SHA-256 hash is stored, never the value. Reading the database does not let you sign in.
- One-time SMS code: valid for 10 minutes
- Guest session: 90 days
- Guest access to a property: up to 12 months after the stay
- Conversations and reservations: up to 24 months
Those periods are not only written here. They are in the internal GDPR processing register, alongside every service that sees data and what it sees it for. A guest can ask for a copy or a deletion at any time; there is a page for it and an address that exists for that purpose.
What arrives from outside counts for nothing
Twilio, Meta and apaleo call our endpoints. Every one of those calls is checked against its signature and journalled — but the more interesting rule is the second one: a webhook's payload is not used as a source of data. When apaleo says a booking changed, we re-read that booking from the API by its id. Forging the message forges no booking.
The emergency path
When Lena recognises a medical emergency, the reply comes from fixed text: the ambulance number first, then what to tell the dispatcher, then Rega for anywhere a vehicle cannot reach. No model writes that answer, and none of the ten reply backstops that rewrite every other answer touch it. A model having a bad day does not belong between a guest and an ambulance number.
What is written here was measured. What is missing gets named.
And something is missing. There is no error tracker in operation, and nothing probes the emergency path from outside. Today we learn about a breakage when a guest tells us. Those are the next two steps, in that order, and the order has a reason: making a breakage visible is the precondition for being able to verify anything after it.