AI & Data Use

The OS uses large-language-model and rule-based AI to support village operators in the following ways:

• Briefings — short morning briefs summarising what changed across alerts, work orders, hospitality readiness, harvest, and external signals like weather.
• Predictions — forecasts derived from operational data (e.g. irrigation demand, hospitality flow, asset wear). Active predictions appear in the Command Center and AI Center.
• Classification & suggestion — categorising alerts, suggesting work orders or recipients, prioritising attention items.
• Agent decisions — recorded actions taken by automated rules, viewable in the AI Center audit feed. Anything requiring human approval is staged through a Pending Approvals queue rather than executed autonomously.

• The OS does not execute irreversible actions autonomously. Approvals required by the operational pipeline stay in the Pending Approvals queue until a human acts on them.
• No chatbot ships in this version of the OS. AI outputs are structured briefings, predictions, and suggestions, not a free-form conversational interface.
• The OS does not make legal, financial, medical, or safety guarantees. Outputs are operational assistance, not professional advice.
• The OS does not replace your accountant, PMS, POS, or payment processor.

AI features see only the operational data of the village they are running for. That includes:

• open alerts, recent work orders, site logs, schedules
• hospitality readiness summaries (units, housekeeping, guest issues — derived from the PMS webhook contract, not bookings or payments)
• revenue summaries (operational, not accounting)
• harvest entries, sensor readings, irrigation/energy schedules, asset maintenance logs
• external context like weather forecasts and FX rate

The AI does not see another tenant's data. AI features are scoped to the same villageId boundary that drives the rest of the OS.

Where the Command Center and AI Center display AI-derived suggestions or attention items, those items carry source references back to the underlying record (alert, work order, prediction, briefing). This makes outputs traceable rather than opaque. Suggestions that lack a source reference are dropped at the assembly boundary.

When the AI provider is misconfigured, disabled, or the data set is too small, the OS may fall back to deterministic or mock outputs. These are labelled — for example with a "mock / system test" badge on a prediction — so operators can tell the difference. The AI Center surfaces the AI mode in a Trust panel:

• real — a real AI provider is configured and responded
• mock — a placeholder output (clearly labelled)
• disabled — the AI pipeline is turned off for this village
• provider_missing — no provider credentials configured

AI processing currently uses Anthropic models. Providers may change as the platform evolves; we will not silently downgrade to a model that produces lower-quality output for safety-critical decisions. Provider credentials are stored as environment-level configuration, never as ticket text or chat content, and never returned through the read APIs that drive the UI.

We do not authorise AI providers to train on your operational data. Where a provider offers a "do not train" mode for API access, that is the mode we operate in. If a provider's policy changes in a way that would make this untrue, we will notify founders/operators before the change takes effect.

AI outputs are decision support, not decisions. The founder/operator remains responsible for the operational and safety choices their team makes, especially in regulated areas (food safety, animal welfare, guest safety, sensor-driven actuation).

If an AI output is wrong, misleading, or potentially harmful, please flag it through the support page with category ai. Citations and the AI Center audit feed make it possible for us to trace what the OS saw at the moment of generation.