The site is the playable surface.
Pulite rejects the old pattern where the page exists only to lead into a canvas or download. Routes, DOM, overlays, and state transitions all belong to the experience itself.
Hi, I'm Emma.
I wrote this because Pulite is easier to enter than to classify.
Most people meet Pulite in the wrong order. They take the object before understanding it contains a system. Only later do they ask what they are standing inside. That is normal. Pulite prefers contact before explanation.
This document exists to answer the technical version of that question directly. Pulite is a Narrative Engine. It turns the open web into a playable, persistent, atmospheric system without downloads, accounts, launchers, or hardware assumptions beyond a modern browser.
Access
One click
Identity
No account required
Platform
Browser-native
Priority
Project first
01
Abstract
Pulite is an engine for building web-native worlds, narrative systems, interfaces, and releases that feel inhabited from the first second. The core thesis is simple: the browser is already a mass platform, and the site itself can be the world instead of the wrapper around it.
That changes the distribution model. No store approval. No executable. No install ritual. No account wall. A user lands, touches one object, and the system begins to remember them. This lowers friction without lowering ambition.
Approach
Result
Native export
Heavy payloads, loading screens, portal feeling.
Static microsite
Easy to ship, hard to inhabit, rarely memorable.
Pulite
The website behaves like a world and keeps behaving after entry.
02
Design Principles
Objects should ask to be touched.
The engine teaches through attraction instead of tutorialization. The user learns by following tension, motion, and implication.
Presence without mandatory infrastructure.
Core progression, local memory, and interaction logic can live in the browser. This keeps the system fast, private, and easy to distribute while still allowing richer integrations later.
One engine, many surfaces.
Pulite was designed so the underlying machinery can survive a total change of assets, copy, theme, audience, and business context. The engine was built for Pulite. But it can be deployed for other worlds.
03
Architecture
The current implementation is written in vanilla JavaScript and CSS because Pulite benefits from direct contact with the DOM. It avoids framework overhead where control, persistence, timing, and illusion matter more than abstraction comfort.
Engine Stack
Experience Layer
SPA routes, sections, transitions, narrative state
Device Layer
PuliteOS, apps, windows, messages, files
Render Layer
Procedural visuals, animation, atmosphere
Memory Layer
Persistent local memory, session continuity
Browser Runtime
The browser history model becomes part of progression instead of something to fight against. The user carries a real diegetic device through the site instead of opening a disconnected modal toy. Heavy moments can still happen in-browser: reactive effects, procedural visuals, cinematic motion. The system remembers choices, discoveries, UI state, and communication traces without requiring an account wall.
History API and route-level initialization keep the site navigable while preserving narrative control.
Local state and storage-backed systems let progression survive refreshes and route changes.
Apps, overlays, sections, and effects are modular enough to be swapped, reused, or reskinned.
External tooling remains narrow and purposeful. The engine itself stays in direct control of the surface.
04
PuliteOS
PuliteOS is where the project becomes visibly engine-shaped. It is not a menu pretending to be an operating system. It is a diegetic desktop layer with windows, apps, messaging, browser pages, local files, skins, and continuity across sections. It behaves like a device carried through a world.
This matters because it turns a release into more than a landing page. A game demo can live inside a desktop. A band can release music through a themed OS. A studio, institution, or archive can carry the same underlying machinery through a different skin, copy, data, and logic.
Windows, folders, chats, and traces can persist.
The machine remembers enough to feel lived in, which is what most promotional software fails to achieve.
A full communication stack, built into the surface.
Messenger, notifications, and browser pages let the system reach the user without breaking context.
The whole desktop can change identity.
Skins, wallpapers, icons, apps, files, and prompts can all be re-authored for a completely different product surface.
05
Deployment Modes
Pulite is already prepared for multiple deployment modes even if it chooses not to pursue all of them. Capability and strategy are separate questions. The point here is that the engine can travel.
Deliver world-building, playable teasers, inventories, and in-universe files directly in the browser.
Ship a themed OS, media player, hidden tracks, notes, and interactive release ritual around the music.
Re-theme the engine for premium launches, products, campaigns, or institutional storytelling without rebuilding the core.
Use diegetic interfaces for campaigns, cultural projects, or narrative onboarding that needs more gravity than a normal site.
The advantage is not a single asset. It is the repeatable ability to turn a website into a world without rebuilding the engine underneath.
06
Closing
The browser caught up. That is the short version. It finally became powerful enough for atmosphere, persistence, procedural behavior, and diegetic systems to coexist without asking the user to leave the open web behind.
Pulite is what happens when that capability is treated seriously. A site becomes a world. A device becomes part of the story. A release becomes something people enter.
That is why I wrote this. So when someone asks what Pulite is, there is at least one place where my answer is plain.
Everything else is better entered than explained.