Brrelo

platform

One engine.
Every process.

Brrelo's code knows records, stages, gates and moves — it has never heard of a ticket or a loom. Your industry arrives as data, in a pack, and the same engine runs it.

How one engine covers every domain

clinic-intake.pack v2
4 records · 6 stages · 12 fields
RecordsVisit · Patient · Referral · Consent
StagesArrived → Triage → Seen → Discharged
GateDischarge ◆ duty doctor
MenusWaiting · In triage · Reports
installs anywhereportable

A pack is a whole process, in a box

Record types, fields, workflows, menus, vocabulary — one artefact. Install a ready-made pack and customise it, or let the assistant build yours from a description.

Because a pack is data, it lifts cleanly into another workspace or another tenant. What you modelled once, you never model twice — and what you know about your industry becomes an asset you can move, version and even sell.

MANUFACTURING PALETTE

needs machinelogs stoppageproduces output
→ generates Shift, Machine, Qty out

CASEWORK PALETTE

takes statementhome visitconsent captured
→ generates Witness, Statement, Consent date

Stages declare what they do, too

Most platforms hardcode what a stage captures — so a clinic ends up with "Operator" and "Shift" columns on a patient visit. In Brrelo the capability palette is content: a pack declares that a stage takes a statement or produces output, and the engine generates exactly those fields.

A domain nobody catalogued just declares new capabilities — the palette grows with the packs, never the code.

A LIFECYCLE'S FOUR STATES

carrieda pack offers it
proposedapproved proposal · in a pack draft
draftyours · invisible to the engine
livethe engine runs it

Draft, then publish — never both at once

A process exists in one of four states: carried (a pack offers it), proposed (an approved assistant proposal inside a pack draft), draft (yours, editable, invisible), live (running). Every screen names the same four — because they come from one place.

Only a person moves a definition to live. Approving the bot's proposal isn't publishing; it just saves your draft.

A MOVE CAN DO EXACTLY FIVE THINGS

setemitnotifyspawnprovision user
webhook · postrefused at parse

A closed set of actions

Moves set fields, emit events, notify, spawn records and provision users — nothing else. A proposal or capability that promises behaviour the engine can't run is refused up front, not discovered in production.

That's a feature, not a limit: when your model says a move notifies, it notifies. There's no "sort of works" state.

uptime · monitoredlive
backed up daily02:00
isolated workspaceper tenant
dedicated deploy optionEnterprise
storage used1.4 GBof 5 GB

Ops included. Lock-in, not.

Managed storage, scaling compute, daily backups, monitoring and security updates — all in the plan, not an add-on tier. Workspaces stay isolated and uploads sit in private storage behind your auth.

When regulation or policy demands it, the same platform deploys dedicated to your cloud. And packs, records and files export — leaving is a chore, not a hostage negotiation.

Frequently asked

Is this a low-code builder?

No. There's no canvas to wire and no code generated underneath. A process is described as data — records, stages, moves, gates — and one engine interprets it. There is nothing to maintain per app.

What if my industry isn't in the catalogue?

Declare it. The assistant can write a pack for a domain nobody catalogued — new record types, new capabilities, new vocabulary — and the engine runs it like any other.

Can a bot publish changes by itself?

No. The assistant proposes; approving a proposal only saves your draft. Publishing is always a person's act.

Can I take my process elsewhere?

Packs are portable data — install them in another workspace or tenant, where they arrive as an offer, never something in force. Records and files export too.