The Briefing Document: A Technical Correction
In the early hours of June 24, 2026, formal demand emails were sent by an individual operating under the name "Verit Analytics" — a corporate identity that does not appear to have existed before this campaign began, which is itself a business formation timeline that raises questions — to several AskDiana team members and to at least one external party: a business contact at a company with whom we have an active commercial relationship.
The emails contain what he describes as a "technical briefing document" alleging systematic misrepresentation, regulatory violations, and fraudulent marketing. A July 5 deadline is stated. A payment of €5,000 is demanded as "settlement." Non-payment is explicitly linked to distribution of the "case file" to customers, regulators, investors, and journalists.
This is a description of extortion. It is being handled accordingly.
What I want to address here is the technical substance of his briefing document, because it contains a specific architectural claim that is, at its foundation, wrong — and the rest of the document is built on that error. The wrong claim is this: that AskDiana is a cloud-only platform with no on-premises capability.
Understanding why this claim is wrong requires understanding the difference between two very different things: AskDiana's core platform, and AskDiana's Extensions Marketplace. His briefing document confuses them. I will explain exactly how, and in doing so, explain why someone preparing a serious technical indictment might want to read the documentation a little more carefully before pressing send.
The Central Error: Two Systems, One Misreading
AskDiana has two distinct software systems that operate independently:
System 1: The Core Platform. This is the document Q&A, analytics, and Genius² system described throughout this blog series. It deploys as a Docker Compose stack. The components — Flask/Gunicorn backend, Next.js frontend, MySQL, Qdrant vector database, Neo4j knowledge graph — run on whatever hardware the deploying organisation chooses. The language models run via Ollama, locally, on the same hardware. No query needs to leave the network. This is what the marketing claims about on-premises and air-gapped deployment refer to.
System 2: The Extensions Marketplace. This is a separate, newer subsystem — an app-store-style platform that allows third-party developers to build and publish add-ons that extend AskDiana's capabilities. Extensions are plugin software written by external developers. They run on AskDiana's cloud infrastructure, using a scoped SDK. The developer documentation for this system uses https://app.askdiana.ai/api/ext as its example base URL, because extensions — by definition — connect to the cloud-hosted marketplace. This is correct and by design, for the same reason that an iOS application connects to Apple's App Store infrastructure: that is what a marketplace is.
His briefing document quotes URLs from the Extensions Marketplace SDK documentation — specifically from the developer portal's getting-started guide and API reference pages — and presents them as evidence that the entire AskDiana platform routes through cloud infrastructure. This is an error at the level of concluding that iPhones require Apple's servers because iOS developers use App Store Connect. It is, in the technical literature, what is known as a mistake.
Two details make this particularly clear.
First: the SDK documentation itself marks the base URL parameter as optional, with an explicit comment directly below the URL he cited: "Optional — Ask DIANA instance URL." It is the default example for developers building extensions for the cloud marketplace. A deploying organisation running AskDiana on-premises would set this to their own instance URL. The parameter exists precisely because the system can point anywhere. This detail is not hidden. It is on the same page as the incriminating-looking URL, immediately below it.
Second: the Extensions Marketplace routes sit under /api/ext/ and use a completely separate database (ask_extensions). The core platform's document Q&A, chat, and RAG pipeline operate on different routes, against a different database, and are entirely independent of the Marketplace subsystem. Reading the Marketplace SDK documentation tells you about the plugin ecosystem. It tells you nothing about whether the core platform requires cloud connectivity.
"There Are No Docker, Kubernetes, or Helm Charts"
This specific claim appears in his briefing document as evidence that no genuine on-premises deployment mechanism exists.
The core AskDiana platform ships with a docker-compose.yml and a docker-compose.dev.yml. They define the full production stack and the development stack respectively. They exist. They are in the repository. Clients use them to deploy. His briefing document's claim to the contrary is factually incorrect, which is a difficult position for a document that presents itself as a rigorous technical audit.
Docker Compose is a Docker deployment artifact. Stating that an on-premises deployment uses Docker Compose is not a marketing evasion — it is a deployment specification. The claim that "no Docker deployment infrastructure exists" is contradicted by the files themselves, which will continue to exist after July 5, the stated deadline, in much the same way they existed before it.
The Chrome Extension Is Not the On-Premises Deployment Mechanism
His briefing document refers to AskDiana's Chrome extension as evidence that the platform is not truly on-premises — characterising it as a "VPN tunnel" that bridges cloud infrastructure to on-premises data.
This description fundamentally misunderstands what the Chrome extension is for, and what it is not for. It is a misunderstanding of a kind that a technical audit might be expected to avoid.
The Browser Proxy Extension is designed for a specific hybrid deployment scenario: organisations that want to use the cloud-hosted version of AskDiana, but also need to access data sources that sit on their private network — an internal ERP system, a database behind a firewall, a legacy application that cannot be exposed to the internet. In this scenario, the Chrome extension runs in a user's browser and acts as a bridge: AskDiana's cloud infrastructure sends a polling request, the extension fetches the data from the internal resource via the user's authenticated browser session, and returns the result. The data never needs to be exposed externally.
This is a sophisticated feature for a specific hybrid use case. It is entirely separate from the on-premises deployment path.
Organisations that require full on-premises deployment do not use the Chrome extension at all. They run the Docker Compose stack on their own infrastructure, with Ollama providing local model inference, and nothing leaves their network. The Chrome extension is not relevant to their deployment. His briefing document's conflation of these two things reflects a misunderstanding of the architecture, not an exposure of a deficiency in it.
The EU AI Act Misapplication
His briefing document invokes EU AI Act Article 5 as a regulatory basis for the alleged violations.
Article 5 of the EU AI Act defines prohibited AI practices. The prohibitions cover: AI systems that use subliminal or manipulative techniques to influence behaviour against a person's interests; systems that exploit vulnerable groups; social scoring by public authorities; real-time remote biometric surveillance in public spaces; and related categories of high-risk manipulation and covert exploitation. It is, broadly speaking, the article most concerned with AI that behaves in the manner of a Bond villain.
None of these categories apply to marketing claims about enterprise software deployment architecture. Article 5 is not an accuracy standard for AI product descriptions. It is a prohibition on specific categories of harmful AI deployment. Invoking it in the context of a complaint about whether a company ships Docker Compose files is the regulatory equivalent of reporting a parking violation to Interpol. Both organisations are, technically, law enforcement. The similarity ends there.
The marketing accuracy of software capability claims, where they are disputed, falls under consumer protection and advertising standards law. The relevant regulators are advertising standards bodies and trading standards authorities — not AI safety regulators whose mandate covers surveillance systems and psychological manipulation.
His briefing document's regulatory framing is incorrect in its choice of provision and incorrect in its application of that provision to the facts as alleged. This is, at minimum, two errors for the price of one.
The Economics Argument
His briefing document argues that the pricing model — described in the blog as £25 per user per month for a system running seven models — is mathematically impossible for a cloud-hosted deployment, and therefore constitutes fraudulent marketing.
The arithmetic is correct for cloud-hosted inference. It is irrelevant to on-premises deployment. This distinction is doing a great deal of work in the preceding sentence, and it deserves acknowledgement.
When AskDiana deploys on an organisation's own hardware, the organisation provides the compute. Ollama runs the language models locally on whatever GPU or CPU infrastructure the organisation has provisioned. AskDiana does not pay for the inference. The organisation does not pay AskDiana for the inference. The per-user subscription covers the software, the support, and the platform — not the compute.
This is a standard characteristic of on-premises enterprise software. A company running Microsoft SQL Server on their own servers does not pay Microsoft per query. The economics of on-premises deployment are different from the economics of SaaS because the compute responsibility sits with the customer. The blog's claim that seven models at that price point is viable is specifically true of on-premises deployment, and the blog has always been explicit that it is describing on-premises deployment. His briefing document's economics section is, therefore, a rigorous analysis of a scenario that does not apply.
The Escalation and What It Means
The step that distinguishes the most recent emails from the earlier LinkedIn posts is the deliberate contact with a third party — a business contact with whom we have an ongoing commercial relationship — with a formal "case file preview" and a payment deadline attached.
This is the mechanism by which this approach operates. The technical claims are a delivery vehicle for reputational pressure. The goal is not to correct the record. If it were, a response to any of the previous public or private communications — all of which were responded to, factually — would have resolved it. The goal is a payment, conditional on which the distribution to third parties is withheld.
When the AskDiana team were announced as speakers at LOGIN 2026 — Lithuania's largest tech festival — he used the public announcement post to issue a direct threat to our team members, publicly, by name:
We have now established, through independent research, that the same individual has used the same approach against at least three other companies and individuals: a fintech founder in the United States, and two executives at a US energy company. In each case the structure is consistent: an approach under the guise of commercial partnership or commentary, followed by a private payment demand, followed by public posts naming individuals and their employers when the demand is not met, followed by escalating deadline pressure.
The two posts below are from the same individual, directed at Jim Wrathall (lead counsel at New Energy Equity LLC) and Bethany M Owen (an ALLETE executive). Note the consistent structure across both: detailed allegations against a named individual, reference to a public records document, and a Thursday deadline before everything goes public. The deadline, the employer notification, the named individuals — all of it maps precisely onto what was sent to our team members overnight on June 24. At this point the playbook has been used enough times that it is beginning to acquire the quality of a franchise.
We are in contact with others who have been targeted. There is now a documented pattern. This context is relevant to anyone — partner, investor, regulator, or journalist — who receives communication from "Verit Analytics" about AskDiana.
Our Position
The on-premises architecture is real. The docker-compose files exist. The Ollama integration runs locally. The air-gapped capability is what we say it is, and the clients who require it are using it.
The Extensions Marketplace SDK documentation, which his briefing document misrepresents as evidence of cloud-only architecture, is documentation for third-party extension developers — an entirely separate system. Reading the App Store developer guide does not tell you how an iPhone works without an internet connection. A technical briefing document that fails to establish this distinction is not, in the end, a technical document. It is a document with ambitions in that direction.
We will not be making a payment. We will not be entering negotiations. The July 5 deadline has no relevance to our position, which will not change before or after it.
If you received an email from "Verit Analytics" about AskDiana, I would ask you to read this post, read the first rebuttal post, and draw your own conclusions from the pattern of conduct described in both.
The platform works as documented. That is not going to change.
— Tony Larcombe, June 2026
Previous Post
Setting the Record StraightAll Posts
Back to Blog Archive