Every AI product works in the deck. Decks are built to work. A demonstration has to settle something harder: whether the thing runs on the documents your people open, on hardware like the machines you own, against a question you chose. Buyers put it to us without decoration — everything works well in PowerPoint, and every claim still has to be proven in a test deployment.
Demos & Proof
What Should an AI Demo Show,
and How Do You Get One?
The script to send ahead, the accuracy comparison to insist on, and the line between what a demonstration settles and what only your own corpus can.
Built from real buyer questions in our sales meetings
Direct Answer
Ask for it to run on your documents, your hardware, your question. A session staged on someone else's material proves someone else's outcome. Iternal declines to show generic content and asks you to nominate a use case so the demonstration runs on your data. The version that settles it is small and specific: a short ingestion run on a real sample of your files, then a live accuracy comparison you can read.
The limit: a demo proves the pipeline runs, not that it holds. A curated sample says nothing about the scale, the file variety or the neglected corners of your full corpus. Live sessions also break — a local model has hallucinated mid-run, output has drifted a couple of lines in, a document set that skipped the server-side processing came back less clean than an optimized one, and a booth with no machine on site fell back to pre-canned material. Treat a clean demonstration as necessary rather than sufficient.
What to verify while you watch. Send the sample yourself, uncleaned; a tidied set flatters the tool. Write the question list in advance so it cannot be steered. Ask for the accuracy report produced on your own files, block by block and in aggregate, and ask whether the build on screen is the build you would receive. The questions below put each of those in writing.
A demonstration and a funded engagement are different instruments. The session is an afternoon. The work that follows carries success measures, configuration and your real volume — Iternal calls those proofs of value rather than proofs of concept, because the software works out of the box and needs configuring. For more information visit the first use case page and the trials and community editions page.
What a Demonstration Has to Prove
The request never varies much. Can I see it. Can someone walk my leadership team through it. Can our architect get a deep dive rather than a highlights reel. Underneath sits a harder demand, put to us in almost the same words: experienced purchasers will not trust AI accuracy until they see it proven, and nobody moves forward without watching the product run against the real data sets.
Generic material fails that demand predictably. An aerospace buyer shown invented documents could not map the session onto the complexity of their own corporate functions; a shipped demonstration set that cannot answer a live question makes the same point from the other side. Hence the nominated use case: value becomes legible on your own data, or not at all.
The Script You Send Ahead
Three inputs and one output. Send them before the session is booked, and the meeting stops being a performance:
| What you send | Why it changes the result |
|---|---|
| A real document set, chosen by you | A manual, a contract folder, a policy library — untidied. Iternal expects evaluators to bring their own documents rather than lean on the demonstration data sets, and a cleaned set proves less than the one your staff open daily. |
| A written question list | Questions your people ask today, whose right answers your experts already know. Written beforehand, they cannot be steered around. Improvised in the room, they can. |
| A named use case, not a tour | The useful question is never what the product can do. It is whether it does the one thing you would buy it for. |
| An accuracy comparison out | The same corpus queried both ways, each answer displayed beside the exact source page, so a reviewer checks the document rather than trusting the summary. |
Getting the session is the easy part. Iternal splits customer demonstrations into a weekly general-admission webinar and private white-glove sessions, and channel partners can stage the walkthrough themselves. The webinar tells you what the product is; only the private session can be pointed at your documents.
The Comparison to Insist On
Ask for the artifact, not the assertion. Iternal states that a Blockify report shows, block for block and in aggregate, what your accuracy is, and calculates token savings on the customer's own data. That is a document you can circulate to the people who were not in the room — a different order of evidence from a number recalled afterwards.
Underneath the report sits a side-by-side. Iternal routinely queries the same corpus two ways, through standard retrieval chunking and through the Blockify output, and shows the answer beside the raw PDF it came from. Run that on your files with your question list and you stop comparing marketing positions; you are reading two answers your own experts can already grade.
Scope the sample to the session. Ingestion speed follows the machine it runs on. A server is built for the volume; on-device processing is far slower, and a few hundred pages of PDF ingested inside the assistant has taken hours rather than minutes. So send something small, real and representative, and get the number for your sample on the machine that will run it:
Pin it down: questions for your evaluation
-
Which machine will run the ingestion for our session, and how long will our sample take on it?Whether the files fit inside the meeting — one timing figure never covers both a laptop and a server.
-
Will we receive the accuracy report generated on our own documents, block by block and in aggregate?That the comparison leaves an artifact behind rather than a number recalled after the call.
-
Is the build being demonstrated the build we would receive, and what is still in development?What ships today versus what is scheduled, before an evaluation is written around a later release.
-
Can we re-run the same question list ourselves, on a machine we control?The result on your own hardware — the one version of the answer nobody else staged.
Paste Something In Before You Book Anything
The lowest-commitment version of this test needs no calendar. Iternal publishes a Blockify ingest demonstration on its showcase site: a visitor pastes in a document and watches the algorithm work on it. Signing in takes an email address, which keeps bots out, and it accepts a page or two of upload — enough to see the mechanics, not enough to be your evaluation.
One caution, stated plainly: it is a public tool, so nothing sensitive should go into it. Pick a page you would email to a stranger. The material that matters belongs in the private session, on your hardware. The instinct is still worth borrowing: the most persuasive demonstration Iternal runs is the one where a visitor puts their own hands on the keyboard.
What a Demonstration Cannot Settle
A clean session earns the next meeting. It does not earn the rollout. A curated sample shows the pipeline running end to end; your full corpus — its scale, its file variety, the folders nobody has opened in years — stays untested until somebody tests it. Closing that gap is what a funded engagement is for. And when a session does break, read the breakage as evidence rather than as a verdict: a straight account of a bad run tells you more about the people you are buying from than a flawless one does.
The last irony is worth naming. Demonstrating an air-gapped product remotely still needs a connection, because the screen share does — so the offline claim is precisely what a screen share cannot show you. Install it, pull the network, ask again. For more information visit the offline and air-gapped page.
Answered elsewhere
- Getting hands on with no scheduled session — see the trials and community editions page.
- Meeting an organization already running this in production — see the references and case studies page.
- Setting the measures a first funded piece of work must hit — see choosing a first use case.
- Weighing a local assistant against the cloud one you already license — see the existing-assistant comparison.
- Assembling the stack yourself from open-source parts — see building it in house.
- Judging which market claims deserve an evaluation at all — see what is actually true right now.
FAQ
FAQ: Demos and Proof on Your Own Data
Your documents, your question list, and an accuracy comparison you can take away. Nominate a real, untidied set; write the questions before the call so they cannot be steered; ask for the corpus queried through standard retrieval chunking and through the Blockify output, each answer shown beside its source page.
Yes, and the report is the point. Iternal states that a Blockify report shows, block for block and in aggregate, what your accuracy is, and calculates token savings on the customer's own data. Ask for it to be generated on the files you supplied and handed over, so the finding outlives the meeting.
Iternal runs customer demonstrations two ways: a weekly general-admission webinar, and private white-glove sessions; channel partners can also stage the walkthrough themselves. Only the private session can be pointed at your material, so send the sample, the question list and the named use case with the request.
Turn each claim into an observable event before the session, then watch for it: your files ingested, a question from your list answered correctly, the source page shown beside the answer, accuracy and token figures calculated on your documents. Anything unobservable on the day belongs in writing instead.
A small, real, representative sample rather than the library. Ingestion speed follows the machine it runs on: a server is built for the volume, on-device processing is far slower, and a few hundred pages of PDF ingested inside the assistant has taken hours rather than minutes. Ask which machine runs your sample and how long it takes there.
Read it as evidence rather than as a verdict. Live sessions do fail: a local model has hallucinated mid-run, output has drifted a couple of lines in, a document set that skipped the server-side processing came back less clean than an optimized one. Ask what broke, and what changed afterwards.
Send the Script, Then Watch Your Own Files
The discipline fits on one line: name the use case, send an untidied sample and a written question list, and ask for the accuracy report calculated on those files. What you learn after that is about your corpus rather than someone else’s.