Engineering Demonstrations
We would rather show you a running system than describe one. Every demonstration here is labelled by what it actually is — interactive, prototype, verified implementation, production, or planned — and the labels mean specific things, defined on this page.
What exists, and what state it is in
A fictional example is never presented as a real customer case. Where something is planned rather than built, it says so. This is the only honest way to publish a capability library, and it is why the list is short.
Customer Renewal Intelligence
A renewal-risk agent running against a real relational database with synthetic data. Six versioned rules, a permission boundary, an evidence chain and an approval gate that records the decision in the database. The results on that page are fetched at runtime, not written by hand. The page also maps each part of the demonstration to the production capability it stands for, and says which part is implemented and which is not.
Synthetic data · 12 tables · 6 rules · live API Open PrototypeSupport triage with tool access
A working prototype in which an agent reads entitlement and ticket context and proposes a resolution, escalating on defined criteria. The tool contracts and the escalation rules are implemented; the integration to a real ticketing system is not.
In build · available on request Open PrototypeOrder-to-cash exception queue
A prototype application unifying order exceptions under one agreed definition, with drill-through to source records and an agent that proposes resolutions with evidence. The application shell and the reconciliation logic are built; no system of record is connected.
In build · available on request Open PlannedPolicy enforcement agent
Versioned policy expressed as testable rules, blocking and escalating on non-compliance, with every check evidenced. Specified and costed; not yet built. We would rather list it here than pretend it exists.
Specified · not built Open PlannedSemantic layer comparison
A side-by-side evaluation of the same question answered through three different retrieval strategies over one dataset, measured rather than asserted. Planned because it needs a real corpus to be worth publishing.
Planned · needs a client corpus OpenThe taxonomy, defined precisely
These labels are the difference between a capability library you can rely on and one that is marketing. They are not decoration, and we would hold ourselves to them.
Interactive
Runs in front of you, in your browser, against a real data store. The output is computed when you open it, and you can inspect the underlying records, the rules and the evidence. You can also change the outcome — approve or reject an action — and the decision is recorded.
The data is synthetic unless the page says otherwise, and the page always says so.
Prototype
A working build of the specific capability, in front of our team, demonstrating that the approach holds. It runs, and it is honest about the parts that are stubs.
It is not production-ready, it is not integrated with your systems, and we will say which parts are which.
Verified implementation
A capability we have built and delivered for a client, and can walk you through the engineering of under NDA, with the client's name withheld if they require it.
We describe what was built, in what environment, and what it did in operation — without publishing metrics we cannot evidence.
Production
A capability running in a client's production environment, monitored, with an operating history and an owner.
We publish these only with the client's explicit permission, and only to the level of detail they approve.
Planned
Specified, understood and not yet built.
Listed so you can see the direction of travel, and never dressed up as existing.
Three rules we apply to everything published here
Synthetic means synthetic
Generated data is labelled as generated, on the page itself, next to the demonstration and not buried in a footer. If a page contains real customer data it says so and explains the basis.
No invented numbers
No accuracy percentage, no ROI figure, no latency claim, no adoption statistic. If we have not measured it against real data, it is not on the page — including the flattering numbers.
Show the seams
Every demonstration states what is implemented, what is simulated and what is not connected. The failure modes are as visible as the working parts, because that is what tells you whether we know what we built.
About the demonstrations
Q1Is the Customer Renewal Intelligence demonstration a real customer implementation?
No. It is a demonstration we built, on synthetic data generated by a seeded script. The schema, the rules, the permission model, the evaluation and the approval workflow are real code you can inspect. The customers, contracts and tickets are fictional. We label it clearly on the page and we would ask you not to cite it as a reference.
Q2Why build a demonstration instead of describing a deployment?
Because in enterprise AI the description and the system are routinely not the same thing. A working demonstration lets you interrogate the engineering — the records it reads, the rules it applies, the evidence it cites — rather than assess a claim. It also forces us to make our own method explicit, which is usually the most useful part of the conversation.
Q3Does the demonstration use a language model?
No. The recommendation is computed by a deterministic rule engine over the database. That is a deliberate choice: it means the same input always produces the same output, every claim carries a source reference, and there is nothing to hallucinate. The page states this explicitly in its transparency section.
Q4Can we see a demonstration using our own data?
Yes, and it is usually more useful. An early engagement often includes running the method against a slice of your real records under NDA, so you can see the reconciliation findings before committing to anything.
Q5Do you have reference implementations we can talk to?
Some, under NDA, and we will walk you through the engineering of them. We will not publish a customer name, a metric or a reference without that customer's explicit agreement, so you should not expect a page of logos.
Q6Why are some demonstrations listed as planned?
Because they are specified and not built. Listing them makes the direction of travel visible, and it is the alternative to quietly implying that more exists than does. We would rather show a short list with honest labels than a long one that is fiction.
See it run against your own records
The most useful version of this is your data. Under NDA, we can apply the method to a slice of it and show you the reconciliation findings.