In almost every immersive attraction we visit, the technology is beautiful and the operation is spoken. Everyone knows what to check in the morning: it lives in two people's heads. Everyone knows what failed last week: it lives in a message thread. Everyone knows what maintenance costs: they find out when the invoice arrives. Carbone logs all three in one place, on the tablet that is already in someone's hand.
The name comes from carbon paper: the sheet you slip underneath to keep a copy of what you have just written. You write once, and a trace of it survives elsewhere, for whoever comes next. That is word for word what an operations log does: the act happens once, on site, and it goes on existing for someone else.
Try the demo
The specimen runs right now, in your browser. It opens with a code we hand out on request, and it runs on an invented venue: no real data behind it, and nothing leaves it.
This is a service under development, not software off the shelf. What you see here runs on an invented venue. A log is only worth anything if it describes your spaces, your machines and your way of opening: which is why every rollout starts with a site visit and with writing the checklists alongside the team. The detail is further down: a made-to-measure service.
The gap you find everywhere
Job ads from immersive venues say it all. They describe multi-zone audio, DMX, cameras and PLCs in fine detail, and almost never say who, during a session, sees the real state of the system, or on what. The pre-opening checklist does exist: it is simply filed inside somebody's memory, and it evaporates with the person who leaves.
The cost of that gap is not paid on the day it is overlooked. It is paid three weeks later: a door mag lock has been slipping for ten days, someone said so out loud on a Tuesday, nobody wrote it down, and the door ends up standing open in front of a group.
Three moments, one log
The tool does not run the show: it keeps the record of it. It covers the three moments when somebody actually has time to write.
-
Opening: twenty-six checks, four phases
Life safety, power-up, walk of the spaces, operations. Every check is marked pass, issue raised or blocking. An issue raised calls for a sentence and a photo; a critical check that has not passed keeps the signature greyed out. It is the checklist that holds the door, not goodwill.
-
The floor, before the machines
Cleanliness, lost property, dangerous object: three distinct things that get wrongly lumped together. What soils gets cleaned, what a visitor lost gets returned, what can injure gets removed at once. A shard of glass under a low shelf is invisible from above. It shows up under a raking light, and it gets logged.
-
Incident: thirty seconds, not an insurance form
Where, which equipment, what was seen, the effect on the session, the minutes of downtime, a photo. The record places itself on the floor plan and opens a maintenance task. Photos are kept at 1600 px: enough to read the printing on a fuse.
-
Closing: seventeen checks, and the readings
The same look at the floor, then the numbers: sessions run, visitors, consumables drawn. It is the most thankless act of the day, and it is the one everything else depends on: with no readings, the forecast is worth nothing.
-
The cleaning instruction, which nobody writes to
A field that stays open, filled in during the evening walk. It is not addressed to maintenance but to the cleaning crew, who come through before them: what needs going over again, and what must on no account be touched.
-
An issue raised becomes a task, on its own
When the opening is signed, with nothing to re-enter. An issue you have to copy out somewhere else for it to exist is not entered twice: it is lost once.
Try “Blocking”. It is the whole point of this article: it is not goodwill that holds the door, it is the checklist.
A checklist is closed by a signature
First name, surname, drawn with a finger, timestamped. Until all three are there, the checklist is not declared, and as long as a critical check is still open, the signature block refuses to arm itself and says why. The signature goes out attached to the report.
This is not red tape. An unsigned checklist is a memory aid; signed, it becomes a document, the one you pull out six months later when you have to establish who checked what, and at what time. It is also, very concretely, what an insurer or a fire safety inspector will ask for after an incident.
This is the exact stroke the demo produces: same generator, same seed. It goes out attached to the report, next to the name and the time.
The floor plan, because a word placed in the right spot is worth a paragraph
“Because there is no use telling it 1 time to 1000 people or telling it 1000 times to one person.”
Say it once to ten people, or ten times to one person: either way, one of them will not have heard it. Placed on the plan, it is said once, to whoever comes past.
The route is drawn out: eleven spaces, the visiting direction dotted in, the two plant rooms set back. You drop a marker with a finger at the exact spot, and hang a thread of comments, photos and a document off it. The maintenance technician who turns up knows where to go before putting the toolbox down. What kind of marker it is reads from the colour and from the shape as well (a square for planned works), so the information still holds for someone who cannot tell the hues apart.
A marker can be moved. You pick it up and put it down somewhere else; if it changes space, what it is attached to follows on its own and the move is written to the audit trail. It looks like a detail; it is not. A marker placed roughly is worse than no marker at all: it sends someone to the wrong place convinced they are in the right one.
All of this can be handled
Work through the checklist, report an incident, move a marker on the plan, correct a stock count: the demo responds the way the tool does.
From the counter to the budget
This is the part venues improvise the most. Every piece of equipment carries an interval in its own unit: hours for a projector, cycles for a mag lock or a trapdoor, days for a statutory inspection. The evening readings advance the counters, the counters move the due dates, and the due dates make the budget, parts and labour included.
None of these four figures is entered twice. It is the same data running through: the counter gives a date, the date calls for a part, the part gives an order-by date, and that one has already gone.
This is where most tools stop, and it is where the bill lands. Every service task carries its parts list: descaling the low fog circuit draws a litre of descaler, greasing the trapdoor draws one grease cartridge, checking the wireless links draws eight batteries. So against each task the schedule shows what it will draw from the store, and flags in red when the stock will no longer be there on the date it is due, with normal usage and other service tasks already deducted.
A cost you can check
A maintenance forecast is only worth anything if every figure comes apart. This one adds up nothing that does not match a line: labour hours at a rate, and part numbers at the store price. The breakdown is shown in plain sight under each total, namely 2 h × €68 + €86 of parts, and the parts named are the ones the task will actually draw from the store, not a lump sum dropped alongside.
›The three billing regimes, and the UPS case
Three billing regimes coexist, because there are three in real life: the in-house crew by the hour, the outside contractor by the hour plus a call-out charge, and theapproved inspection body at a flat rate for statutory inspections: emergency lighting, extinguishers. Collapsing all three into a single rate is the first way to produce a costing nobody can defend.
Same logic on intervals: the UPS carries two distinct due dates, an annual discharge test that costs nothing but time, and a battery bank to replace every four years that costs three hundred and fifty euros in hardware. Merging them into one line billed the bank every year. It is mistakes like that, not the big ones, that make a forecast unusable.
The store
A tab of its own, because stock is not something you consult: it is something you correct. Standing up, in front of the shelf, on a tablet, with a thumb. Hence single-unit steps and goods-in by pack size: you do not receive “a litre” of low fog fluid, you receive a five-litre drum. Every movement goes to the audit trail.
Two kinds of item live there, and they are not managed the same way. A consumable runs down at a rate, so many litres per session, so many cartridges per task; you reorder it on days of cover. A spare part, no: it does not wear out on the shelf. It is called for by a dated service task, and it has to be ordered before that date, supplier lead time deducted. Managing the second on an average rate makes no sense: it would appear to evaporate on its own, or to last forever.
›The reorder plan, and the part numbers that exist only to show the link
The consequence reads backwards in the reorder plan: for each part number, the order-by date, the quantity, the amount, and what is pulling the stock : namely, the service tasks coming up. An order stops being an arbitrary expense; it becomes something you can argue about.
A few part numbers in the specimen exist only to make the link visible. Mechanical grease and descaler are consumed by no session at all: without the link their stock would look eternal and nobody would order them, until the day of the task, when the part would be missing. Conversely, the mag lock and the LED strip power supply are called for by no scheduled maintenance at all; they sit on the shelf because they are the ones that stop the show. The table has to be able to say “cover not applicable” without going red: a deliberately dormant stock is not a stockout.
The dashboard
Twelve rolling weeks. Not for decoration: to tell the equipment that costs money apart from the equipment that makes noise. Incidents per week stacked by severity, operational availability against its target, spaces and equipment ranked by minutes of downtime, and the duration of the pre-opening check, which on its own tells you whether the team has taken the checklist on board or is merely enduring it.
And the report
At the end of the day, one single document: signatures, issues raised, what was found on the floor, incidents, readings, the cleaning instruction, plan markers, open tasks, anything falling due within three weeks along with its parts, the reorder plan, the thirty-day forecast, attachments. One recipient, maintenance, and one action. The report goes out exactly as it appears on screen; it can also be downloaded, because an operator wants to be able to file it without depending on us.
Five pieces, taken exactly as they are
None of these images is a mock-up. They are screenshots of the demo, taken at the exact spot where the mechanism shows.
On the team's tablet
This is the real workstation: a tablet held in one hand, in a badly lit venue, by someone who is walking. The interface reorganises itself for the screen, and it is not the same page shrunk down: in landscape the rail stays open; in portrait it becomes a bottom tab bar and a check's three answers take the full width. Targets are sized for a thumb, nothing depends on hovering, and a wide table scrolls inside its own card without ever pushing the page.
Every column heading and every figure carries its own explanation, because a log's vocabulary belongs to nobody else: “margin” does not mean here what it means on a profit and loss account.
What it changes
Critical checks (exits, emergency lighting, floor, trapdoor, intercom) block the signature until they are cleared. The rule is held by the tool, at six in the morning as much as on the fifth day in a row.
An immersive venue runs on seasonal staff. Whatever is not written down is relearned at every hire, at the price of a fault or two.
The same reading feeds the maintenance schedule, the reordering and the cost per visitor. Nothing is entered twice, so everything gets entered.
A timestamped record, a photo and a point on the plan are worth three phone calls back and forth, and make remote supervision possible between two visits.
A made-to-measure service, not software off the shelf
CARBONE is under development. What the demo shows is a complete, playable specimen, but it describes an invented venue: “La Verrière”, eleven spaces, a group size of eight. No real venue looks like that one, and that is exactly the point: an operations log that does not speak the house language will not be kept, and a log that is not kept is worth nothing.
So a rollout always starts in the same place: on site. We walk the route with the people who open and close, we write the checklists with them rather than for them, we survey the equipment and its real intervals, we draw the plan of the route. That work is what makes the tool; the software is only what carries it.
- The checklists : your checks, your phases, your vocabulary, and above all your critical checks: what, in your venue, must forbid opening.
- The equipment and its units : hours, cycles, sessions or days depending on the machine, with the manufacturer's intervals corrected by what you actually observe.
- The floor plan : the real one, at the scale of the route, with the visiting direction and the plant rooms.
- Consumables and their parts lists : your part numbers, your pack sizes, your suppliers and their lead times, and what each service task actually draws from the store.
- Where the report goes : to your technician, your in-house crew, your technical management, or to us if we hold the on-call duty.
- The activity, not just the venue : an actor-led attraction, an escape room, a museum after dark and a multi-purpose venue do not open the same way; checklists do not copy across from one case to the next.
At this stage, we are looking for venues to build the first real installations with. What you see here is the material, not the finished product: the functions are there and they work, while hosting, multi-user accounts and integration with an existing estate are decided case by case.
Try the demo
Twelve simulated weeks of operation on a fictional venue. Nothing leaves it: sending to maintenance opens a preview of the email instead of posting it, and the demo's state never leaves your browser.
Carbone has a control-room sibling: ARGUS, the tower that watches the session while it happens. An incident declared from Argus arrives here already filled in, with the exact time, the zone and the state of the system at that moment. Carbone holds the before and the after, Argus holds the during: the same day, seen through its two halves.
Under the bonnet
- No outside dependency : nothing is fetched from outside the machine on load, not even the typeface. What runs at your place depends on nobody else.
- The grammar of the Darkvalley suite : Carbone wears the skin shared by our operations tools. An operator running several of them does not relearn where to look each time.
- Colour is only ever used for state : green, amber, red, and nothing else. Spending it on decoration makes it inaudible where it matters.
- Nothing leaves the browser : the demo's state lives on the machine, and nothing is sent. That is a choice specific to the specimen; a real installation obviously has a server behind it.
- A photo of a fault has to let you see the fault : photos are downsized before being kept, but only just enough that a cracked solder joint or the printing on a fuse stay readable. An attachment that only proves a photo exists is no use at all.
- The demo replays the same day from one meeting to the next: twelve simulated weeks of operation, identical every time it opens.
- The chart colours are verified so they stay distinguishable to colour-blind readers, and verified again after every change of skin: a palette is validated against a given surface, not in the abstract.