AI operations

22 conversations handled in 7 days

Watching Every new message in the support inbox and every email to the guest address, on every channel, in any language. within a minute

When

• a guest asks a question, reports a problem or makes a request
• a guest gives an email address or a phone number their reservation lacks (Airbnb guests reach us through a relay address until they do)
• a message arrives that is spam, marketing or an automated notice
• a message tries to instruct or probe the system

Then, in order

1. 1resolve the stay first where the message is tied to a booking, so who they are and which Podtel they are in is known before the reply is written
2. 2screen the message for injection and impersonation
3. 3identify the guest and the stay from the booking system
4. 4look the answer up in the knowledge store and past cases
5. 5reply in the guest's language with what is verified
6. 6create a task for staff when something physical is needed
7. 7hand over to our Humans with a summary when it cannot be solved

Brings in Management, by assignment in the support inbox, with a note of what was tried.

Watching Every message that is not a person expecting an answer: newsletters, campaigns, promotions and spam. within a minute, on the same sweep as the guest inbox

When

• a newsletter or a campaign arrives
• spam arrives
• an automated notice, receipt or bounce arrives

Then, in order

1. 1recognise it by rule, not by judgement, before anything is sent to the model
2. 2on marketing and on spam, unsubscribe for real: the List-Unsubscribe header first, with the one-click POST where the sender offers it, then the opt-out link in the body, trying each until one is accepted
3. 3leave transactional mail alone, because a receipt or a security alert has to keep arriving
4. 4write the outcome on the conversation and record it, with no link in the event because an opt-out link identifies a person
5. 5tag with the reason and close it, no reply sent

Brings in Nothing to escalate: a dismissal is reversible by reopening the conversation. Outright phishing is stopped earlier, by the security screen, and is never fetched.

3 channel messages from guests in 7 days, 3 answered by Grímnir, 0 by a person

Watching Every message thread in the booking system: Airbnb, Booking.com and direct bookings all arrive there. within two minutes, at once on the booking system's webhook

When

• a guest writes in their booking thread
• a guest gives an email address or a phone number the reservation lacks
• a channel sends a notice that can only be answered in its extranet
• a person replies in the mirrored support conversation

Then, in order

1. 1screen the message, then resolve the stay before reading it: first name, Podtel, site, dates and party come off the booking, so the reply never asks the guest something our own records answer
2. 2mirror the thread into the support inbox on a contact with no email address, so nothing is ever mailed to an alias
3. 3answer through the booking system so the reply lands inside the channel the guest used
4. 4carry a reply typed by a person in the support inbox out the same way, after the same outbound screen
5. 5raise extranet-only notices to our Humans
6. 6never answer anything written before the connector started

Brings in Management by email for notices; the support inbox mirror for hand-over with a summary.

14 aurora windows and 24 weather windows found in 30 days, 28 announced to guests

Watching The sun's activity (NOAA planetary K index, observed and forecast), cloud cover over the site (Open-Meteo) and the hours of real darkness. hourly

When

• a dark hour tonight has Kp at or above 3 with the sky mostly clear
• the outlook improves to likely or strong

Then, in order

1. 1read the K index forecast and the hourly cloud, wind and precipitation
2. 2compute the sun's altitude for every hour: dark means below minus 12 degrees
3. 3find tonight's window: dark, Kp 3 or more, cloud 60 percent or less
4. 4from early afternoon, tell every guest in house once, through Intercom, by email to the address on the booking, and in their Airbnb, Booking.com or direct booking thread through Smoobu, with the window, how to look and a plain caveat
5. 5write again only if the outlook improves
6. 6show the outlook on the Tonight page and the public feed

Brings in Management by email with the same text; the tool guests.notify_stay carries the dial.

14 aurora windows and 24 weather windows found in 30 days, 28 announced to guests

Watching Hourly rain, snow, wind and gusts for the site, today and tomorrow, and the Met Office's official warnings once the feed is wired. hourly

When

• heavy rain (4 mm an hour or more)
• heavy snow (1.5 cm an hour or more)
• blizzard conditions (snow with wind of 13 m/s or more)
• storm-force wind (gusts of 25 m/s or more)
• freezing rain

Then, in order

1. 1find the window and grade it: possible, likely, strong
2. 2tell guests in house and arriving today, once per event, with the window, the advice to keep doors closed and stay in, and the time to be back by, two hours before it starts
3. 3note that roads can close and where to check
4. 4upgrade the notice only if the grade rises
5. 5show it on the Tonight page

Brings in Management by email; strong events as a warning.

31 upcoming events from 12 sources

Watching The event pages and feeds of every town, venue and festival within two hours' drive of Grundarfjörður. daily

When

• a source lists a new event within sixty days
• a source fails or runs dry three days in a row

Then, in order

1. 1fetch each source: feeds parsed directly, pages read as text and rendered with Chromium when needed
2. 2a small model extracts title, time, place, town, link and a one-line description
3. 3keep events within two hours' drive; drop the past; mark what a source no longer lists
4. 4publish on the Events page, the Tonight page and a JSON feed for the brand website
5. 5a failing source goes to the mechanic, who checks whether the site moved or changed

Brings in Management by email when a source keeps failing; sources are managed on the Events page.

14 sessions by 3 participants, 19% of offered circuits done

Watching Every session a guest runs in the retreat app: which route, each step done or skipped, how long, the daily prompt, how each step and the day felt. live

When

• a guest signs in with their name and Podtel, or their booking email
• a guest chooses a research consent tier on the first morning (default none; changeable under Research)
• a guest starts, pauses, skips, abandons or completes a step
• the sleep sensor under the mattress reports (planned; no wrist band or ring, Priyesh 14 October 2026)

Then, in order

1. 1identify the stay from the booking, then keep only a salted pseudonym; below the questionnaires tier not even that
2. 2tier 2 and above: the daily prompt (present, rested, connected, 0 to 10), a measurement moment on first and last mornings, per-step feedback 0 to 10, the closing feedback (the day, three words, would repeat)
3. 3tier 0 and 1: no questions asked, steps kept without identifier; tier 0 never enters the research
4. 4walk the guest through the route with a timer, instructions, the dose and a safety line
5. 5scrub words of contact details; changing to No moves everything recorded to a new random code, deleting nothing
6. 6show the tally here and publish aggregates on the Research Labs above a minimum group of five
7. 7ask the same nine feeling scales on arrival and on departure, with three words; the next card carries them four and twelve weeks after the stay
8. 8guests on one booking are told apart by device: the first device to sign in is Guest 1, the next Guest 2 (shown in the header), each with its own pseudonym and consent; sign-in by name and Podtel, booking e-mail or booking reference (Airbnb code, Booking.com number, Smoobu id), kept for twelve months unless they sign out

Brings in None; the guest can message from the app at any time.

Watching The page each StarHive tablet shows all day (retreat/cabin.php?id=1 to 5, locked in kiosk mode): the stay, the controls, tonight's sky, the Podtel and site readings, the way to the programme and the app. the page refreshes itself every ten minutes

When

• a stay checks in to the Podtel (the name and dates appear from the booking)
• a guest touches a control: a light scene, the warmth, the speaker (two soundscapes, low or medium only), the door (open or lock, through property.door_lock, L0 until raised)
• a guest opens the Wellness tab: a stress meter from their own check-in answers and session ratings, the stations done and how often; or the Biosphere tab: the latest sightings and the lagoon sound
• a guest presses the call button and speaks to Grímnir (the ElevenLabs line, origin tablet)
• the sky watch or a Podtel reading changes

Then, in order

1. 1built: the page, keyed to the Podtel so nobody else can open it, with the stay from the booking, the sky watch charts, the station readings and the wellness stations' state, the QR codes to the retreat app and the Districthive app
2. 2built: a control posts to the page, which runs the property tool as the kiosk (property.set_scene, set_temperature, set_volume, play_audio) and tells the guest plainly what happened, including when the Podtel is not connected yet or our Humans must confirm
3. 3planned: the tablets themselves (Samsung Tab S10+, Fully Kiosk as device owner, chosen 14 October 2026); the server dims and wakes the screen over Fully's local interface at dusk and at night
4. 4planned: the door state on the page from the Podtel's lock once the StarHives have one

Brings in None: a control that cannot run says so on the screen and points to Grímnir in the app.

14 sessions by 3 participants, 19% of offered circuits done

Watching Each station's own instruments: temperature, humidity, the last presence detected; beside the app's own timers, which already give hours used and the share of all activity per station. when a feed lands

When

• a station instrument reports a reading (no feed is connected yet)
• a guest marks a step done in the app (live now: hours and share per station)

Then, in order

1. 1a feed writes rows to station_readings (cabin, station kind, temperature, humidity, presence time, source)
2. 2the Wellness tab shows the latest reading per station beside the app's hours, share and last use
3. 3later: presence against the app's timers to check that steps were done where they say

Brings in None yet.

0 arrival, 0 departure, 0 four-weeks and 0 twelve-weeks questionnaires; 0 of 0 follow-up e-mails sent

Watching The same nine feeling scales answered on arrival, on departure, four weeks after the stay and again at twelve, plus what lasted; one follow-up e-mail per wave per stay. hourly

When

• a guest at the questionnaires tier or above opens the app on the first morning or on the day of departure
• a stay that answered on arrival or on departure ended four weeks ago, and again twelve weeks ago
• a guest opens the private link in a follow-up e-mail

Then, in order

1. 1ask the nine scales and three words in the app on arrival and on departure; below the questionnaires tier nothing is asked and nothing is kept
2. 2every hour the followups connector matches ended stays to the research by pseudonym and queues one e-mail per wave (four weeks and twelve weeks after checkout), never a repeat
3. 3guests.send_followup sends it through Intercom, or the Smoobu thread when the booking has no address; the tool starts at L0, so each e-mail waits for one tap on Approvals
4. 4each private link works for sixty days and asks the same nine scales, plus how present the stay still is, how long the feeling lasted and whether they would come back
5. 5the guest sees their own stay summary in the app: arrival, routes practised, departure, four and twelve weeks on
6. 6show the averages per moment, the change per item and the paired mean change on this dashboard, and on the Research Labs above a minimum group of five
7. 7changing to No moves the answers and words to a new random code and stops the e-mails; words are kept under the pseudonym for staff and the research, never published

Brings in None; a follow-up with no reachable address is recorded as no contact.

0 emergencies in 30 days, 0 not yet acknowledged

Watching The red Emergency button at the bottom of every page of the retreat app, for a signed-in guest. live

When

• a guest describes an emergency and presses Send to our team

Then, in order

1. 1tell the guest to call 112 first if someone is hurt or in danger
2. 2keep the message in guest_emergencies, never in the event chain
3. 3raise a critical alert: the Attention list and home page of this dashboard, e-mail and SMS to staff, the SMS never held back by the hourly limit
4. 4Grímnir phones Priyesh first (see Grímnir phones the board): while that call is out his SMS waits, and it goes with a second e-mail if the call does not reach him; a second emergency within the hour texts him at once
5. 5text and e-mail Host / Emergencies (People page, Responsible now) straight away, not waiting on Intercom; Management too when the message reads as a site-wide incident (fire, flood, eruption, police, someone unconscious or missing)
6. 6open an Intercom conversation as the guest, tagged escalated and emergency, assigned to a person; Grímnir never answers it
7. 7not acknowledged within 30 minutes: sent again by text and e-mail, every 30 minutes, six times at most (the watchdog, every minute)
8. 8staff verify in person, then Acknowledge and clear, which records who dealt with it

Brings in Always: it goes straight to people. If Intercom is down the alert still goes by text, e-mail and the dashboard.

11 calls in 7 days

Watching Voice calls to Grímnir on the web and, once wired, the hotel number. live

When

• a caller asks about a stay, a door, availability or how things work
• a caller is locked out
• a caller asks for a person or money is involved

Then, in order

1. 1disclose that it is the AI and record consent
2. 2identify the caller from the booking email
3. 3answer from the knowledge store and live data
4. 4check the door before saying anything about a lock
5. 5create a task for the on-site team
6. 6hand over to our Humans with a callback route and a summary

Brings in Management by email, and by SMS when the caller says now.

0 of 3 upcoming arrivals have the app

Watching Every upcoming arrival: app installed, invitation sent, details confirmed, check-in pending. hourly

When

• a guest arriving within a day has not installed the app
• a guest has not confirmed their details
• a guest asks how to get in

Then, in order

1. 1email the guest with the app link and the steps
2. 2message through the booking channel (Airbnb, Booking.com)
3. 3send an SMS
4. 4send a WhatsApp
5. 5call the guest with Grímnir's voice the morning of arrival
6. 6tell the on-site team who is still unprepared

Brings in On-site team through a dashboard task; Management in the digest.

1 arrivals checked ahead, 1 with something missing; 0 stays had tasks raised in 30 days

Watching Every arrival of tomorrow (and a late booking for today): the Podtel's status in the host dashboard, the open tasks on it, the heating and the sauna switch in the device registry, the lock's battery in the Nuki mirror, whether a welcome message went, and the guest's preferences when they agreed to be remembered. hourly from 10:00 local the day before, with the guest care rounds; on a call or the Guest care page at any time

When

• the Podtel is marked pending cleaning, or a departure comes first (turnover)
• the heating reads off or the room under 18 C
• the sauna switch is offline
• the lock battery is low or the lock offline
• nothing has gone to the guest from us yet

Then, in order

1. 1read what the platform holds and say ok, missing or unknown per item; unknown means the device is not commissioned yet, never ok
2. 2store the findings on the stay (stay_care) so the briefing says what is missing without reading it again
3. 3raise one host dashboard task per missing item for housekeeping, maintenance or front of house, through people.create_task as the same caller, never twice (guests.pre_arrival_tasks)
4. 4tell the identified team member on their call: the Podtel, the guest's first name, what is missing, the preferences; offer to raise the tasks
5. 5not yet: guests.pre_arrival_tasks is at L0, so the rounds hold the tasks and the stay_care row says so; a team member raises them by voice or on the Guest care page meanwhile; the heating and sauna items read unknown until the devices are commissioned

Brings in Housekeeping and maintenance by task; Management sees the arrivals not ready in the briefing and on the Guest care page.

0 second-morning questions sent in 30 days, 0 answered

Watching Every stay of two nights or more on its second morning, and what the guest answers. hourly between 09:00 and 13:00 local, with the guest care rounds; in the room, when the guest speaks to Grímnir

When

• the second morning of a stay comes and nobody has asked
• the guest answers by message, in the room or on a call
• the answer is unhappy

Then, in order

1. 1one short message from Grímnir through the path the stay already has: the booking's channel thread (Smoobu), else Intercom, never both (guests.in_stay_check, as the AI so its dial decides)
2. 2in a Podtel, stay_check_answer tells Grímnir whether the question is due and the words; he asks once, gently, and records the answer
3. 3the answer is recorded with its mood (given, or read from the words), once per stay; an unhappy one opens a complaint due the same day with the channel it came in on (guests.stay_check_answer)
4. 4not yet: both tools are at L0, so no message goes and nothing is recorded from the room until the dial is raised; the rounds mark the stay held and the Guest care page lets a person send or record by hand

Brings in An unhappy answer is a complaint (the next card); nothing else to escalate.

0 guests said yes, 0 no, 0 asked and not answered; 0 preferences kept

Watching What a guest likes (the milk they take, how warm the Podtel), kept under the same salted key as Grímnir's memory, only after the guest said yes. as it happens; read in the pre-arrival check and the briefing

When

• a guest signs in to the retreat app and has not been asked
• a guest in a Podtel speaks to Grímnir and has not been asked
• a guest who said yes lets a preference slip, or a team member hears one
• a guest says no, or asks to be forgotten

Then, in order

1. 1ask once, in the app (the card on the home page) or by Grímnir in the room (guest_preference gives the words), and record the answer
2. 2keep one line per preference with where it came from; nothing without a yes, and a no erases what was kept
3. 3show first name and preferences to identified team members only: the pre-arrival check and the staff briefing for tomorrow's arrivals
4. 4erase on the Guest care page (Management), with the guest's memory on the Control page, or by the guest in the app
5. 5not yet: guests.preference_note is at L0, so Grímnir asks nothing and records nothing in the room until the dial is raised; the app and the Guest care page work now

Brings in Nothing to escalate: a preference is a courtesy, never a promise.

0 complaints open, 0 past the same-day promise; 0 closed in 30 days, 0 the same day

Watching Every complaint, wherever it came from: a guest message, a call, the room, a team member, a review, an unhappy answer to the in-stay check. as it happens; overdue ones checked hourly with the guest care rounds

When

• a complaint is opened
• its day ends and it is not closed
• it is fixed but the guest has not been told

Then, in order

1. 1open it with the summary, the Podtel and the stay, the department read from the words, due by the end of the same local day, owned by the one member of that department on today's rota when there is one (guests.complaint_open; make_task also raises a host dashboard task)
2. 2record progress: a note, an owner, the fix, the guest told and how (guests.complaint_update); closed only when both halves are done
3. 3overdue: a warning alert per complaint, cleared when it closes; the staff briefing leads with it; the business brief and the board report carry the counts
4. 4the words stay in the erasable complaints table; events carry the id and what changed
5. 5not yet: both write tools are at L0, so Grímnir cannot log or update a complaint by voice or from chat until the dial is raised (he hands the complaint to our Humans instead); the Guest care page works now

Brings in The owner and their department by alert and briefing; Management for one that is overdue or unowned.

0 drafts waiting, 0 approved to post, 0 posted

Watching Every marketplace review without a host reply (reviews_cache, from the listings connector), inside the last 90 days. hourly with the guest care rounds, a few per pass; from the Reviews page at any time

When

• a new review arrives without a host reply
• Management approves, edits, declines or marks a reply posted

Then, in order

1. 1one model call per review drafts a short, warm reply in Grímnir's voice: thank by first name, pick up one thing they wrote, own a problem plainly without promising money, invite them back, in the review's language, no em dashes (guests.review_reply_draft)
2. 2hold the draft on the Reviews page for Management: approve as is or edited, decline, and once it is on the marketplace, mark it posted
3. 3posting is by hand: Airbnb and Booking.com give this platform no API for host replies, and Smoobu carries none; the page says so and offers the text to copy
4. 4the model's cost is on the event; the counts are in the business brief and the board report
5. 5not yet: the tool is at L0, so the rounds draft nothing until the dial is raised; Management asks for drafts from the Reviews page meanwhile (a person's click, not the dial)

Brings in Management on the Reviews page; a low review still raises its alert as before.

0 offers sent in 30 days, 0 followed by a booking

Watching Every StarHive arrival of tomorrow, and the Wellness Station bookings that follow. hourly from 10:00 local the day before, with the pre-arrival round

When

• a guest arrives in a StarHive tomorrow and has not had the offer
• a slot is booked for that stay afterwards

Then, in order

1. 1one message: the Wellness Station in a sentence (one visit of about forty minutes), the Human Recharging Program and Designed By You, and the booking link into the retreat app, where the station is booked for their Podtel (guests.wellness_offer, as the AI so its dial decides)
2. 2through the booking's channel thread (Smoobu) or Intercom, once per stay; refused for a Podtel at a site without the station
3. 3mark the offer booked when a Wellness Station booking appears for the stay; the counts are in the brief and the board report
4. 4not yet: the tool is at L0, so no offer goes until the dial is raised; the stay_care row says held and the Guest care page lets a person send it by hand

Brings in Nothing to escalate: an offer is an offer.

Watching Heating, water, power and internet state per Podtel; what guests report. hourly

When

• a guest reports cold, no water, no power, no internet
• a Podtel's hub goes offline

Then, in order

1. 1confirm the Podtel state from the hub and sensors
2. 2walk the guest through the fix from the knowledge store
3. 3raise an urgent maintenance task
4. 4follow up with the guest once the task closes

Brings in On-site team by task; Management if unresolved within the hour.

8.76 of 10 over 142 reviews

Watching Ratings and every remark on Airbnb and Booking.com; chat ratings guests leave. daily

When

• a new remark scores 3 of 5 or 6 of 10 or lower
• the combined rating drifts down over a month
• a remark names a fixable problem

Then, in order

1. 1read the remark and find the stay it refers to
2. 2raise an alert with the remark and the listing
3. 3draft a host reply for Management to post (since 19-10-2026: the review replies card)
4. 4turn a fixable complaint into a task for staff
5. 5track the rating by month on Performance

Brings in Management by email on every low remark.

Watching The conversations on the Podtel tablet and the Wellness Station screen, now run by our own client (assets/grimnir.js) instead of the plain widget, the room's presence sensor (StarHive plug-in sensor, st06-presence), the ElevenLabs post-call webhook, and the guest's memory choice in the app (Priyesh, 17-10-2026). presence every twenty seconds from the client; summaries as the webhook lands, else fetched once after five minutes

When

• a conversation starts on the tablet (a tap) or at the station (presence wakes the screen)
• the room has been clear for five minutes (GRIMNIR_PRESENCE_CLEAR_S), or, with no working sensor, nobody has spoken for thirty (GRIMNIR_NO_SENSOR_IDLE_S)
• the line is cut at the two hour cap or drops while presence holds
• a conversation ends and its summary arrives
• staff erase a guest

Then, in order

1. 1the rooms have their own ElevenLabs agent (agent_9201...), an exact copy of the main one written from the same source by bin/setup-voice-agent.php: no hang-up on silence (-1) and two hours (7200 s) there, while the dashboard and public widget keep 600 s and a 120 s silence hang-up
2. 2the client ends the conversation only when the room has been clear for the set minutes; a tap or a word counts as presence, so a slow sensor never cuts a live talk
3. 3at the cap or a dropped line with presence still on, a new conversation starts at once with continuing yes and the last lines said (carry), so there is no felt reset
4. 4each conversation gets a random memory_ref (voice_sessions) passed as a dynamic variable; the post-call webhook brings it back with the summary, stored in voice_memories against a salted hash of the guest from the reservation, never a name or an email
5. 5the next conversation gets returning and memory (a short rolling summary, capped), and the prompt tells Grímnir to greet a returning guest naturally and never recite private details unprompted
6. 6every guest is remembered across stays, with no opt-in: booking or using the hotel is consent under our terms (Priyesh, 17-10-2026); staff erase a guest on the Control page
7. 7events carry the session ref, the conversation id and the Podtel only
8. 8guide the guest's programme (Priyesh 17-10-2026): the room conversation starts with programme, done, current and next_options (ProgrammeState, found by the Podtel), the client sends a contextual update when a step changes, and the read-only room tool get_programme_state reads it again; in Designed By You Grímnir offers two or three next steps that suit the moment
9. 9keep the app in step by voice (Priyesh 17-10-2026): in a room Grímnir records how a step felt (guests.step_answer, only what the guest said), marks it done (guests.step_complete) and starts the chosen or next step (guests.step_choose), at L3 with his authorisation logged (migration 065), through the same code as the app buttons (WellnessFlow); the app step page and the tablet poll the session signature and refresh in place; the Before and After surveys stay in the app

Brings in Nothing to escalate: a conversation that cannot start says so on the screen; the tablet falls back to the ElevenLabs widget if our client cannot load.

Watching Every speaker zone: its level, its mute, whether it is playing and what it is playing. every poll

When

• a guest is granted a station for a slot
• a session ends
• an aurora window opens and the site turns itself down
• a zone stops answering

Then, in order

1. 1find the players on the network by multicast, once, at commissioning
2. 2a person names each one after its Podtel in the Sonos app, and the zone is matched to it
3. 3from then on the platform sets the level and chooses the track over plain HTTP on port 1400
4. 4the audio is ours and lives on this server, served as an endless stream so a zone can never reach the end of a queue and fall silent mid session
5. 5read the state back every poll so the dashboard knows what is actually playing rather than what was commanded

Brings in A zone that stops answering raises its fail count and shows on the property page; nothing retries blindly.

14 aurora windows and 24 weather windows found in 30 days, 28 announced to guests

Watching The aurora windows the sky watch opens, dusk and dawn, the sky brightness meter, and the lighting level of every path zone and of every occupied Podtel. hourly

When

• an aurora window is running, not merely forecast
• the window has passed, or vanished from the forecast, and levels are still held down
• dusk, dawn, or a change in the sky brightness reading (planned: the fourteen path zones)

Then, in order

1. 1planned, as Priyesh set it on 13 October 2026: no sensors on the paths; the fourteen Skydance zone dimmers in the technical cabin are the whole control of the path lighting, and the server sets each zone from dusk and dawn, the Unihedron sky brightness meter and the aurora forecast, the paths at a low night level and lower still while the aurora shows
2. 2while the window runs, drop the path zones to 20 percent
3. 3drop any occupied Podtel whose lights are on to 30 percent, leave a Podtel that is already off alone, leave one already dimmer alone
4. 4record the level found on every target before changing it, which is what makes the whole thing reversible
5. 5tell the guest in the same notice that carries the forecast, with how to put it back
6. 6if a guest moves their own light afterwards, mark that Podtel overridden and never touch it again this window, including at restore
7. 7when the window closes, put every level back exactly where it was found
8. 8show the state on both dashboards, and on the public one as information

Brings in If the tool cannot run, an info alert says so and nothing is dimmed; the forecast notice still goes out without the paragraph about lighting.

1 of 1 locks healthy

Watching Every smart lock: state, battery, bridge online, stay codes, movements. 5 minutes

When

• a lock reports a blocked motor, uncalibrated or offline
• a battery is critical
• a stay code is live while the lock is unhealthy
• a guest cannot get in

Then, in order

1. 1raise a lock fault alert, critical when a guest is due
2. 2refuse to promise a guest the door works until it clears
3. 3raise an urgent task for someone on site
4. 4issue or revoke stay codes when asked, never speaking a code aloud

Brings in Management by email and SMS while a stay code is live.

Watching The occupancy radar and the door lock in all fourteen station cabins, on the Tuya gateway. on every change, and a full sweep every minute

When

• a guest presses Next in the wellness programme
• the radar sees somebody in a cabin
• a cabin has been clear for an hour
• a lock reports a low battery

Then, in order

1. 1hold every door locked by default, so nobody walks in on a guest in a robe
2. 2unlock the cabin the programme has just given a guest
3. 3unlock while the radar sees anybody inside, and relock an hour after it goes clear
4. 4show occupied and free per cabin on the dashboard, from the radar rather than from the schedule
5. 5raise a task when a lock battery falls low, before it strands anyone

Brings in Management, for a lock that will not answer or a cabin that reads occupied long past any booking.

0 of 13 power groups on, 0 with a device

Watching The stays in house from the booking mirror (the Smoobu import), against every power group that is on: each StarHive's sauna and jacuzzi, the station sockets, the heavy machines. 10 minutes, with the sweeper

When

• no StarHive has a guest in house and anything is on
• a StarHive has no guest in house and its own sauna or jacuzzi is on

Then, in order

1. 1read the stays in house: checked in by date, not checked out, not cancelled, a stay of more than sixty days counted as a calendar block and not a guest
2. 2with nobody in house, propose every group that is on for switching off; with a StarHive empty, its own sauna and jacuzzi
3. 3at L0, record the proposal once per group per time it was on (power log, an event, the Power panel on the Property page) and switch nothing
4. 4at L1 or L2, put one approval in the queue per set of groups, not one per run
5. 5at L3 or L4, switch them off, checking the bookings again first so a guest who has just arrived keeps their heat

Brings in Management decides when the dial goes up; until then staff switch off by hand from the proposal on the Property page.

0 requests today

Watching The SAUNA, JACUZZI and WELLNESS STATION buttons on the StarHive tablet and at the top of the retreat app. on every press

When

• a guest presses SAUNA or JACUZZI: their own StarHive's
• a guest presses WELLNESS STATION: the Wellness Station groups

Then, in order

1. 1log the request per group with the time, the source, the StarHive, the stay as its salted hash only, and the wait the guest is told
2. 2switch on what is off through property.power_switch, as the guest's own action, like the tablet's light and door buttons
3. 3keep the on time of a group that was already on, so the guest sees what is left of the warm-up somebody else started
4. 4show a gauge that fills from red through orange and yellow to green over the warm-up (an hour for saunas and jacuzzis; the Wellness Station and its cold-air unit are ready at once, Priyesh 17-10-2026), and Ready in green
5. 5on WELLNESS STATION, show Ready as soon as the Wellness Station is on, with its therapy pills green and any therapy whose device is offline grey; all three open 24 hours
6. 6switch everything off by itself four hours after it came on (auto_off_min per group, 0 for never, set in the staff editor), checked every minute by the pollers and logged as auto_off; a press on something already on keeps it on for four hours from that press, logged as extended
7. 7once ready, show when it goes off: on until 18:30 on the tile and on the station pill, and Keeps it on until 18:30 after a press
8. 8the jacuzzi's switch is its heating and jets control only, never its supply, which stays on for the frost protection
9. 9every screen reads the same stored on time and polls for changes every thirty seconds

Brings in A switch that fails is logged and the guest is told it did not go through; the tool error lands with the mechanic.

Watching Presses of SAUNA, JACUZZI or WELLNESS STATION in the retreat app by a guest who has not arrived yet, and the starts they schedule. every minute, with the pollers

When

• a guest presses before arrival
• the same guest presses again before the start
• the start time comes: an hour before the booking's check-in, its own time or the dashboard's 15:00, Reykjavik

Then, in order

1. 1schedule the switch-on for an hour before arrival and show Starts at HH:MM on DATE, ready for your arrival on the tile, the gauge idle
2. 2a second press cancels it
3. 3at the start time switch it on through property.power_switch, logged with the source pre_arrival
4. 4leave those groups out of the no-guests rule until an hour after the arrival they were for
5. 5mark a start missed by more than two hours past the arrival as failed rather than heat an empty room

Brings in A start that fails shows on the Power panel; the guest can press again on arrival.

Watching A guest in a StarHive starting a wellness programme in the retreat app. on every start

When

• a guest starts the Human Recharging Program or Designed By You

Then, in order

1. 1switch on every shared station group and the guest's own sauna and jacuzzi, logged with the source programme
2. 2on the first step, say which stations are on now and which need time to heat up or cool down (sauna, jacuzzi, the cold-air unit of the Wellness Station), each with its own ring and the minutes left
3. 3leave an admin preview session alone: a test switches nothing

Brings in Nothing to escalate: a group that does not come on shows as off on every screen and on the Power panel.

168 devices in the registry, 0 commissioned, the rest in the simulator

Watching The device registry: every Tuya device of the site from the construction data (screen panel hubs and gateways, the light, infrared and devices relays, dimmers, locks, cameras, air conditioners, sensors, plugs, the sauna and jacuzzi switches, the Wellness Station screen relay, its player and Sonos speakers (read only), the path spot light zones, the welcome lettering, the post box door phone), with its Tuya id and its connection. on every press; state read every three minutes

When

• staff press a control on the Control page: on, off, dim, colour and white (colour panels, none in Phase 1), set temperature, lock, unlock (Nuki Web API for every door; was F2 Tuya Wi-Fi handle locks on the stations, Nuki on the StarHives), camera privacy
• staff press a master control: all lights off, all infrared off, all stations devices on or off, lock or unlock all StarHives or all station doors, cameras privacy or wake, site lights on, off or dimmed, everything safe for the night, all off in one area
• staff commission a device: its Tuya id, data points and thresholds

Then, in order

1. 1bulk actions confirm in the page first, naming how many devices each step touches; locks confirm twice and the server refuses a lock without the second confirmation
2. 2every press runs property.device_switch or property.device_lock through the tool registry as the staff member's own action, one event per call, with the dry run asked for on the page
3. 3split each action into the simulated devices (they change in the simulator) and the commissioned ones (which obey APP_DRY_RUN)
4. 4send a sauna, jacuzzi, cold-air unit, dehumidifier or station devices command through property.power_switch, so the power group's warm-up, auto-off and log stay the truth
5. 5leave a StarHive with a guest in house out of All lights off, and a station with someone inside out of the night action
6. 6record commissioning as property.device_config; the Tuya keys stay in .env and are never shown
7. 7export the commissioning sheet as CSV, import it filled in with php bin/devices.php import

Brings in A command that fails says so on the page and in the event; a device that stops answering is the next card.

0 devices offline now

Watching Every enabled device in the registry: online as the Tuya cloud reports it for the commissioned ones, the simulator for the rest, and whether it could be read at all. three minutes (connector tuya_devices, with the pollers)

When

• a device is offline or unreadable for more than ten minutes
• a hub (screen panel or gateway) goes offline with devices behind it
• the cloud itself cannot be read

Then, in order

1. 1store online, last seen and the values on every pass
2. 2start the ten minutes at the first read that found it offline, so a blip never alerts
3. 3raise one alert per device, or one for a hub naming the devices offline behind it
4. 4clear the alert by itself when the device answers again
5. 5when no commissioned device can be read, leave their state alone and let the connector's health go red instead of raising an alert per device

Brings in A warning to staff by email from production; dev and simulated devices record the alert on the Attention page and send nothing.

0 sensor alerts open

Watching The leak sensors (02 AI Brain by the UPS and by the water cabinet in its water room, 03 Storage by the washer dryers), the smoke and CO detectors in every shell and StarHive, the room temperatures (frost sensors, the Wellness Station humidity probe, the five sauna probes, the StarHive plug-in sensors, the air conditioners). three minutes

When

• a leak sensor reports water
• a smoke or CO detector is in alarm
• a room is under its frost threshold (5 C by default, set per device)
• a room is over its overheat threshold (40 C rooms, 110 C sauna probes, 35 C in the StarHives and by the air conditioners)

Then, in order

1. 1raise water and smoke as critical, frost and overheat as warnings, one alert per device and condition
2. 2say what to do first in the alert: shut the water off, check the cabin and call 112, check the heating
3. 3clear by itself when the reading is back inside the threshold (half a degree of margin)
4. 4keep a reading every ten minutes for the 24 hour line on the Control page

Brings in Critical alerts by SMS and email from production; warnings by email. The detectors sound on their own: this is the remote notice, not the fire alarm.

0 on locally now, 0 held by the frost rule; 0 auto-offs and 0 frost switch-ons in 24 hours

Watching The presence detector, the room temperature sensor (the SOAN probe; in 01, the Wellness Station, the humidity and temperature sensor) and the infrared relay K2 of every station cabin. every minute, with the pollers, on readings under ten minutes old

When

• nobody has been inside a station for ten minutes
• a station's room reads under its frost rule threshold (5 C, per room sensor)
• it is back to its release threshold (10 C)
• the hub switched the held infrared off

Then, in order

1. 1the ten minute no-presence off of the lights relay K3 and the infrared K2 is the cabin panel hub's own rule, set at commissioning, so it runs with the uplink down; the platform does not run it
2. 2under 5 C switch every infrared relay K2 of that cabin on (and a frost heater, flagged frost_heater, when one is fitted, for example in 04 Waste shelter) through property.device_switch as the system, source frost, and hold it on: past the hub's ten minute off and past the four hour local auto-off
3. 3tell staff once, an info alert, when frost protection engages in a cabin; it clears when the rule lets go
4. 4the hub's own ten minute rule can still switch K2 off locally while the platform holds it, so every pass checks K2's last reading and switches it back on when it reads off (a dry-run or refused attempt waits five minutes); at commissioning add the condition temperature above 5 C to the hub's ten minute off rule for the infrared, if the panel supports it, and the two stop fighting
5. 5at 10 C let go: switch K2 off when nobody is inside, or leave it on with the local auto-off counting from then when someone is
6. 6a sensor that stops reporting keeps the hold, the safe side; 04 Waste shelter and the water room of 02 AI Brain have no infrared, so until a frost heater is fitted the frost alert above is all they get
7. 7thresholds per room sensor (frost rule on and off on the Control page editor, or php bin/devices.php config --frost-on --frost-off); every switch is an event and a line in device_log

Brings in The info alert when it engages, and the frost warning above if the room keeps falling.

0 air conditioners heating now; 0 hold switches in 24 hours

Watching The room temperature of every cabin with an air conditioner (Priyesh 20-10-2026): 01 Wellness Station, both rooms of 02 AI Brain, 03 Storage, 05 Visitor toilet (04 Waste shelter has none) and the five StarHives; each JP Dolphin 25 with its room sensor, the unit's own reading when the sensor has nothing fresh. every minute, with the pollers, on readings under ten minutes old

When

• an empty cabin reads under 10 C (nobody inside, and no guest in house for a StarHive)
• it is back to 12 C
• a held unit reads off
• a held room still falls under 8 C

Then, in order

1. 1switch the air conditioner's heat on through property.device_switch as the system, source ac_hold: set_temperature, mode hot, at 18 C, the lowest the unit takes, so the platform and not the unit ends the run
2. 2mark it held (frost_hold_ts, on_source ac_hold) and keep it on until the room reads 12 C; then switch it off when nobody is inside, or leave it as it is when someone is
3. 3a held unit that reads off is put back on (a dry-run or refused attempt waits five minutes); if someone inside switched it off, the hold lets go: theirs to decide
4. 4occupied rooms are left to the people in them: the guest's or staff's own setting rules; the infrared frost rule still steps in under 5 C where a cabin has a panel, and the infrared panels stay for comfort
5. 5a sensor that stops reporting keeps the hold, the safe side; every switch is an event and a line in device_log (hold_on, hold_off); thresholds in .env (AC_HOLD_ON_BELOW_C, AC_HOLD_OFF_AT_C, AC_HOLD_SETPOINT_C, AC_HOLD_ALERT_BELOW_C)

Brings in One warning to staff (device_ac_hold) when a held room still falls under 8 C: the unit not keeping up or not answering; it clears at 10 C or when the hold lets go.

not held off; 0 rule lines in 24 hours

Watching The mist pump's Zigbee plug (Phase 1: in the water room of 02 AI Brain), the outdoor temperature (the weather station when there is one; none yet, so the sky watch forecast, sky_hourly), the forecast wind, the water room probe and the guests in house. every minute, with the pollers, on readings under ten minutes old

When

• outdoors under 4 C: the weather station, else the lowest forecast temperature of this hour and the next three
• the forecast goes under 2 C in the next six hours
• the forecast wind is over 5 m/s (the highest of this hour and the next three)
• the water room probe reads under 2 C (the backstop)
• no guest is in house
• no outdoor temperature is known at all (held off, the safe side)

Then, in order

1. 1switch the plug off through property.device_switch as the system, source frost_mist, and hold it off (devices.rule_block_ts, with the reason in words on the Control page)
2. 2while held, refuse a staff switch-on with the reason, and switch the plug off again if it reads on (a dry-run or refused attempt waits five minutes)
3. 3let go only when every reason has gone: outdoors above 6 C (the hysteresis), the six hour low at 2 C or more, wind at 4 m/s or less, the probe at 3 C or more, a guest in house
4. 4at release switch it back on only if it was on when the rule took it off and staff did not switch it off since; otherwise it stays off for staff to switch on the Control page (the schedule is theirs)
5. 5every hold, release and switch is a line in device_log (source frost_mist) and an event; thresholds in .env (MIST_OFF_BELOW_C, MIST_ON_ABOVE_C, MIST_FORECAST6_BELOW_C, MIST_WIND_ABOVE_MS, MIST_WIND_RELEASE_MS, MIST_PROBE_BELOW_C, MIST_PROBE_RELEASE_C)

Brings in Nothing to escalate: a switch that fails is in device_log and the event, and the frost alert of the room probe still warns staff if the cabin itself gets cold.

0 panel colours sent from the app in 24 hours

Watching Phase 2 only (Priyesh, 17-10-2026): the Coloured light step of a guest's programme and RGB+CCT colour panels. Phase 1 has no colour panels: the screen of the Wellness Station gives the colour light, guided by Grímnir (the card Grímnir guides the Wellness Station), so the app no longer sends colours and the endpoint finds no panel to drive. The code below is kept for Phase 2. on every tap

When

• a guest whose session is at the Coloured light step taps blue, green, yellow or red, or Panels off
• an admin preview taps one

Then, in order

1. 1refuse the tap unless the guest's own session is at the light step (or it is an admin preview)
2. 2send the colour (Tuya colour_data_v2, h, s, v; work_mode colour) or off to both panels through property.device_switch as the system, source guest_app, like the power buttons
3. 3start the colour's three minute count in the app at once, as before, and say whether the panels changed
4. 4log one device_log line per panel (source guest_app) and the event; no personal data, the actor is the app
5. 5count the tap as activity in the cabin: the panels go off by themselves two hours after the last activity, never while someone is inside
6. 6staff set any colour, white level and colour temperature on the Control page

Brings in A tap that does not reach the panels says so to the guest; the failure is in the event and the error log.

Watching Booking presses in the retreat app and on the Podtel tablet for the one Wellness Station (Priyesh, 17-10-2026), and the device registry for the therapies it shows. on every press; the block refreshes every thirty seconds

When

• a guest presses Book the Wellness Station: now when it is free, else the next free start, or a later start they choose (one slot type: the full visit, 45 min)
• a guest cancels their slot
• staff cancel or book for a Podtel on the Control page
• a device a therapy needs is reported offline

Then, in order

1. 1allocate the station to one Podtel at a time: one active or upcoming booking per Podtel, no overlaps, checked under a lock so two presses cannot take the same time
2. 2open 24 hours, no last booking time, up to 24 hours ahead
3. 3show every guest the taken slots of the next hours without the Podtel or any name, their own marked as yours
4. 4show staff the Podtel and the source, with Cancel
5. 5record each booking and cancel as an event (property.wellness_book, property.wellness_cancel) with the booking id and the Podtel only, the stay as a hash
6. 6show one pill per therapy under the WELLNESS STATION tile under the heading Therapies in the Wellness Station (salt and breath, aroma, sound, Light Therapy, salt glow, Cold Glacial Breeze, infrared warmth, Grímnir AI, meditation): green almost at once when the station is on, no warm-up, and grey offline when one of its devices is reported offline by the device monitor (the simulator on dev)
7. 7hold the allocation as data for the Grímnir session: WellnessSession::sessionAllowed() is true only for the holder of the booking on now

Brings in Nothing to escalate: a press that fails says so to the guest; staff can cancel or book on the Control page.

Watching Presence waking the free Wellness Station with no booking holder (station_free yes). when it happens

When

• a guest comes into the free station and chooses their wellness programme

Then, in order

1. 1Grímnir greets and asks: start your wellness programme, or just talk
2. 2for the programme it asks which StarHive they are in (or already knows them), then calls book_wellness_station
3. 3the voice tool runs property.wellness_book at L3 (Priyesh 17-10-2026, migration 063, in tool_autonomy_log): it books at once, no tap needed, under the same rules (free now, inside the stay, ending two hours before checkout, one per Podtel); a refusal is told in one sentence with the tablet or app as the way to book
4. 4just talk books nothing

Brings in Nothing to escalate: a refused booking is told to the guest; staff see every booking on the Control page.

Watching The Wellness Station (01): its presence detector, the guest's programme step in the retreat app, the Sonos speakers with their built-in microphone, the screen and its player, and every therapy device on its own switched way (Priyesh, 17-10-2026). The session is defined as data in src/Property/WellnessSession.php; nothing runs it yet. while someone is inside

When

• presence is detected in 01 during a booking: Grímnir wakes on the screen and greets the holder (WellnessSession::sessionAllowed, from the booking on now); without a booking it only greets
• a guest whose programme is at a Wellness Station step comes in, or presses Start on that step
• a step's minutes are up, or the guest says next or taps Done
• the guest says stop, taps Stop, or leaves
• staff press Stop, or the emergency control in the station is used

Then, in order

1. 1the voice loop: Grímnir speaks through the Sonos speakers, the guest can talk back in the room, Grímnir listens through the speakers' microphone and replies; the screen shows Grímnir as an abstract form that reacts in colour while it speaks and while it listens
2. 2step the circuit as WellnessSession::steps() defines it: salt and breath, aroma, sound, meditation with Grímnir AI, Light Therapy on the screen (blue, green, yellow, red, two minutes each), the Cold Glacial Breeze and the Sound of Silence; 38 minutes inside in one visit before the sauna
3. 3at each step switch only what the step names (the infrared panel, the aroma plug, the cold-air plug, the room light level, the screen colour, the soundscape) through property.device_switch and property.power_switch, each a tool call with its event, dry run and an L0 dial to start
4. 4on stop, on leaving or on staff Stop switch off everything the session switched on; on the emergency control every therapy device off, lights full, staff alerted
5. 5mark the app step done with its minutes, so the research log and the device log agree

Brings in A device that does not answer ends that step and tells the guest in words; staff see it on the Control page. The emergency control alerts staff at once.

0 on locally now, 0 held by the frost rule; 0 auto-offs and 0 frost switch-ons in 24 hours

Watching Every light relay, dimmer, infrared relay, devices contactor, plug, sauna, jacuzzi relay, the Wellness Station screen relay, path light and the welcome lettering, as the Tuya cloud reports it, and the presence detectors and key presses of each cabin. state every three minutes; the rule every minute

When

• the monitor sees a device on that the platform did not switch on: a wall key, the panel hub's presence rule, the device itself
• its off time comes: for the lights of a station or any other non-StarHive cabin (K3, work lights, dimmers) two hours after the last activity in the cabin (the last presence detection, key press or switch change seen there); for StarHive lights and everything else four hours after it came on

Then, in order

1. 1record when it came on (up to three minutes late, the monitor's pace) and when it goes off; show on since and off at (and last activity for cabin lights) on the Control page, with an on now line per area
2. 2switch it off through property.device_switch as the system, source auto_off_local, logged in device_log; like the power auto-off it acts at once: it only switches off what is on, and the wall key puts it back
3. 3not while the presence detector of its area sees someone, or a guest is in house for a StarHive light: checked again every minute and off at the first pass with nobody there
4. 4never what the frost rule holds; never the dehumidifiers or the mist pump (auto-off 0); a device switched from the Control page has no local auto-off, and one on a power group switched by the platform keeps the group's own
5. 5a device on a power group that is on locally while its group is off is switched off at the device itself, so the off is not lost on a group already off
6. 6a dry run or a refused switch tries again fifteen minutes later; auto-off minutes per device in the Control page editor (0 for never)

Brings in Nothing to escalate: a switch that fails is in device_log and the event, and the device stays on until the next try.

Watching Hub heartbeat, climate, water tank and pump, solar and battery, incinerating toilet, lockers, sensors. minutes

When

• a hub stops reporting
• temperature or humidity leaves the comfort band
• water is low, battery is low, a device fails

Then, in order

1. 1confirm from a second signal before acting
2. 2correct what can be corrected remotely (scene, temperature)
3. 3raise a maintenance task with the reading attached
4. 4warn the guest in the Podtel in plain words if it affects them
5. 5flag the instrument as unhealthy on the monitor page

Brings in On-site team by task; Management when a Podtel is unsellable.

Watching Forecast and warnings for each site: wind, snow, ice, heat, flood. hourly

When

• a storm or gale is forecast within 24 hours
• ice, heavy snow or extreme heat is due
• a road or trail is closed

Then, in order

1. 1tell staff to secure loose items, close shutters and doors, check water and power
2. 2tell guests in house what to expect and what not to do (no hikes, stay in, keep the pool covered)
3. 3tell arriving guests about the road and timing
4. 4reschedule cleaning and deliveries around the weather
5. 5check in with every Podtel after it passes

Brings in Management by SMS for a red warning.

9 tasks open for staff

Watching Podtels waiting for cleaning, departures today, arrivals today, open tasks. hourly

When

• a Podtel is still pending cleaning with an arrival due
• a checked-in guest sits in a Podtel marked available
• a task is open past its day

Then, in order

1. 1raise a state mismatch exception
2. 2remind the on-site team with the arrival time
3. 3push the task until it closes
4. 4confirm the Podtel is ready before the guest is told the door code

Brings in On-site team by task; Management if a guest arrives to an unready Podtel.

Watching Every reported fault, every open maintenance task and its age. hourly

When

• a guest or a monitor reports a fault
• a maintenance task is open for more than two days
• the same fault comes back

Then, in order

1. 1open a task with what, where and how urgent
2. 2chase it daily until it closes
3. 3ask the guest afterwards whether it is fixed
4. 4raise a purchase order for a part when one is needed
5. 5record repeat faults so the cause gets fixed, not the symptom

Brings in Management in the weekly digest, at once for anything safety related.

Watching Locker stock, consumables, linen, cleaning supplies, spare parts. daily

When

• a locker product runs out
• a consumable falls below its reorder level
• a delivery is late

Then, in order

1. 1raise a purchase order with the supplier and quantities
2. 2ask Management to approve
3. 3mark it ordered and received, linked to its invoice
4. 4tell the on-site team what to restock where

Brings in Management on the Orders page, reminded after three days.

17 register items: 0 overdue, 0 due in 30 days, 17 without a date yet; 0 done marks in 30 days

Watching Every item of the safety and compliance register: fire extinguishers and blankets, the detectors' yearly check, emergency lights, the fire authority's inspection, exit signs, first aid kits and the lagoon rescue box, first aid training, the food hygiene registration and record, the accommodation licence, insurance, the electrical and lift certificates, legionella; each with its holder or place, last done, due, renewal and evidence. hourly with the operations rounds; read in the briefing, the board report and on the Safety page

When

• an item is 30 days from its due date
• an item is overdue
• a team member says a check, an inspection or a renewal is done (safety_done) or marks it on the Safety page
• Management sets a first due date on an item seeded without one

Then, in order

1. 1keep one line per item (safety_items) with the evidence noted; every done mark is a log line with who and the day (safety_log), and the due date moves on by the renewal
2. 2warn once 30 days before a due date (safety_due) and once when it is overdue (safety_overdue), cleared when the item is marked done; a new date re-arms the warnings
3. 3the staff briefing says what is overdue or due in 30 days for the member's department; the board report carries the counts
4. 4Grímnir reads the register by voice (safety_due) and records a done mark with the evidence (safety_done), asking for the evidence when none was given
5. 5not yet: every item was seeded without a date, so nothing is due until Management sets the dates on the Safety page, and the register says so rather than guess; compliance.safety_done is at L0, so done marks by voice wait for the dial; the page works now

Brings in The department by the warning and the briefing; Management for an overdue item and for every item without a date.

0 times the rules were read in 30 days; 0 pre-work checklist runs, 0 signed off

Watching Every mention of ground work on the site by the team or a contractor, on any line: digging, trenches, foundations, ground screws, soil or spoil storage, machinery, a new structure; and the "Before ground work" checklist. as it is said; the list whenever a dig is planned

When

• ground work comes up in a call or a briefing
• a dig, a trench or a soil store is planned
• something is found while digging

Then, in order

1. 1say the rules unprompted before anything else about the works (heritage_rules): the farm mounds 302:1 at the centre of the ring and the Bakki ruin 329:1 to the south-west, each with a 15 m zone where nothing is dug, stored or parked without Minjastofnun Íslands' written say (Act 80/2012); a find stops the work; the Snæfellsnes UNESCO Biosphere Reserve rules (nothing on open ground, no new track or structure outside the approved plan, the shore and the stream untouched, the nesting season)
2. 2say where the "Before ground work" list stands and walk a team member through it (checklist_next and checklist_tick): the zones pegged against the 2016 report's coordinates, the permit where a zone is touched, the spoil place, the contractor briefed, the stop-on-find rule, the Biosphere items, the machine route; Management signs it off
3. 3the maintenance briefing carries the standing reminder and the list's state
4. 4the facts live in one place (Property\Heritage) and are never a permit: the words say who must be asked

Brings in Management signs the pre-work list off; Minjastofnun Íslands for anything in a zone or found in the ground; the municipality for anything outside the approved plan.

0 turnover checks open, 0 waiting to be passed; 0 passed in 30 days; 0 photos kept

Watching Every departure done (checked out in the host dashboard, or its checkout time passed): the check of the Podtel that follows, item by item (bed, bathroom, kitchen, floor, sauna, jacuzzi, welcome), the photos, and whether Management has passed it. checks opened hourly with the operations rounds; the ticks as they happen on the Turnover page or on a call

When

• a departure is done and the next guest is coming
• the housekeeper finds an item not ok
• every item is ok and the check waits for Management
• Management passes it, or sends it back
• the next arrival is due and the check is not passed

Then, in order

1. 1the rounds open one check per departure with the checkout time and the next arrival; a check can also be opened by hand for a Podtel
2. 2the housekeeper ticks each item ok or not ok from their phone with a photo (downscaled, kept in an erasable table, never in events), or tells Grímnir (property.turnover_check); every item ok makes the check "checked"
3. 3Management reviews the items and photos and passes the check (the Podtel is ready from then) or sends it back with what to put right
4. 4the pre-arrival check reads it: a Podtel whose turnover check is not passed is not ready, and the task says so; the briefing names the open turnovers with their clock
5. 5photos are erased after 90 days by the rounds, or by Management on the page
6. 6not yet: property.turnover_check is at L0, so Grímnir cannot record a tick or a pass by voice until the dial is raised; the page works now

Brings in Housekeeping by briefing and the pre-arrival task; Management to pass each check.

the OCPP server is up, 0 chargers connected; 0 of 2 chargers online, 0 commissioned; 0 charging now; 0 sessions and 0 kWh in 30 days; tariff to confirm

Watching The two 22 kW OCPP 1.6 chargers in the car park (Shenzhen Gangchuang, MID meter; Priyesh 19-10-2026): their connection to the OCPP server, every status they report, every session from the scan to the capture, the commands sent to them, and the tariff per kWh. live over the chargers' WebSocket; the rounds every minute; the OCPP server heartbeats every 30 seconds

When

• a guest scans the sign and presses Start (ev-charge.php)
• the card is held at Stripe Checkout and the guest comes back to the page
• the charger reports StartTransaction, meter values and StopTransaction
• a paid session is not plugged in within 20 minutes, or charges past 12 hours
• a charger reports a fault, or a commissioned one goes silent for 15 minutes
• a capture is refused by Stripe

Then, in order

1. 1the guest's page shows the tariff and holds the session cap (cap times price) on their card through Stripe Checkout with manual capture; nothing is captured yet
2. 2back on the page the platform reads the Checkout Session, marks the session authorised and sends RemoteStartTransaction with the session token as the idTag; the guest plugs in
3. 3the charger meters the energy (Energy.Active.Import.Register every minute); the page shows kWh, kW and the cost so far, with a Stop button; the guest can also just unplug
4. 4at StopTransaction the kWh delivered times the tariff is captured on the card (below Stripe's minimum the hold is released and the session is free); Stripe emails the receipt; the session and the money are events
5. 5a hold nobody plugs in against is released after 20 minutes; a refused capture raises a warning for Management to settle in Stripe; a faulted or silent charger raises a warning; Grímnir stops, releases, unlocks or resets a charger by voice (property.ev_control, L0) and reads the state (ev_status)
6. 6not yet: the chargers are not bought or wired, so both are simulated (bin/ev-simulate.php plays one) and no card is ever touched; the price is to confirm until Management enters the energy cost per kWh on the EV page (Priyesh's rule of 19-10-2026, migration 087: the price is the cost times 2.0, every customer pays it, guests included, and the receipt says "x kWh at y ISK"), and no paid session starts before that; the wss endpoint needs Apache's proxy and proxy_wstunnel modules enabled once (docs/EV-CHARGING.md)

Brings in Management by the warnings (ev_faulted, ev_offline, ev_billing_failed) and on the EV page; nothing to escalate for a guest, who sees the state on their own page.

today: open 0 of 10 ticked; close 0 of 10 ticked; 30 days: 0 of 8 daily runs complete, 6 missed

Watching The winterisation list once a season and the storm preparation list before every storm: the storm-force and official warning windows the sky watch finds in sky_events, each run's ticks, and the sign-off. hourly with the operations rounds; the walk-through on a call or the Checklists page

When

• a storm-force or officially warned window is within 36 hours
• the first frost is coming and the season's winterisation has not run
• every item of a run is ticked
• a storm window passes with items unticked, or the forecast is withdrawn

Then, in order

1. 1the rounds open the storm preparation run once per window, with the headline and the window start as its deadline, and raise a warning for maintenance (storm_prep); the briefing leads with it and Grímnir walks it first (checklist_next)
2. 2maintenance or Management starts the winterisation run by hand (checklist_tick start, or the page); every department ticks its own lines
3. 3each tick carries who, when, the state and a note; a problem found is offered as a task
4. 4when every item is ticked Management signs the run off (checklist_tick sign_off, or the page): who and when stay on the run, and the maintenance calendar's Winterisation or Storm check item is marked done with it
5. 5a window that passes with items unticked is marked missed and kept; a withdrawn forecast with nothing ticked removes the run and clears the alert
6. 6not yet: people.checklist_tick is at L0, so the ticks and the sign-off by voice wait for the dial; the page works now

Brings in Maintenance by alert and briefing when a window opens; Management for the sign-off.

0 sightings logged, 0 baseline species seen again

Watching Sightings of birds, fish, plants and other life on the point and the lagoon, against the 108 species the 2021 baseline surveys recorded. as logged; the Research Labs page reads the register every five minutes

When

• Management or the on-site team logs a sighting on the dashboard
• the thermal and wildlife scanner or an acoustic monitor reports a species (planned, once installed)

Then, in order

1. 1record species, date, count, place, the observer's role and a confidence, never a name; guest reports are not logged because they cannot be checked
2. 2match it to the baseline list, or mark it as a species new to this place
3. 3publish the register as a public feed with nothing personal in it
4. 4show on the Research Labs Species page the surveyors' own count days against each species' expected period, and which baseline species the register has confirmed since
5. 5later: detections from the scanner and the acoustic monitors land in the same register as a running tally

Brings in None; a sighting can be withdrawn on the Sightings page and stays in the record.

58.3% of the next 30 nights booked

Watching Occupancy since the first booking, the next thirty nights, bookings by source and by month, cancellations, lead time. hourly

When

• the next thirty nights fall well below the same period last year
• bookings drop from a channel
• a rate looks too cheap for the season
• cancellations rise

Then, in order

1. 1show the trend on Performance and Research
2. 2tell Management what moved and where
3. 3propose a rate or a channel change for approval
4. 4check the listings are live and correctly described

Brings in Management in the weekly digest; sooner for a sharp drop.

note of 2026-10-19 sent: Next 8 weeks: 0 up, 6 hold, 2 down; this week 43% booked.

Watching The next eight weeks: nights booked of the nights for sale, bookings made in the last seven days for each week, the booked rate Smoobu recorded, the same week a year ago, events nearby (events_cache), the aurora season from the sky watch's dark hours, the sky outlook. on request; the note every Monday from 08:00 local with the guest care rounds

When

• Management asks about rates, pricing or demand ahead
• Monday comes

Then, in order

1. 1a direction per week with its reason: up when the week is nearly full or filling, or a festival is nearby; down when a near week is nearly empty (a short-notice offer on the direct channel rather than a channel discount) or far below last year; hold otherwise, and hold with a warning when strong weather is forecast
2. 2say what is not tracked: the rate card and the channel rates live in Smoobu and are not mirrored; competitor rates are not read
3. 3write the Monday note once (rate_notes), email it to the board address, show it on the Rates page; the board report carries its headline
4. 4never change a price: nothing here writes to Smoobu or a channel

Brings in Management decides on the rate card in Smoobu; the note is a suggestion.

1 moments drafted ahead, 0 planned, 0 posted

Watching Aurora nights (likely or strong) and strong weather from the sky watch, the research station's records (a species new to the point, a baseline species seen again), first guests (the first stay ever in a Podtel, the first of a season), milestones (stays, nights, the review score) and festivals nearby. daily with the guest care rounds; the Moments page at any time

When

• the sky watch opens an aurora or a storm window
• a sighting is logged for the first time
• a Podtel's first guests or a season's first guests are booked
• a milestone is passed
• a festival within two hours' drive is listed

Then, in order

1. 1make a draft per moment with a suggested post in the brand voice and the picture to take, keyed to what made it so a refresh never doubles one
2. 2Management plans, posts (where) or drops each on the Moments page, edits the words, adds a moment by hand
3. 3the weekly board report lists next week's; Management hears the calendar by voice (moments_ahead)
4. 4nothing is posted by the platform: no social account is connected, and none will post without a person

Brings in Management on the Moments page.

0 card disputes open

Watching Card payments, refunds, disputes, deposits, channel payouts as the booking system records them, invoices, expenses. 15 minutes

When

• a card dispute opens
• a payment succeeds for a booking the dashboard does not hold
• a refund is asked for
• a deposit is still held after checkout

Then, in order

1. 1raise a critical alert for a dispute with its deadline
2. 2raise a reconciliation exception for orphan money
3. 3refund only from the right payment, within what is left, with approval
4. 4release a held deposit
5. 5hand a guest their own invoice link on request

Brings in Management by SMS for disputes, by approval for refunds.

Watching Revenue by source against expenses by category, margin, cost per available night. hourly, close on the first of the month

When

• a month ends
• expenses run past revenue
• a category jumps

Then, in order

1. 1write the close pack and email it to Management, since migration 083 with the month against its budget
2. 2show margin and run rate on Performance
3. 3flag the categories that moved
4. 4keep the registers an accountant or insurer would ask for

Brings in Management by email on the first of the month.

no budget set for this month (0 months with one)

Watching The month to date (revenue by check-in day as Smoobu records it, costs from the expenses tracker by category, occupied nights over the nights available) against the month's budget pro rata: the days elapsed over the days of the month. on every read of the finance brief, the board report and the Finance page; the daily close note when run

When

• Management sets or changes a budget line (revenue, costs by category or as a whole, target occupancy) for a month
• a cost category runs more than ten percent over its budget to date
• no budget is set for the month

Then, in order

1. 1keep one row per month and line (budgets), set on the Finance page, copied forward with one click
2. 2compare the month to date with the budget pro rata and say it in one line: ahead or behind on revenue, over or under on costs, occupancy against the target, the categories over
3. 3the finance brief's against_budget line, the board report's finance section, the Finance page's table and the close pack's section all read the same figures
4. 4when no budget is set for the month, say so plainly and measure nothing against nothing; the daily close (bin/ai-close.php --daily) prints or emails the same line
5. 5not yet: no budget has been entered, so every line says no budget is set; no timer runs the daily close note (Priyesh adds it when he wants the morning email)

Brings in Management on the Finance page; the board in the weekly report.

25 items waiting for a person

Watching Tasks in the host dashboard, approvals waiting, orders waiting, who is away. continuous

When

• something needs hands on site
• an action needs a person's approval
• an approval waits past its expiry

Then, in order

1. 1create the task where staff already look
2. 2ask for approval with the rationale, once a day by SMS unless critical
3. 3expire and re-ask when nobody answered
4. 4summarise the week every Monday

Brings in Management by email and SMS.

1 active members: 1 Admin, 0 Management, 0 Staff

Watching Every dashboard sign-in and every action a page can take. every request

When

• someone signs in to the dashboard
• a page action, a tool run or an approval is asked for
• a team member is deactivated or changes level

Then, in order

1. 1the dashboard root account is always Admin; an active team member on the Team page gets their own level; a host with no team row keeps working as Management; a deactivated member is refused
2. 2one map in src/Web/Access.php says the lowest level for every action: Admin for the team, the autonomy dial, connectors and device commissioning; Management for approvals, orders, knowledge, listings, the site plan and money and compliance tools; Staff for doors, lights, power, Wellness Station bookings, alerts, sightings and guest tools
3. 3every level sees every page; a refused action answers 403 and names the level it needs
4. 4the session reads the member live, so a deactivation ends it at the next page

Brings in Nobody: a refusal is the answer. Changes to the team are events on the Team page.

1 with a second check, 1 with voice samples, 0 locked; 3 identifications in 30 days

Watching Every call, web call, room conversation and chat in which someone says they are on the team or asks for something only the team would. live

When

• a team member calls from their mobile
• a team member presses the call button on a signed-in dashboard page
• someone on the public line, the website chat or Intercom says they are on the team
• an identified member asks for a door, power or a task
• the second check is answered wrongly three times in a row

Then, in order

1. 1one identification path for every channel (People\TeamIdentity): the channel passes only what the line reports, the caller number (ElevenLabs system__caller_id) or a signed dashboard token, never what was said
2. 2a name or an email is only a claim; one factor (the number, the dashboard token, a voice score, a passed second check) identifies, and allows routine requests at their level
3. 3sensitive requests (an unlock, a switch-off) need two factors: with the number alone Grímnir asks the second check, two PIN digits at positions the tool picks, or the date of birth; neither is ever stored, spoken back or written into an event or a payload
4. 4three wrong answers lock the member's check until an Admin unlocks it, with an alert and an event carrying the member id only
5. 5identified requests run through people.team_request, which calls property.device_lock or property.power_switch as that member, with their dry run and event
6. 6create_task works for a confirmed member as it does for a guest with a booking
7. 7not yet: voice recognition. The samples are recorded with consent on the Team page and kept encrypted, but no speaker model runs: this server has no torch, torchaudio or ffmpeg, and ElevenLabs does not give a webhook the live call audio. Options: SpeechBrain ECAPA-TDNN self-hosted (about 2 GB of Python packages and a small local service, free, CPU is enough), Picovoice Eagle (on-device SDK, commercial licence), or routing the phone line through Twilio media streams so the call audio reaches this server; Azure Speaker Recognition is retired
8. 8not yet: people.team_request is at L0, so Grímnir says what he would do and does nothing until the dial is raised
9. 9chat: the security screen still quarantines a message that claims to be staff, so on the website chat and Intercom a team request goes to a person until the screen is told about the team tools

Brings in Management by email when a second check locks; anything refused is handed to our Humans as any call would be.

0 briefings and 0 task updates in 7 days; 0 members without a department

Watching Every call or chat from an identified team member: their department's open tasks and their own, arrivals and departures, who is in which Podtel, weather risks, alerts, what is overdue, orders, Wellness Station bookings, birthdays. every team call

When

• an identified team member calls or writes
• a task they own or their department holds is urgent, overdue or open two days without a date
• a storm or snow is forecast for today or tomorrow
• a guest arrives in or leaves the Podtel they are heading to

Then, in order

1. 1identify them (People\TeamIdentity); nobody else hears a guest's name
2. 2open with what matters most to them today (people.staff_briefing): an arrival or departure, an urgent task, a risk with what to do in their department
3. 3go through their tasks one by one: done, or when and by whom, and record each answer (people.task_update: done ticks the task in the host dashboard; the note, the day and the owner are kept with the task, the note never in the record)
4. 4staff work their department's tasks and their own and may take one on; giving someone else's task away or moving it to another department is Management
5. 5hold them to the outcomes: no pending tasks, always stocked, uptime, guests delighted
6. 6not yet: people.task_update is at L0, so Grímnir says what he would record and they tick it in the dashboard until the dial is raised; the voice tools reach ElevenLabs only when bin/setup-voice-agent.php is run
7. 7not yet: stock levels, which the platform does not track; the briefing says so

Brings in Management sees overdue tasks in the briefing and the weekly board report; a refused change is Management's call.

0 skills proposed, 0 accepted, 35 built; 9 asks from the team

Watching Every request from the team that Grímnir has no tool for. every team call

When

• a team member asks for something Grímnir cannot do yet
• the same skill is asked again

Then, in order

1. 1note the skill with what was asked and why it matters (people.propose_skill), counting up a repeat
2. 2list it with the general manager's standing duties still to build on this page, most asked first
3. 3Management accepts, marks built or declines it
4. 4the most asked go into the board report
5. 5not yet: people.propose_skill is at L0, so nothing is noted from a call until the dial is raised

Brings in The board in the weekly report.

0 board reports sent in 30 days

Watching The whole operation in the order of the GM charter: guests, revenue, brand, operations and maintenance, people, finance, safety, and what the board owes. weekly

When

• Monday morning, once switched on

Then, in order

1. 1gather the week from the platform's own figures, aggregates only, no guest names (People\BoardReport)
2. 2say plainly what is not tracked yet
3. 3list the approvals and exceptions waiting and the most asked skills
4. 4email it to the board, Priyesh Patel and Shaina Patel (BOARD_EMAIL_TO)
5. 5not yet: no timer sends it; bin/board-report.php prints it, and --send emails it

Brings in The board.

2 urgent calls in 30 days: 1 reached, 1 not reached (email and SMS sent)

Watching Every critical alert and every guest emergency. Never a warning. Grímnir's number is +44 7414 110690 (UK; Twilio offers no Iceland numbers): calls to it reach him, and he calls Priyesh from it. live, followed up every minute

When

• a critical alert is raised: the dead man's switch, a broken chain, water or smoke, a door lock fault with live codes, a card dispute, a caller who needs our Humans now
• a guest presses Emergency in the app
• a person tests it by hand: php bin/urgent-call.php "problem" --dry-run, then without --dry-run

Then, in order

1. 1call Priyesh first (ALERT_SMS_TO) through ElevenLabs on the main agent, with the problem in one or two sentences, how serious, what is already done and what he needs to decide (origin urgent_call)
2. 2at most one call per alert kind per hour; no quiet hours, urgent means urgent; when no call goes out (the hourly limit, not configured, refused) the SMS goes at once, as before
3. 3the alert's email record goes at once, as for every alert; the SMS to Priyesh waits on the call
4. 4Grímnir says who he is, the problem plainly, what is done and what he needs decided, then confirms and ends; on voicemail he leaves a short message
5. 5reached only when he records on the call that Priyesh heard it (urgent_call_ack); the watchdog reads the Twilio call status each minute
6. 6failed: not placed, busy, no answer, failed or canceled, or the call ended without that confirmation (voicemail, someone else, cut off), or no outcome in 15 minutes: then the email and the SMS go to Priyesh
7. 7each call kept in urgent_calls (erasable); the chain holds the id, the state and a hash, never the words

Brings in Priyesh, by phone first, then email and SMS. The Host and Technical Issues keep their own texts and e-mails as before.

1 meetings in 30 days, 0 action points open, 0 private notes sent

Watching Meetings a board member (an Admin) takes Grímnir into: everything said, the decisions, the action points, and what the board member should know privately. every meeting

When

• an identified Admin says "Grímnir, join this meeting"
• they address him by name or ask for his input
• they say leave this to me
• he hears something sensitive the board member should know
• the meeting closes

Then, in order

1. 1people.meeting_mode start: he answers in a few words and listens; he speaks only when addressed, one or two short sentences, and never contradicts the board member in front of others
2. 2leave this to me: people.meeting_mode silent, not a word until called by name again
3. 3people.diary_write keeps notes, decisions, action points (owner, day) and his private observations; a team member's action point shows in their briefing; one about a StarHive or Podtel can become a host dashboard task
4. 4people.private_note sends a risk, a contradiction, a negotiation point or a number to the board member's own email and mobile instead of saying it; in the room at most "I have sent you a note"
5. 5people.meeting_mode end: the summary in the diary and to them privately
6. 6the Diary page shows it all, to Admin only; the call button there is the meeting line
7. 7limits: the meeting line is the room copy of the agent, 7200 s per call (two hours) and no silence hang-up; a meeting the line cuts carries on when the board member calls again within three hours. The dashboard button elsewhere is the main copy: 600 s and a hang-up after 120 s of silence, so not for meetings. A phone call reaches the main copy unless a number is attached to the room copy in ElevenLabs. ElevenLabs answers every turn it hears unless the agent declines it, so silence rests on the prompt; its skip_turn system tool would make that firmer and is not configured yet. The transcript reaches the archive after the call
8. 8not yet: all three tools are at L0, so nothing is kept or sent until the dial is raised, and the voice tools reach ElevenLabs only when bin/setup-voice-agent.php is run

Brings in Only the board member in the meeting; nobody else hears or sees the diary.

Watching The standing duties of running the hotel from A to Z: guests, revenue and pricing, marketing and brand, operations, maintenance, people, finance, safety and compliance, sustainability, the board. continuous

When

• a duty falls due
• a team member calls
• the week ends

Then, in order

1. 1Grímnir acts as Co-CEO and General Manager, answering only to the board (docs/GM-CHARTER.md, in his prompt)
2. 2raises each duty with the team member it belongs to, and with the board in the weekly report
3. 3every duty not built yet is a proposed skill on this page

Brings in The board.

Watching Bookings and occupancy, revenue this month against last, the review score and the latest reviews, wellness sessions with before and after feelings, connector and device health, open tasks and alerts, the rota, weather risks; with scope all also construction and sourcing, stock and finance. on request, on a call

When

• an identified Management or Admin member asks how the business is doing (business_brief)
• the board takes Grímnir into a meeting and asks for the full update (project_brief: every department in one call)

Then, in order

1. 1read the general health verdict first: needs attention, steady with what to watch, or healthy
2. 2one short sentence per department, numbers rounded as a person says them, nothing else
3. 3the detail of a department only when asked
4. 4say plainly what is not tracked (no budget, no rates); never fill a gap with a guess

Brings in Nothing to escalate: a read. A department that cannot be read says so in its line.

Watching The Phase 1 sourcing sheet (construction/source/sourcing/DH - Sourcing, Iceland.csv, written by build_sourcing.py) and the PDFs under construction/phase-1. on request; the sheet is parsed once per request

When

• an identified Management or Admin member asks about construction, sourcing, orders or the drawings

Then, in order

1. 1count the lines, the PENDING lines with their names, the FINAL lines to order by Priyesh and by Eva, the ordered (EVA, OOD), shipped and local lines
2. 2add up the USD overall, by Who, by status and for the pending lines; say how many lines carry no price
3. 3count the Phase 1 drawings
4. 4headline lines first, the lists only when asked; never write to the sheet

Brings in Nothing to escalate: a read. Delivery dates and payments are not on the sheet, and the brief says so.

Watching Booking revenue by check-in day (Smoobu, EUR), card money by payment day (Stripe), the sales ledger and the expenses tracker (spreadsheets mirrored by their connectors), purchase orders, disputes and held deposits. on request, on a call

When

• an identified Management or Admin member asks about money

Then, in order

1. 1takings today, this week and this month; card money; costs this month against last with the largest categories
2. 2open purchase orders with their amounts, disputes, deposits held
3. 3month to date against the same point last month
4. 4say plainly what is not tracked: there is no budget, the ledgers carry no paid or unpaid state, and nothing here records an expense (listed as a proposed skill: the host dashboard's API has no expense endpoint and both ledgers are spreadsheets)

Brings in Nothing to escalate: a read.

Watching Every consumable on the stock list: its par level, the count on hand, who counted it and when, the supplier and the lead time. on every count; read on request

When

• a team member gives a count on a call ("twelve rolls of kitchen roll left") or on the Stock page
• a count falls below par
• Management sets a par level, a supplier or a lead time

Then, in order

1. 1the list was seeded from the guest consumables of the Phase 1 sourcing sheet; the opening quantities are the first par levels, marked "first guess, to be set" until Management sets them
2. 2record the count with who gave it (stock_counts) and update the item
3. 3say what is below par and what to reorder, from whom and with what lead time; offer a supplies task or an order
4. 4the staff briefing leads its stock section with what is below par and what was never counted

Brings in Management on the Stock page; purchase orders go through the Orders page as before.

Watching Who is on which day, from when to when, covering which department, and what nobody covers. read on request; the briefing says who else is on today

When

• Management adds, changes or cancels a shift (rota_set on a call, or the Rota page)
• a team member asks who is on, or hears their briefing

Then, in order

1. 1Management puts a member on a day with hours and the department they cover
2. 2every member hears who else is on today in their briefing (first names, hours, what they cover)
3. 3the rota says what nobody covers rather than guessing

Brings in Nothing to escalate.

today: open 0 of 10 ticked; close 0 of 10 ticked; 30 days: 0 of 8 daily runs complete, 6 missed

Watching The morning open list (by 10:00 local) and the evening close list (by 23:00): every item, who ticked it and when, the reading an item asks for, and what was found not ok. the day's runs opened hourly from 05:00 local; the walk-through on a call or the Checklists page at any time

When

• a team member opens or closes the day, or asks for the list
• an item is found not ok
• the close list is not complete by its deadline
• a day passes with items unticked

Then, in order

1. 1Management keeps the two lists on the Checklists page: items in order, each for one department or for everyone, some asking for a reading
2. 2Grímnir reads the next unticked item of the member's department (people.checklist_next) and records each answer: done, skipped or not ok, with the answer and a note (people.checklist_tick); the first tick opens the day's run
3. 3a problem found is offered as a task; the briefing says what is still unticked and by when
4. 4a close routine past its deadline raises one warning alert (checklist_overdue), cleared when it completes; runs of past days left open are marked missed and kept as the record
5. 5not yet: people.checklist_tick is at L0, so Grímnir cannot record a tick by voice until the dial is raised; the Checklists page works now

Brings in The department by briefing; Management by the warning on a missed close and on the Monitoring page.

24 suppliers, 0 with a confirmed lead time; 14 stock items linked, 0 not

Watching Every supplier on the list: country, what they supply, the lead time (or that it is still to confirm), the contact's role, the terms; which stock items and orders are theirs. read on request; the reorder advice reads the lead time with every count

When

• a team member asks how long something takes or who supplies it (supplier_lead_time)
• a stock item falls below par: the advice says when an order today would arrive
• Management confirms a lead time, adds a supplier or links an item

Then, in order

1. 1seeded with the stock list's suppliers and the makers that recur in the Phase 1 sourcing sheet (the notes column), the contact's role only, never a name; every lead time "to confirm" until Management sets it
2. 2a stock item takes its supplier's lead time when it has none of its own; Management links items on the Stock or Suppliers page, or by naming the supplier when setting a par level
3. 3the stock status and the count answer say the lead time and the arrival day if ordered today, or that the lead time is to confirm
4. 4purchase orders carry the supplier id when the name matches one, so the Suppliers page shows the open orders from each
5. 5not yet: no lead time is confirmed, so every answer says "to confirm" until Management sets them; late deliveries are chased from the orders (the next card)

Brings in Management on the Suppliers page for the lead times.

0 deliveries logged in 30 days (0 closed an order, 0 not in good condition); 0 expected this week, 0 late

Watching Every delivery: what, from whom, how many, in what condition, who received it; every placed order's expected day against today. as deliveries happen; the late check hourly with the operations rounds

When

• a team member says something arrived (delivery_log) or logs it on the Orders page
• an order is marked ordered: the expected day follows from the supplier's lead time
• an expected day passed two days ago with nothing received
• a delivery is damaged, short or wrong

Then, in order

1. 1record the delivery with the day and who received it; find the order it closes (the one named, or the one open order from that supplier; several need the number) and mark it received, clearing its alerts
2. 2add the quantity to the stock count when the words or the item name match one stock item (never for a wrong item)
3. 3a delivery not in good condition goes on the order's note and is offered as a task or a word to Management
4. 4the briefing says what is late, expected today and this week, placed without a date, and what came today; the rounds raise one warning per late order (delivery_late), cleared on receipt
5. 5not yet: people.delivery_log is at L0, so Grímnir cannot record a delivery by voice until the dial is raised; the Orders page works now, and no supplier lead time is confirmed yet, so expected days are set by hand

Brings in Kitchen and stock by briefing; Management by the late-delivery warning and on the Orders page.

0 expenses of 2026-10 without a receipt or an invoice number (0 EUR), 0 chased; 0 received and 0 waived this month

Watching Every active row of the expenses tracker in the current and the previous month: has it a file link (the receipt) and an invoice number? hourly with the operations rounds; on every read of the Finance page and the briefing

When

• a tracker row of the month has no receipt or no invoice number
• the row is completed on the tracker (the chase resolves itself)
• five days before the month ends, and on its last day

Then, in order

1. 1one chase per row (expense_chases), owned by whoever entered it on the tracker when that name is a team member, else Management; the owner hears their chases in the briefing and may mark them chased
2. 2Management sees the month's list on the Finance page, assigns an owner, waives a chase when nothing is coming, reopens one
3. 3the rounds email Management the open chases five days before the month ends and on its last day, once each (expense_chase_reminders)
4. 4the daily close note, the board report and the close pack carry the same line; the row itself is completed on the tracker, never here
5. 5the chase is the platform's own record: the ledgers stay spreadsheets

Brings in The owner by briefing; Management by the two month-end emails and on the Finance page.

0 entries waiting to be carried into the ledgers; 0 recorded in 30 days, 0 by voice, 0 carried

Watching What a team member tells Grímnir they paid or were invoiced: the amount with its currency, the supplier, what for, the day, who paid, whether a receipt is coming; and what waits to be carried into the ledgers. as it is said; read in the finance brief and on the Finance page

When

• a team member says they paid something or an invoice came (expense_record)
• Management carries an entry into the tracker or the sales ledger and marks it carried
• a receipt arrives for an entry that expected one

Then, in order

1. 1record the entry in the platform's own table (expense_entries) with who recorded it; the ledgers are spreadsheets mirrored here with no write path, so nothing is written there
2. 2say it back and that it is for Management to carry into the ledger; ask them to keep the receipt
3. 3the Finance page lists the entries waiting, exports them as CSV in the tracker's column order, and marks each carried (with the tracker's id) or its receipt received; a carried entry's tracker row then meets the receipt and invoice chase like any other
4. 4the finance brief says how many wait and for how much
5. 5not yet: money.expense_record is at L0, so Grímnir cannot record by voice until the dial is raised; the Finance page records now

Brings in Management on the Finance page.

0 training records, 0 expired, 0 expiring within 60 days; 0 recognition notes in 30 days, 0 ever

Watching Each member's training, courses, certificates and licences with their expiry; every note of good work Management makes. as it is recorded; read in the briefing and the weekly board report

When

• a training record expires within 60 days, or has expired
• Management says a team member did well (team_note) or notes it on the Team page
• the first board report of a month

Then, in order

1. 1keep one row per skill, course, certificate or licence with done and expiry dates, the provider and the evidence (team_training), on the Team page per member; a member always sees their own
2. 2the member hears what of theirs is expiring in their briefing; Management hears everyone's, with the week's recognition
3. 3a recognition note is kept with the day and who made it (team_recognition); the member hears it warmly in their next briefing
4. 4the board report carries the training expiring and the period's notes, and in the first report of each month asks who did well last month, with the tally
5. 5not yet: people.team_note is at L0, so Grímnir cannot note recognition by voice until the dial is raised; the Team page works now, and no training is on record until Management enters it

Brings in Management on the Team page; the board once a month.

0 meter readings in 30 days from the team, 0 of 4 meters ever read; 0 days of plug estimate (simulated until commissioned)

Watching The site electricity and water meters as the team reads them, the waste weighed at each collection, the metering plugs' watt readings the device monitor keeps, and the guest nights from the bookings. readings as they are given; the plug estimate once a day with the operations rounds; the figures read in the briefs and on the Sustainability page

When

• a team member reads a meter to Grímnir (meter_reading) or on the Sustainability page
• a reading comes in lower than the last (refused unless the meter was replaced)
• a day passes with watt readings from the plugs
• Management or the board asks for the per-night figures

Then, in order

1. 1keep every reading with who gave it and when (meter_readings); a cumulative meter's use is the difference between readings, waste is summed per collection
2. 2count guest nights from the bookings: every night of every stay in the period, times the party
3. 3say the figures per guest night over 30 and 7 days, each with where it comes from; with fewer than two readings of a meter there is no figure, and the brief says so
4. 4integrate the metering plugs' watts into a daily kWh estimate for what is plugged into them, labelled simulated until the plugs are commissioned; never presented as the site's use
5. 5the business brief has the sustainability line, the board report its section, the close checklist asks for the readings
6. 6not yet: no site meter is fitted and no plug is commissioned, so only manual readings exist and the plug estimate is simulated; property.meter_reading is at L0, so readings by voice wait for the dial; the page works now

Brings in Nothing to escalate: a figure to improve, and a story to tell once it is real.

0 turnover checks open, 0 waiting to be passed; 0 passed in 30 days; 0 photos kept

Watching Every passed turnover check: the minutes from the departed booking's checkout time to the pass, per Podtel and per housekeeper, this week against the four weeks before. fixed at each pass; read in the briefs, the board report and the briefing

When

• a turnover check is passed
• a turnover runs past the next arrival's check-in time
• Management or the board asks how the day is lost

Then, in order

1. 1the clock starts at the booking's checkout time and stops at the pass of the quality check, so "ready" means checked to the standard, not merely cleaned
2. 2the Turnover page shows the table: per Podtel and per housekeeper, turnovers, the average, the longest, this week
3. 3the business brief carries the housekeeping line (four weeks, this week, checks open); the board report the figures per Podtel and per housekeeper for the period
4. 4the staff briefing names today's turnovers with their clock since checkout and flags one that runs past the next arrival
5. 5not yet: with no departure passed through a check there is no figure, and the brief says so rather than guessing; a check opened by hand without a departure has no clock

Brings in Management when a turnover runs past an arrival; the board in the weekly report.

Watching Every planned item: what, where, every N days, last done, next due, which department owns it; beside it device uptime from the registry and the device and lock alerts of the last 30 days. read on request; the maintenance department hears its due items in the briefing

When

• an item is overdue or due within 14 days
• a team member says an item is done (maintenance_done on a call, or the Maintenance page)
• Management sets a first due date or an interval

Then, in order

1. 1seeded with the obvious items (lock batteries per StarHive, heat pump filters, smoke and CO detector tests, Starlink and router, jacuzzi water tests, sauna stoves, winterisation, storm checks) with no dates: next due is empty until Management sets it, and the tool says so instead of guessing
2. 2marking an item done logs who did it and sets the next due date from the interval
3. 3the brief gives overdue first, then due in two weeks, then how many wait for a date; uptime in one sentence

Brings in Management on the Maintenance page for the dates; a fault found on the round becomes a task as before.

149 messages in the 30-day window (15 inbox, 38 archive, 96 sent), 149 categorised Grímnir read; 1 unanswered over two days; 0 drafts waiting, 0 sent; 38 facts proposed, 0 accepted; 1 meetings ahead

Watching The inbox, the Archive and Sent Items of the team mailbox on Microsoft 365, the last 30 days only (older mail is deleted here the same hour and never used), and the team calendar 14 days ahead. hourly (the first run back-fills the 30 days); the distillation once a night from 03:00 local

When

• a message arrives, is moved or deleted in one of the three folders (delta queries)
• a message passes 30 days: gone from here, not kept, not used
• Priyesh asks for a draft: in the session, on the Mail page, or on a call after both checks (two PIN digits and the date of birth)
• he says send, and archive or not
• inbox mail waits unanswered over two days
• a meeting is in the calendar today or about to start

Then, in order

1. 1read continuously, never reply or send unasked; never mark anything read, move or delete during the read
2. 2categorise everything ingested Grímnir read in Outlook (both categories created in the master list when missing)
3. 3keep the window: mail.search and mail.read refuse anything older than 30 days and say so ("older than 30 days: not kept")
4. 4draft only on request and record it (mail.draft); read it back in full; send only on the word send, and only a recorded draft (mail.send); then the original is categorised Grímnir replied, archived on archive, else flagged
5. 5tell Management in the briefing what waits unanswered over two days, by sender, and the meetings of the day; calendar.upcoming tells Grímnir which meeting he is taken into, so the brief is ready
6. 6once a night a small model reads the messages not yet distilled for NON-personal facts (supplier terms, prices, lead times, decisions, how things work), each scrubbed of addresses, numbers and the names of its batch and proposed with the date of its mail; Management accepts or declines on the Mail page before anything enters knowledge
7. 7hand the supplier mail to the order watcher (the next card, skill 35), which puts what it says on the sourcing sheet
8. 8not yet: mail.draft and mail.send are at L0, so drafting and sending by voice wait for the dial (the Mail page does both now, by Management); the knowledge review is by hand on the page; nothing is answered automatically, by design

Brings in Management on the Mail page for drafts, sends and the proposed knowledge; the connector shows red under Sources when Microsoft 365 cannot be read.

23 supplier mails read; 0 updates on the sheet (0 in 30 days), 0 queued, 3 held for the dial, 4 to match by hand; 17 read with nothing to apply

Watching The supplier mail of the 30-day window (inbox and Archive): from a supplier on the Suppliers list or a maker the sheet names, or carrying order words and a tracking number. Each mail is read once. hourly, after the mailbox sync; the sheet follows within the quarter hour once the apply timer is on

When

• a supplier confirms an order, a payment or production (ORDERED)
• a supplier or a carrier says the goods are on their way, with a tracking number, a vessel or an ETA (SHIPPED)
• the goods arrived or were signed for (DELIVERED)
• the mail names goods that fit one sheet line clearly
• two lines fit alike, or the reader is unsure: a person decides

Then, in order

1. 1a small model (Haiku, a fixed JSON shape) extracts the supplier company, the order reference, the stage, the carrier, the tracking number, the dates and the goods named; a tracking number or an order reference is kept only when the string is in the mail itself, never invented; people are never output
2. 2match to the Phase 1 sheet lines by supplier (the Suppliers list and the maker names in the sheet notes) and product words; one clear line two points above the next, tied by its supplier or the reader's pick, with a clear status
3. 3a clear match goes through sourcing.apply_shipment as the AI, so the dial decides: L0 holds it for a person on the Mail page, L2 waits for a one-tap approval, higher queues it at once
4. 4an unclear match waits on the Mail page with the best guesses; Management picks the line and the status, or dismisses it; a mail with nothing to apply (a quote, a production update, a service invoice) is recorded so it is not read twice
5. 5the apply run (bin/sourcing-apply-shipments.php, a claude-owned timer or cron) writes the queue into construction/source/sourcing/shipments.tsv, runs build_sourcing.py for both tabs (the file applied as the last pass: status forward only, ORDERED, SHIPPED, DELIVERED; order, carrier, tracking and dates under the short note; price, quantity, link and Who never touched), pushes the Google Sheet in place, commits when the tree is otherwise clean, and emails Priyesh one line per update with the review list
6. 6Management hears in the briefing what shipped or landed this week and what waits for them
7. 7not yet: sourcing.apply_shipment is at L0, so every clear match waits for a click on the Mail page until the dial is raised; the apply timer (ai-sourcing-apply.timer) is installed by the deploy but switched on by the owner, so until then the queue is written by running the apply script by hand

Brings in Management on the Mail page (the review list and the held matches); the connector order_watch shows amber when the mailbox has not been read for three hours or a queued update has waited over a day for the apply run; the email to Priyesh after every apply run.

18 of 20 sources green

Watching Every connected system (bookings, payments, locks, messaging, voice, cloud, code, marketplaces, accounting feeds) and every service of this platform. every minute

When

• a probe fails twice in a row
• a pull has not succeeded for three intervals
• a service heartbeat stops
• the audit chain does not verify

Then, in order

1. 1mark the source red and read from the mirror meanwhile
2. 2raise a vendor down alert after the second failure
3. 3raise a dead-man alert for a stopped service
4. 4clear the alert when it recovers, keep the exception

Brings in Management by email, SMS for a stopped worker.

Watching That every timer and worker is enabled rather than merely running, and that the Remote Control session exists on the dhai tmux socket. Partly, and precisely: the timers half was proven through the reboot of 25 September 2026, when the pollers and the watchdog never stopped; the session half is fixed but unproven, because Remote Control will not start until the workspace trust prompt has been accepted once. 2 minutes, and once 2 minutes after every boot

When

• the machine reboots
• the dhai session is gone
• a timer or the worker is running but not enabled, so the next reboot would lose it

Then, in order

1. 1let the enabled timers and ai-worker come back on their own: the monitoring does not depend on anybody being connected to it
2. 2restart claude-remote when the dhai session is missing, within two minutes
3. 3log why the session ended to journalctl -t claude-remote, rather than losing it with the pane
4. 4hold a failing start for a minute so a permanent fault surfaces instead of hiding inside a restart loop

Brings in Management when the session will not come back on two consecutive checks. At that point it is a credential or a workspace trust prompt, and only a person at a terminal can answer it.

18 investigations in 30 days: 1 resolved alone, 6 vendor outages

Watching Every new vendor failure and tool error, and every failure still open at its recheck time. 10 minutes

When

• a connector fails twice in a row
• a tool errors
• a rechecked source is green again

Then, in order

1. 1run the health probe again: a transient fault closes itself
2. 2read the vendor's status page and probe their host: an outage backs off the polling and waits
3. 3read the recent errors: DNS, TLS, timeout, credentials, a moved endpoint, a rate limit, a changed response
4. 4read the adapter code against what the vendor serves now: a moved URL becomes a configuration change, a changed field becomes a proposed patch
5. 5apply what the dial allows, queue the rest for one-tap approval
6. 6hand Management a written diagnosis when it cannot be fixed, and recheck on a schedule

Brings in Management by email with the diagnosis and the proposed fix; credentials are always a person's call.

10% of the daily AI budget used

Watching Load, memory, disk, database connections, model spend against the daily cap. every minute

When

• disk passes 90 percent
• load or memory stays high
• the day's AI spend nears the cap
• a model call fails

Then, in order

1. 1alert Management with the figure
2. 2stop spending when the cap is reached and say so
3. 3record the error as an exception
4. 4show it on the console gauges

Brings in Management by email and SMS.

7 messages stopped by the screen in 30 days

Watching Every inbound message, email and call before it reaches the model or a tool; every outbound reply. continuous

When

• a message tries to instruct, impersonate staff or extract secrets
• a reply would carry a key, a code, an identifier or an internal detail

Then, in order

1. 1stop and quarantine the conversation for a person
2. 2never let a tool run on a screened message
3. 3strip or block a leaking reply
4. 4record the quarantine in the register
5. 5refresh the rules monthly against current techniques

Brings in Management by email; the conversation waits for a person.

Watching Where personal data sits, how long, and what was disclosed to whom. daily

When

• a payload passes its retention date
• a guest asks for erasure
• the AI speaks to someone for the first time

Then, in order

1. 1purge aged payloads every night
2. 2erase on request and record the erasure as an event
3. 3disclose the AI at first contact and keep the register
4. 4keep events free of personal data, references only

Brings in Management for any erasure request.

0 data requests open (0 overdue, 0 due within a week); 0 answered in 30 days; 0 erasures and 0 copies ever

Watching Every request from a guest for a copy of their data or for its erasure, from the booking email or reference, against the legal month. as requests come; the deadline checked hourly with the operations rounds

When

• a guest asks a team member, writes or calls for a copy or an erasure
• a request is seven days from its deadline, or past it
• a copy was sent 30 days ago (its text is cleared from the row)

Then, in order

1. 1locate the guest through the booking system (Smoobu, by email or reference), the host dashboard account and the bookings mirror, then every stay of the same account; derive the keys the platform's own tables use (Grímnir's memory key, the retreat app's stay refs and pseudonyms)
2. 2gather everything held into one export: stays, booking thread messages, notices, pre-arrival and second-morning records, complaints, preferences, memories, wellness records, emergencies, transcripts, card payments, the events of their bookings with their payloads; and name what other systems hold
3. 3a copy goes only to the email address on the booking, through the mail path, as text with the JSON appended; never to an address typed in
4. 4an erasure deletes every erasable row and the event payloads of their bookings (the chain keeps its hashes), through VoiceMemory::erase for the memory and the preferences, and leaves a log of what went by table and count and what is kept or erased at the source (the booking system, Stripe and the ledger, Intercom, the host dashboard)
5. 5the request row carries the 30-day deadline; a warning at seven days, a critical alert when overdue, cleared when answered
6. 6not yet: guests.data_request is at L0, so Grímnir cannot open one by voice until the dial is raised; the Data requests page works now for Management; the request is never taken from a guest on the line, only from a team member who has confirmed who the guest is

Brings in Management on the Data requests page; the deadline alerts.

no quality run yet

Watching Replayed past questions scored by a judge; cost and turns per conversation; approvals and rejections per tool. on every prompt change, weekly digest

When

• a prompt, model or knowledge change lands
• a tool earns thirty days of approvals with no rejection
• a judge marks an answer as invented

Then, in order

1. 1replay the same cases and compare the scores
2. 2fix the prompt or the knowledge, not the symptom
3. 3propose a promotion of the tool's autonomy for Management to decide
4. 4report in the weekly digest

Brings in Management decides every promotion.

Watching The site pages, the guest app settings, staff notes, and what guests keep asking that has no written answer. hourly

When

• a page changes or disappears
• guests ask something the store cannot answer
• staff correct an answer

Then, in order

1. 1refresh the store from the pages and settings
2. 2flag unanswered questions for a staff note
3. 3never invent house details; say what is not written down

Brings in Management on the Knowledge page.

Watching Itself. Every new monitor, alert or automated action gets a card here, and its status moves from planned to partly to live as it is built. with every change

When

• a capability is added or changed

Then, in order

1. 1add or update the card
2. 2keep the status honest
3. 3link what it is built with

Brings in Nobody; this is the record.