Eight answers, and what each one proves
Presentations are easy to make and demonstrations are easy to rehearse. These are screenshots of BrainStorm answering ordinary questions against JD Edwards®, including the ones where the honest answer is inconvenient.
All screenshots use JD Edwards demonstration data (JDV920). The supplier names, order numbers and amounts are the demonstration set’s own, not a customer’s.
A purchase order approved from chat, and the record it left behind
Four screenshots, one session, one order. Nothing between them was edited out.
It works out who you are before it asks anything
“My approval” is not a parameter someone typed. BrainStorm resolves the signed-in user’s own address book number first, then asks JD Edwards what is waiting on that person. A different user gets a different list, because it is a different question.
It also states that the row limit was not reached — so the reader knows the list is complete, rather than assuming it.
One order in full, including what looks wrong with it
Header, originator, hold code, line detail, receipts and vouchers. The status path is resolved against the order activity rules, so the next status and its alternates are shown rather than a bare code.
The requested date precedes the order date. Nobody asked about that. It is flagged anyway, because someone about to approve the order should know.
It asks before it writes, and shows exactly what it will send
The instruction was “approve order 795”. BrainStorm reads the order back, states plainly that the action will change data in JD Edwards, names the capability it intends to call, and prints the literal payload — every field, every value.
Then it stops and waits. The approval happens on the word “yes”, and not before. There is no hidden step between the screenshot and the outcome.
The approval, as JD Edwards recorded it
This is the record JD Edwards keeps, read directly. Order 795 carries the approved flag; the neighbouring orders do not. The released-by column holds the signed-in user’s own ID — not a service account, not an integration user, not a pool. Other rows in the same view were released by other actors, which is how you can tell the column means something.
JD Edwards will tell you an order is approved. Finding out who approved it means reading the record. So that is what is shown here.
The point of the sequence is not that four things worked. It is that the identity that asked the question is the identity that signed the approval, and the audit JD Edwards produced is the one it would have produced had the user clicked through the screens.
An order created from a sentence, and the warning that came back with it
It finds the right capability, runs it, and tells you what JD Edwards said
The instruction names a branch, a supplier and two item lines. BrainStorm locates the published capability that creates purchase orders, checks what that capability expects, supplies it, and reports the new order number back — with both lines as entered.
JD Edwards returned a non-blocking warning on the requested date. It is passed through word for word, with an explanation of what it means and where to change it. Warnings that get swallowed are how automation quietly produces work nobody trusts.
The reasoning is on screen as well. What the assistant considered, and which capability it settled on, is visible rather than inferred — down to the capability’s own name. Capabilities are named and versioned: this one takes few parameters and defaults the rest, and a more flexible variant can sit beside it for the cases that need one.
Two write paths are shown on this page — approving an order and creating one. Both went through capabilities that were published in advance, under the signed-in user’s identity, and both reported exactly what JD Edwards returned.
Where the honest answer is the inconvenient one
A system that is only ever seen succeeding at well-formed questions has not been shown to be trustworthy. These three were chosen because the answer is awkward.
It argues with the question
Asked which invoices make up a supplier’s 61-to-90-day overdue balance, BrainStorm answers that there are none — that bucket is empty — and then shows where the balance actually sits, ageing bucket by ageing bucket, and offers the follow-up the user meant to ask. A plausible list would have been easy to produce and impossible to trust.
It grades its own answer
The arithmetic gives one number. BrainStorm reports it, then points out that most of it comes from two receipt lines whose unit cost and unit of measure cannot both be right, and restates the figure a buyer can actually use. Then it says which records to investigate first. The number and its reliability arrive together.
It says what the data does and does not prove
A voucher with two offsetting pay items, the payments applied against each, what the net effect is, and what it means in a sentence. And then the limit: this reflects what JD Edwards recorded, not whether the payments cleared the bank. An answer that knows the edge of its own evidence is worth more than one that does not.
What to do with this
Put BrainStorm in front of real users, real documents and real work. Let them ask the questions they actually ask and attempt the tasks that actually matter. A fixed-price Pilot exists for exactly that, so the trial carries no open-ended cost.