What every run leaves behind

Your AI team runs. Somebody gets messaged, something gets checked, a report goes out. Then what?

Until now the only thing left behind was a trace — a step-by-step record for you, the person who built it. Useful for fixing things, unreadable to the business owner paying for it, and different in every project.

Now every run of every project also leaves a result: one small record, the same shape everywhere, that answers the only question a business owner really has — is this thing working?

What one looks like

What it was about — the customer, invoice, patient or product, using their identifier. Not ours.
What happened — one of five outcomes (below).
A line for the owner — "Reminded Mrs Okafor about ₦45,000 outstanding for Term 2, due 5 days ago." Written for them, not for you.
What was delivered — every message that went, where it went, and whether it arrived.
Anything worth knowing — findings raised by an Assess step.
Numbers and words a chart can use — amounts, days overdue, stock left; branch, product, class.
What it cost — how long it took, how many model calls.

The five outcomes

Everything counts on these, so there are five and there will not be more.

Outcome	Means
Handled	Done. No person needed.
Needs human	Triaged and handed over. Somebody must decide.
No action	Looked, and correctly did nothing.
Blocked	Couldn't finish — no phone number on file, a service down.
Failed	It broke.

Two of these are worth dwelling on.

No action earns its place. An AI team that only reports when it acts is indistinguishable from one that has stopped working. "Checked 200 carts, 197 were fine" is the reassurance people are paying for.

Blocked is not failed. "No phone number on file" is the business's own data to fix, and it shows up as a data-quality problem. "The model errored" is ours. Putting them in one bucket means nobody ever fixes either.

These are worked out from what actually happened — not asked of a model. A message that went is handled; an address that was never filled in is blocked. The only parts a model writes are the summary, the grouping and the numbers.

Setting it up

Settings → What this project reports.

The kinds of thing it handles — one per line, in the words the business uses: balance-overdue, low-stock, high-risk-transfer. Results get grouped by these, so keep the list short and change it rarely. RAiN's packages arrive with a starting list; edit it to fit the client.

What each run is about — customer, patient, supplier, SKU. Free text, because a row is a different thing in every business.

Currency — held once, here. Amounts are recorded as plain numbers, so nothing needs rewriting the day a client bills in something else.

Clock — the customer's, not yours. A record stamped in UTC shows a Lagos school its nine o'clock reminders going out at eight, and they will tell you it is broken.

Send a copy to — optional. Each record is also POSTed to this address as JSON: a webhook, an automation, or the business's own system. It is a copy — RAiN keeps the record either way, so a webhook that expires costs you nothing but the timeliness.

Fan-out and batches

When a trigger runs once for each row, every record carries the batch it belonged to and its place in it. That is what turns forty-seven separate events into one readable sentence: "the 09:00 job reminded 47 customers, 3 unreachable."

Questions people ask

Does this cost anything? One small, cheap model call per run to write the summary and pick out the numbers. Everything else is worked out without a model. You can switch the whole thing off per project with Keep a record of every run.

Does a test run count? Yes, and it is labelled as one. A run you started yourself is recorded as manual, so a dashboard can leave it out — but it is not silently dropped, because then you could never check that recording works.

What if the summary is wrong? The summary is the only part a model writes freely. The outcome, the deliveries and the subject are all taken from what actually happened, so a wrong sentence never turns a failed send into a successful one.

What happens when a run fails? It still leaves a record, with the error as the summary. A project that only reports when it worked looks exactly like a project that has stopped running.

Can the business see all this? That is what it is for. Findings are shown with what was checked — and what each check found — so nobody treats a finding as an oracle, and a wrong one can be corrected rather than merely disbelieved.

Where do I see them? The Results tab on the project. The counts across the top answer "is it working?" — how many were handled, how many need a person, how many were blocked. Below that: recent firings, then one line per run with its summary, what was delivered, and any findings.

The same records are available to Rivium Helix, which draws the fuller dashboard. Because every package leaves the same shape behind, that needs no bespoke work per package — which is the whole reason the record is worth having.