Same Fibric. Wildly different operations.
A hotel, a paper and print company, and a warehouse share nothing about how they work. They share one problem: something is always about to go wrong in a system nobody is watching closely enough. Here is the same loop, sense then reason then act, told three times on three operations that look nothing alike. Read them side by side and the pattern is the point.
The building runs on a fixed overnight schedule. It pre-heats the whole property at 5 a.m. whether ten guests are arriving or none. Half the floors warm up empty while the late check-ins walk into cold rooms. The night manager has no way to see occupancy, weather, and the building's own systems in one place, so nobody touches the schedule. It just runs.
Fibric reads the building management system, the property's reservation feed, and the weather, and folds them into one live picture. Tonight it sees occupancy at 0 on the east wing, 14 confirmed arrivals landing between 9 and 11 p.m., and an outside temperature of 31°F and dropping. Every input is real and current. Nothing is assumed.
A base model reads that picture and works out the rhythm of the night: which rooms will be occupied and when, how long each takes to reach a comfortable setpoint at 31°F, and which floors can stay dormant until they are needed. It weighs comfort against energy and proposes a plan, a sequence of timed setpoint, lighting, and access changes. It does not act on its own conclusion. It hands the plan to the executor.
The executor checks each step against the policies the hotel set, never let a guest room fall below 66°F, never disarm access on an occupied floor, and runs only what passes. It pre-conditions the east wing 40 minutes before the first arrival, holds the empty floors dormant, and stages corridor lighting. Single-flight and idempotent, so a retry can never double a command. It acts through the building systems already installed. No new hardware.
By the time a tracking number says “label created, not yet scanned,” the order is already late and the customer is already calling. The only place to win is upstream of the carrier, on the floor, while there is still time to fix it. That is the whole job of this operator.
Around 600 orders are open at any time. Each one can slip for a different reason: a proof the customer never approved, a stock shortage, a press that ran long, a finishing step that backed up. No single screen shows which orders are about to miss. The team finds out when the customer calls, which is always too late to do anything but apologize.
Fibric reads the order book from the ERP, the proof-approval queue, and live production status, and joins them per order. It sees that order #PR-20418 has its proof unapproved on day 2 with the press already booked, and that #PR-20355 is short on a stock that will not arrive in time. Real order data, joined across systems that normally never meet.
The model scores every open order for its risk of missing its ship date, and ranks the few that are both high-risk and still fixable. An order already on the press is risky but not actionable, so it drops down the list. One stuck on an approval, upstream of the carrier scan, is exactly where a nudge still changes the outcome. It proposes the worklist and the action for each.
For #PR-20418 the executor places a hold so the press slot is not wasted, then nudges the customer for the proof approval and tells the account owner why. For #PR-20355 it escalates the stock shortage to purchasing. Each action is checked against policy first, and never escalates the same order twice. The receipt records what it saw, what it proposed, and what it did.
One station stalls and the whole floor feels it ten minutes later. A scanner drops, totes pile up behind it, and the work that should have flowed through gets stuck because there is nothing routing around the jam. By the time a lead walks over and notices, the pile-up has spread and the late inbound is about to make it worse. The exception is small. The cost of finding it late is not.
Fibric reads the warehouse management system, the state of every station and lane, and the inbound schedule, as one live picture refreshed continuously. At 09:14 it sees station 3 stall, its scanner offline with 22 totes queued behind it, while stations 5 and 6 run with spare capacity and a 10:00 inbound is due to land right on top of the jam.
The model works out where flow is about to break and what relieves it fastest: not just that station 3 is down, but that its open work can move to 5 and 6 without overloading them, and that the incoming dock slot should slide back so it does not compound the queue. It proposes a coordinated plan across routing and scheduling, in one move, rather than three people reacting separately.
Within seconds the executor reroutes station 3's open work to 5 and 6, pushes the 10:00 inbound to 10:40, and notifies the floor lead with the reason and the receipt. Every step is checked against policy first, never overload a station past its rated rate, and runs single-flight so a reroute cannot fire twice. The line keeps moving while station 3 gets fixed.
This is reach, not a vertical menu.
Fibric is not a hotel product, a print product, and a warehouse product stitched together. There is one kernel and one loop. A hotel's chiller, a paper company's open order, and a stalled pick station are the same kind of thing to it: a system it can sense, reason about, and act on, under the same governance.
So these three stories are not the catalog. They are proof that the catalog is open. If you can connect it and say what good looks like, an operator can run it. The next story is the one you write for your own operation.
Tell us what you run. We will write the next story.
Whatever you operate, the loop is the same. Point Fibric at it, set what good looks like, and watch the first plan before anything runs.
Real data only. Every action checked before it happens.