Reporting.Stream

Somebody noticed something. Thirty seconds later it is on the record, in their words, attached to the thing they noticed it about — and the office has it, straight from a phone in the field.

Call it a report. Call it a note, a status update, an observation, a ticket, an issue, a snag, a bug, a heads-up. It is one short piece of writing about one identified thing, and what it means is yours to decide — we supply the structure and the vocabulary is yours.

What filing one actually involves

1. Open your site's address. Already signed in. nothing to install
2. Pick what kind of thing it is — your team's kinds are at the top of a short list. one tap
3. Say which one: type what is written on it, or pick it from the list where there is one. best effort is good enough
4. Say what you saw, the way you would say it to a colleague. a sentence is plenty
5. Photo if a photo helps. Does it need someone to act? Send. receipt on screen

The problem is universal

Every organization runs on resources: equipment, vehicles, rooms, infrastructure, inventory. All of them drift out of spec, and the person who notices first is almost never the person who repairs, replaces, or budgets for them — and almost never the person who holds a login to the maintenance system.

What gets lost in between is time, and with it the pattern. A symptom mentioned in passing on one shift and again on another is two pieces of hearsay. The same symptom recorded twice against the same resource is evidence.

A universal solution is simple

Frictionless reports from the field become a durable record against the thing they are about, and the office gets to act on a pattern instead of a rumour. That is the whole of it — and the three parts below are all there is.

Actors send reports from the field

Whoever is at the sharp end: the driver, the technician, the volunteer, the nurse. They sign in through your own identity provider — no new passwords to issue, no accounts to retire by hand — and what they file is attributed to them permanently.

Every actor can serve on a team: the group they speak for in your business. At a driving centre that might be drive team, logistics, workshop; in a hospital, nursing and porters; in a shop, floor and back room. You name them. A team says who is speaking, not what they are allowed to do. Report access and the ability to act are explicit, so neither follows from a team name alone.

Resources are whatever you say they are

Cars, radios, medical devices, forklifts, walk-in coolers, staplers. You define the kinds that matter to you; the platform supplies no industry vocabulary and imposes none. A resource is anything identifiable your business looks after — the things whose condition you cannot otherwise see.

Every resource carries an identifier

A sticker, an asset tag, a unit number, a QR code — whatever your people already say out loud. A resource without an identifier cannot be reported on. Identifiers can be free-form and accumulate as people go, or be strictly enumerated and inventoried — and either way the system takes what is typed, because best effort is the whole point.

A report is one observation

Mostly it is a sentence or two — tweet-length, and welcome to run longer when the situation deserves it. Filed from the phone already in the actor's hand, with no form to learn and no categories to get right.

filed

2026-10-11 14:32 UTC

by

a-2088 · R. Vance · science lab · prep room

about

BAL-3 · top-pan balance

“Reads about two grams high once it has warmed up — checked against the reference weights, and it is the balance, not the glassware. Three class sets were weighed with it this morning.”

The timestamp and actor and resource ids are the record. The name, the team, and the kind of resource ride along for whoever reads it — but the identifiers are what the system reasons about, and the team is recorded as it stood at the moment of filing.

Reports are delivered to the office

The office is whoever is responsible for doing something: the shop, the biomed department, facilities, the duty desk. Reports arrive in the order they were filed and are kept exactly as submitted — corrections and conclusions are recorded alongside an observation, never on top of it. What the field said remains what the field said.

Every act is performed under an explicit hat. A member hat files for its team, from the field. A team controller works the reports of a named team — that is the office. A site administrator configures one site, and an operation administrator configures its sites, without automatically seeing their reports: configuring a place is not working its stream. The capacity in force is always visible and recorded with the act.

One organization, many sites

A site is a place that runs itself — a centre, a branch, a hospital, a depot. Each site owns its own resources, identifiers, and reports for their entire lifetime, and each is reached at its own address — one page, on any phone, nothing to install. Configuration can cover a site or an operation; report visibility remains a separate, explicit question rather than a side effect of an administrative title.

Setting it up is an afternoon

No implementation project, no data migration, no inventory to assemble first. A site starts working once somebody has answered three questions.

And every team sets its own order on top of that: the few things it reaches for first, and what it would rather not see at all — nothing is taken away, because anyone who needs a kind their team left out turns that off for themselves.

The simplest possible start: one building of rooms

You do not need an inventory to begin. For a hospital, make the site the building and the first kind just rooms. The identifiers take care of themselves — everyone already says room numbers out loud — so there is nothing to enumerate and nothing to name. That is enough to file against on the first morning:

identifier

Trauma-242 · a room

“The elevated bed doesn't rise all the way.”

One kind, one list that already exists, one sentence. Beds, pumps, and cuffs can become kinds of their own later, and nothing filed in the meantime has to be redone.

Inventory, if and when you want one

Reporting stands on its own. A report carries the identifier as it was written and needs nothing from a list behind it, so a site can run for years on free-form identifiers and never keep an inventory at all. An inventory is an overlay you add, not a price of entry.

When you want one, it comes together two ways. Type in what you already know — the rooms, the bays, the rows of the lot — and the form starts offering them. Or let it grow from what your people file: a controller enrolls a report, and every earlier observation of that same thing joins it. Most sites do both — declare the rooms, accrue the cars.

It is meant to be partial. Three of forty enrolled is a normal, useful state: the rest keep reporting and join the moment someone enrolls one. A kind can be a fixed list or wide open, and that decision can wait. And nothing is ever deleted — a sold car is retired, its reports kept, its number free for the next one — while the pictures accrue into a history no one has to maintain.

Day one — the walk-around

It starts with the phone already in somebody's hand. The app goes into inventory mode, and every car in the lot is the same five seconds: photograph the car, type the number off the sticker, add a word if it helps — Guards Red, bay 3 — and submit. One tap, and it stays put for the next one:

photo → number → a word or two → submit → next

There is no list to consult and nothing to get right. The photo is the record, and the number is all the office needs to line the walk-around up with everything that car has ever been reported for. A controller opens the queue and enrols each one — one act per car, and every earlier report that names the same number joins it. By the end of the afternoon the fleet has faces and histories, and nobody was handed a spreadsheet.

What that looks like

• Healthcare

  A nurse finds the infusion pump in bay 6 running fast — the rate will not hold where it is set. Biomedical engineering sees the unit and the last three reports against it, and pulls it from the floor before the next round of patients.

• Community & non-profit

  A Saturday volunteer reports the food bank's walk-in cooler sitting warm. Facilities is reached while the pallets are still good, and the cold-chain record exists later, when a grant audit asks for it.

• Automotive

  A driving instructor reports a car pulling right under hard braking. It comes out of rotation before the next guest session, and the observation stays attached to that vehicle for the rest of its service life — including across the shop that eventually finds a different cause.

• Retail

  A cashier says lane four's scanner misreads produce codes once it warms up. The right team sees the pattern at that store instead of another complaint that disappears in a break-room conversation.

• Logistics & fleet

  A yard hostler flags a trailer's landing-gear pin as sloppy. The unit is held before it is loaded, and the history follows the trailer rather than the driver who happened to speak up.

• Industry & utilities

  An operator reports a rising whine from a conveyor bearing. The office has it before shift change, and the report still reads as the operator wrote it after the diagnosis turns out to be the gearbox.

Illustrative scenarios. Resources, identifiers, kinds, and who may see them are defined by each organization; the platform supplies the structure, not the vocabulary.

Your organization is not a template

Start with one team in one place. Grow to several sites, several teams, and several organizations working side by side without inventing a new kind of account or baking a location into a job title.

A person may hold more than one hat — for example, a member of the drive team, a controller for workshop, and a site administrator — but wears one at a time. The hat says what capacity is in force; the team or place it is held over says where that capacity reaches.

That makes contractors, volunteers, working leads, and cross-cover ordinary rather than exceptional. If two organizations need to cooperate, chosen teams can share a narrow, read-only view without turning it into permission to change one another's work. Nothing is inherited from an org chart: authority is explicit, narrow, and visible.

Sign in in a way that fits

An operation can use its own identity providers where it has them, or an approved email address and an authenticator app where it does not. Authentication establishes who someone is; a hat establishes what they may do. Neither a provider, an email domain, nor a group name quietly becomes authority.

With one provider, the organization onboards every team member into that system and applies its normal multi-factor policy — a passkey, authenticator prompt, security key, or whatever it already trusts. A person opens their Reporting.Stream site in a browser, signs in with that familiar organization account, and returns to their work. There is no Reporting.Stream password to issue and no app to install.

One provider is usually the clearest arrangement: one place for onboarding, offboarding, recovery, and multi-factor policy. More providers are useful when the organization itself is genuinely plural, not as a menu of social accounts people must sort through. Every accepted sign-in is matched to a known actor, and changes to access remain explicit, reviewable hat grants.

Already using Reporting.Stream? Your site has its own address, e.g. https://your-site.reporting.stream. Sign in there.