MMeurneoba OS

AI & Data Use

Last updated: 2026-10-15

Draft for legal review. This document is a founder-authored draft describing how Meurneoba OS is operated today. It is not a substitute for legal advice and has not been reviewed by counsel. Production deployments should commission a legal review before relying on these terms.

What AI does inside Meurneoba OS

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 in the AI Center audit feed. Work orders the AI proposes wait in a Pending Approvals queue until a person approves them. Alerts and notifications the AI raises are sent to the property's managers straight away, without approval, because their job is to warn people quickly.

What AI does NOT do

  • The OS does not operate equipment or move money on its own. The AI can raise alerts and send notifications to managers; anything that assigns work goes through a person first.
  • The AI makes no decisions about people: it does not decide statements, bookings, votes or access. Those follow the rules of the property and the people who run it.
  • 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.

What data the AI sees

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

  • open alerts, recent work orders, site logs and schedules, including text typed by staff (which may contain names);
  • hospitality summaries: units, housekeeping and guest issues;
  • revenue and income totals;
  • harvest entries, sensor readings, irrigation and energy schedules, asset maintenance;
  • weather forecasts and exchange rates.

It does not receive passwords, ballots, residents' statements or payment details. The AI provider (Anthropic, USA) processes this under its data processing terms and does not use it to train its models.

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.

Citations & provenance

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.

Mock and system-test outputs

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 on this server, for every property it runs
  • provider_missing — no provider credentials configured

Providers we use

AI processing currently uses Anthropic models. If the main model declines a request for safety reasons, the provider may answer it with another Anthropic model instead; the model that answered is recorded with each AI review, briefing and proposed work order. Providers may change as the platform evolves. 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.

Training

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.

Operator responsibility

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).

Reporting concerns

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.