Six models. One device.

Application model

An application is a page and, when it needs one, a service. Everything is described by a single manifest of Beroun's own format, and parts of the system use exactly the same format as third-party apps.

• The interface is a web page, rendered by WPE WebKit. Interfaces open one at a time in one shared window: open an app and it takes the screen, close it and the launcher returns. An app that needs its own window says so in the manifest, as the browser and Caroline's chat do.
• The state contract. On closing, an app saves its place and always comes back to it: the open file, the folder, the conversation, the scroll position. The system checks it.
• Services outlive the window. The manifest sets when a service starts (at boot, on first open, by hand), its priority, its memory budget, whether it runs while the device sleeps, and whether it may take the screen, as an incoming call does. The system dispatcher starts services, measures them, and under memory pressure stops the least important first.
• File types. An app declares what it opens, and the file manager sends every file to the right app.
• Native programs too. Ordinary Wayland and X11 programs are described by the same manifest and run alongside web apps.
• Tools for the assistant. The manifest's caroline section lists the tools and skills an app offers, so Caroline can drive it directly.

Hardware model

A unified system interface for buttons, sensors, camera, audio, display, power and storage, the same on a device and in the simulator.

• One hardware layer. All hardware access goes through one system interface; nothing else touches a device. That is why one system runs on real hardware and on its simulator.
• System buttons. Each has a job fixed by the system: the assistant button, power, volume, and the exit button. System buttons never reach an application, and the assistant button always gets through, whatever is open.
• Power. A dedicated power service: a short press sleeps and wakes, a long press powers off with a farewell screen, and the device powers on from off.
• Sleep. The device sleeps like a phone and wakes instantly. Services allowed to keep working do so, and an incoming call wakes and rings.
• Memory that holds. Everything the device runs lives inside a set memory budget. On top of it, compressed swap in RAM, and idle pages written back to flash under a daily write limit that protects the flash. When room still runs out, the lowest-priority services stop first; the assistant never does.
• Screen, sound, input. A touch screen and physical buttons, microphone and speaker, and an on-screen keyboard with several layouts and voice input.

Network model

Profiles and access points, VPN and proxy configuration, traffic control and secure connections through one consistent interface.

• Wi-Fi as a system service, with saved networks and one device-wide connection state that apps and the assistant read the same way.
• Network time. Date, time, time zone and NTP synchronisation belong to the system, not to an app.
• System notifications for network, battery and storage events, delivered to the owner and to the assistant alike.

Agent model

An application can contain agents: specialists that carry out tasks in their field. The app publishes them to the system, and Caroline uses them. Agents are declared in the same manifest, run as autonomous workers, and speak a task protocol in the form of A2A.

• Skills with inputs and results, the permissions they need, and where the agent runs.
• Tasks with a life cycle: progress, cancellation, and questions to the owner routed through Caroline.
• AI services through the system dispatcher, with every call logged under the agent's name.

The agent model in full →

Storage model

Filesystem, database, application state and assistant memory are managed as parts of one system, with backup and migration in mind.

• The owner's home is on the memory card, ext4, with no FAT32 file-size limits. Applications see the card as their root and nothing outside it.
• Separated data. Each app sees only its own part: files on the card and its own state. System data is kept apart.
• The assistant's memory of the owner, their people and standing rules is part of the system's data, not of an app.

System API

One set of system services for applications and the assistant alike. Whatever an app can show the owner, the assistant can show too, through the same call.

• Message boxes in the system's own style, answered with the same buttons everywhere.
• System sounds and vibration for events, confirmations and alerts.
• A notification panel in the launcher, with do-not-disturb, fed by apps, by the system and by the assistant.
• The clock: date, time, time zone and network time, with reminders from the calendar.