How to use it

FROM FIRST SENTENCE TO LIVE SYSTEM.

Pick the hardware. State your intent. Ship. Three steps from the operator's first sentence to a live system. The operator describes what they want in their language; NOUS turns it into pure intent and ships a signed manifest over the mesh.

Behavior change is the same conversation, just continued. The runtime never recompiles. Only the manifest changes. Once the system is live, the operator keeps talking to NOUS the same way they did on day one.

You build it. You own it. You change it. No middle man.

1 · Pick → 2 · State → 3 · Ship → Change behavior later
Restaurant · Operator (unit GM) Talks to the screens every shift. Doesn't write code. Wants to change behavior without calling support.
1 · Pick the hardware
biRT runs on a runtime host you provide — typically a small GCP VM, scaled to your site. The host carries the intent; the operator-facing devices already in the building connect over the local mesh. No new operator-side hardware to buy.
2 · State your intent (operator to NOUS)
“I run a 60-seat dine-in. Take my menu, route orders from the front to the kitchen, settle checks at the table. We're open 11 to 10.”
3 · Ship (NOUS confirms)
“Manifest signed and broadcast over the local mesh to the phone-KDS and POS tablets. Applied at next tick. Dine-in is live — speak any name change for any item or hour any time.”
4 · Change behavior later (operator to NOUS)
“Hey NOUS, we're closing the second grill station for maintenance — should be back up in a few days. Push grill-2 orders over to grill-1, prioritize salads and bowls on the kitchen displays, and have the front-of-house gently steer guests away from grill-heavy items until I tell you we're back.”
5 · What happens
Signed manifest goes out over the mesh to every runtime in the building — KDS, POS terminals, FOH tablets. Applied at the next sync tick. No code shipped. No restart. No outage. Reverted just as fast when the operator says it's back.
Restaurant Group · CIO Owns the operational P&L of the tech stack. Done paying for software. The reframe: not "fewer vendors" — no middle man. The operator IS the platform.
1 · Pick the hardware
Production-class compute behind your existing WAN. Each unit's existing operator hardware joins over the mesh. Your data stays where it is — because it was always yours; nobody else has a copy now. No new middle man signed.
2 · State your intent (CIO to NOUS)
“47 units, 3 brands. I'm canceling our POS, KDS, loyalty, labor, and BI contracts at renewal. You're the runtime now. Each brand's menu, pricing, and labor rules are ours — they were always ours. Roll up nightly P&L by brand and by region. I sign off on every behavior change at brand level; GMs sign off at unit level. Nobody outside the company gets to gate a change.”
3 · Ship (NOUS confirms)
“Three brand manifests authored. Signed at corp. Broadcast over the mesh. Live across all 47 units the same night. The runtime is in your hands now — not licensed, not subscribed, not rented. Yours.”
4 · Change behavior later (CIO to NOUS)
“NOUS, we just closed on 8 units in the Tucson DMA. Fold them in as a 4th brand. Their existing menu carries over for 90 days; after that we re-pitch them on our standard frame. No integration project. No middle man on the receiving end. The runtime just extends.”
5 · What happens
Brand-4 manifest signed at corp, propagated to 8 new unit runtimes. Brands 1-3 unaffected. Reporting roll-up extends from tonight. No truck rolls. No change-order. No middle-man pass-through. The 90-day pricing override auto-expires; standard manifest takes over on day 91 unless extended. You didn't call anyone to do any of this.
Restaurant Group · CTO Owns the architecture. Done outsourcing the runtime. Every "integration" today is a tax paid for the privilege of standing on someone else's API. The reframe: you own the runtime. You own the data. You own the manifests. The vendor APIs were an artifact of a world where you didn't.
1 · Pick the hardware
Production-class compute as the corp-tier runtime. Each unit's existing POS/KDS/labor hardware joins the mesh as a runtime tile. Your warehouse stays where it is — we push signed event records to it. The pipeline is yours end-to-end now. Nothing leaves your perimeter unless you say so.
2 · State your intent (CTO to NOUS)
“Cancel our 4 vendor surfaces — POS, KDS, loyalty, labor — at renewal. You're the runtime. Stream a signed event record per order, per shift, per state change into our warehouse. Sandbox tier on 2 pilot units. I want auditable diffs on every behavior change. No third party ever holds our event log again.”
3 · Ship (NOUS confirms)
“Pilot manifest authored, signed, broadcast to your 2 named units. Event-stream contract published — one signed line per state change, delivered to your warehouse over your network. The other 45 stay on the legacy vendors until your green-light. Every change between now and promotion lands in your audit log.”
4 · Change behavior later (CTO to NOUS)
“NOUS, pilots clean for 6 weeks. Promote to fleet. Cancel the POS, KDS, and labor contracts on the 45 — the cutover is the day the manifest goes live. Hold loyalty for one more cycle while I figure out if we keep that surface or fold it in too.”
5 · What happens
Promotion manifest signed at corp, broadcast to 45 units. Three vendor surfaces go cold the same day. Loyalty stays vendor-routed per your hold. Every change is one signed manifest in your audit trail. You can diff fleet-state at any timestamp against any other — forever, because the log is yours.
Restaurant Group · IT Director Every new store is a hardware build. Every patch is a midnight push. Every break is a vendor ticket and a "we're escalating to engineering." The reframe: there is no engineering team in another building. The runtime is yours. The audit trail is yours. The rollback is yours. Tier-1 reads the diff and ships the fix.
1 · Pick the hardware
Production-class compute as the corp-tier runtime. The mesh discovers each store's existing hardware on first power-on. QR-scan provisioning — no golden image to maintain, no vendor portal to log into.
2 · State your intent (IT Director to NOUS)
“Onboard new stores in under an hour from hardware-arrival to live. Single audit trail for every config change, with one-click rollback to any named checkpoint. Tier-1 reads the audit and ships the fix — no escalation to a middle man that doesn't pick up at 2am. After-hours alerts page me only when order capture or payment breaks.”
3 · Ship (NOUS confirms)
“Provisioning manifest signed. New-store QR cards in the opening kits. Audit-trail view live in your support portal. Pager rules applied — you only hear about order capture or payment failures after hours. The day you cancel the vendor support contracts, nothing changes for tier-1 — because the runbook is already yours.”
4 · Change behavior later (IT Director to NOUS)
“NOUS, store 38 reporting KDS lag at dinner rush. Roll the KDS surface back to the manifest from 11 days ago — that was stable. Suppress non-emergency alerts from store 38 for 2 hours while I review. Page me only if order capture breaks.”
5 · What happens
Store 38 KDS manifest reverted to the named-checkpoint, applied at next tick. Other 46 units unaffected. No truck roll. No middle-man ticket. No "we're investigating." The diff between today's KDS manifest and the 11-day-old one is in your audit log — you can read it yourself if you want to know what changed.
1 · Pick the hardware
A dedicated production-class compute instance for the plant-wide controller — bulk translation, manifest broadcast, alert routing all on the metal. Each line station's existing operator hardware connects over the mesh.
2 · State your intent (operator to NOUS)
“Five lines, plant A. Track throughput. Alert me when any line drops below target by 10%. If a line slows, route surplus to lines with headroom. Shift starts 6am.”
3 · Ship (NOUS confirms)
“Manifest signed and broadcast from the controller to every line phone. Applied at next tick. Throughput board is live — speak any new threshold any time and I redeploy.”
4 · Change behavior later (operator to NOUS)
“NOUS, line 3 is running half speed today — QA is sampling. Don't trip the under-throughput alert, and route the surplus to lines 4 and 5 if they have headroom. End of shift, go back to normal.”
5 · What happens
Manifest signed and broadcast to all five line runtimes. Applied at next tick. Alert thresholds shift; routing kicks in only if 4 and 5 have capacity. The runtimes themselves do not change. Auto-reverts at shift end.
1 · Pick the hardware
biRT runs on a runtime host in dispatch — a cloud VM or a local x86 controller, your call. Field crews carry whatever ARM hardware your team already standardizes on as the mesh terminal: biRT runs natively when the bootloader is reachable; runs as an Android-hosted form when it isn't. Multi-transport: short-range wireless, long-range radio, IP, and physical.
2 · State your intent (operator to NOUS)
“Dispatch jobs by zip. Page the storm-response team on weather alerts. Suppress non-emergency tickets in active storm zones until the all-clear.”
3 · Ship (NOUS confirms)
“Manifest signed and broadcast across the mesh. Applied at next tick. Dispatchers see the new routing now. Crews stay in sync without cloud uptime.”
4 · Change behavior later (operator to NOUS)
“NOUS, the storm is hitting the southern region. Postpone all non-emergency dispatches in zip 30500–33999 for the next 12 hours. If anyone in that area calls about an active outage, page the storm-response team instead of the regular crew.”
5 · What happens
Manifest pushes to dispatch and customer-portal runtimes across the affected region. Applied immediately. Auto-reverts in 12 hours unless extended. No code changes anywhere.
Honest note

These three flows are illustrative of the design, not transcripts from a production system today. The runtime, the manifest pipeline, and the mesh transport are shipped. The conversational manifest authoring layer is in active development. We will update these flows as each layer hardens, and we will publish real numbers the first time a customer ships.