What SuperhostOS actually is
A governing runtime, a real workload, and the public claims we are willing to make without publishing the protected method behind them.
Start with the distinction
The easy way to describe SuperhostOS is by the workload currently attached to it. That is also the least useful description. Hospitality tells you where the system is being tested; it does not tell you what the company is building.
SuperhostOS is a governing runtime. The public promise is about consequences: repeated work should become less expensive to run, factual answers should stay tied to sourceable records, and limits should remain visible instead of being hidden by fluent output.
Why hospitality comes second
A governing system needs work that can prove it wrong. Bookings, supplies, turnovers, calendars, guests and money are useful because the consequences are concrete. Our own operating fleet gives the runtime something real to answer for.
That makes hospitality the first live workload and the proving ground, not the identity of the machine.
What we are willing to claim
The Curator can act on a real portfolio. Airbnb calendar import is live. Marketplace and orders are live. A master calendar covers arrivals, departures and turnovers. Photo and voice input are live where the product says they are live.
Personalisation is early. Opening the runtime beyond our own operating fleet is next. Those labels matter because an aspiration is not evidence merely because the code exists somewhere.
The deliberate gap
We will discuss observations, results, failures, constraints and the fields of engineering involved. We will not publish the protected implementation method simply to make a marketing page sound technical.
That is not an invitation to trust us blindly. It is the opposite: judge the public claims by what can be observed and verified, while accepting that the mechanism itself is not part of the public brochure.