⚠️
Notice Regarding Targeted Harassment

This article was written in direct response to a coordinated LinkedIn harassment campaign against this blog series. The individual responsible subsequently demanded $25,000 from our company. We consider this extortion. The matter has been reported to the relevant authorities and is now being handled by our legal team.

Setting the Record Straight

AI Work Related

Over the past several weeks, a LinkedIn user identifying himself as a "Senior AI Engineer" has posted a series of comments across this blog series, my personal LinkedIn activity, and at least one unrelated post by a colleague of mine — a live video he was hosting, about which I had posted a three-word comment. The comments allege fabricated clients, nonexistent technology, and regulatory fraud. They were accompanied, privately, by a demand for $25,000.

The matter is now in the hands of the relevant authorities and our legal team. I am not going to address it further in that context here.

What I am going to do is address the technical and factual claims, one by one, because several of them deserve a proper answer — either because they raise legitimate questions that deserve a clear public response, or because they are straightforwardly false and saying nothing would imply they are not.

I will try to be scrupulously fair. Where a criticism is technically valid, I will say so. Where a LinkedIn comment simplified something that the blog stated more precisely, I will acknowledge it. Where a claim is simply incorrect, I will explain why, with reference to the underlying architecture and the documented record.

Let's go through them.

Claim 1: "Response time the same as a single LLM is a mathematical contradiction."

This is a reasonable question from someone who assumes the models run sequentially. They do not.

Genius² runs all models in parallel. You send the query to all N models simultaneously. You wait for the slowest one to return. The total response time is therefore approximately equal to max(individual response times), not the sum of them. This is standard parallel processing, not a novel architectural invention — it is how most distributed systems handle concurrent workloads, and it is well-established in the literature.

The more nuanced version: in practice, response time is slightly higher than a single model call, because you must wait for the consensus calculation after all models return. That calculation is fast — it is statistics, not inference. The end result is that the latency profile is dominated by the slowest model, not multiplied by the count of models. The blog's claim that response time is "the same as a single LLM" is a simplification, but it is not a contradiction. It is an accurate characterisation of user-observable latency.

Claim 2: "You went from concept to production in 30 days — an extraordinary claim."

This one I will address with unusual transparency, because it involves a discrepancy between a LinkedIn comment and the blog itself, and I prefer to acknowledge that directly rather than pretend the inconsistency does not exist.

The blog — which you are currently reading, and which predates the harassment campaign — consistently states 90 days from concept to production, and two months from prototype to production. The Genius² engineering post is titled "Concept to Production in 90 Days." The production deployments post says "prototype to production in two months." These are the considered, written-down numbers.

The LinkedIn comment that was quoted said "30 days." That was a simplification — specifically, a reference to the time from the initial whiteboard session to a working prototype that we could demonstrate to clients. Not concept to production. The full timeline is in the blog, it has always been in the blog, and it was in the blog before any of this started.

If the LinkedIn comment was imprecise, that is fair to note. The blog is the authoritative record.

Claim 3: "Consensus reinforces shared errors. Multiple models agreeing on a hallucinated fact does not make it true."

This is the most technically substantive criticism, and it deserves a proper answer rather than a dismissal.

The criticism is correct in a narrow sense: if you ask the same question to models trained on similar data, you can get correlated errors. If GPT and Claude have both absorbed the same incorrect Wikipedia entry, they may well agree on the incorrect fact. Consensus in that scenario does not help you.

The criticism misses the point of what Genius² actually does, for three reasons.

First, model diversity. Genius²'s production configuration runs models with fundamentally different architectures, training objectives, fine-tuning approaches, and data curation strategies. The on-premises deployment uses Llama, Mistral, and Qwen variants alongside others. These models do not simply share the same training corpus processed through the same pipeline. The correlation in their errors is lower than the criticism implies.

Second, the outlier detection works on disagreement, not just agreement. The consensus engine is not simply counting votes. It identifies where models diverge — and divergence is itself a signal. When models disagree strongly on a factual claim, Genius² flags it for lower confidence or human review rather than presenting an answer. The system is designed to surface uncertainty, not paper over it.

Third, the statistical argument still holds for independent hallucination. The blog's engineering post makes a specific claim: that truly independent hallucinations — models inventing facts that are not in any training data — are exponentially unlikely to converge. If one model has a 15% chance of hallucinating a specific drug compound's properties, the probability of eight independent models independently hallucinating the same properties is vanishingly small. This does not address correlated errors from shared training data, and the blog does not claim it does. It addresses independent confabulation, which is the most dangerous failure mode in high-stakes environments.

The blog's claim is "below 2% hallucination rate against an industry average of 10–15%." Not zero. The opening post of this series used the word "eliminates" in a context that was intended to convey "makes effectively extinct in practice" — not "produces a mathematical guarantee of zero errors." That is a distinction worth making explicit, and I am making it now.

Claim 4: "API calls route through app.askdiana.ai, exposing LLM routes."

This is false, and I can be precise about why.

app is a reserved subdomain in AskDiana's multi-tenant architecture. It is explicitly listed in the system's reserved subdomain list alongside www, api, mail, and others. A request to app.askdiana.ai does not resolve to a tenant. It sets the system into a main-domain request state with no tenant context. All API endpoints that do anything useful require a valid JSON Web Token. Without that token, every endpoint returns 401.

There are no exposed LLM routes on app.askdiana.ai. The claim appears to have been constructed from a misreading of URL patterns in browser developer tools, which would show the API base URL but would not reveal the tenant resolution logic sitting behind it.

Claim 5: "There is no on-prem infrastructure. No air-gapped deployment. No sovereign capability."

This is also false.

AskDiana deploys as a Docker Compose stack. The components are: a Flask/Gunicorn backend, a Next.js frontend, MySQL, Qdrant (vector database), and Neo4j (knowledge graph). All of these run on your hardware. None of them require an external connection to function.

The language model layer uses Ollama, which runs open-weight models locally. The default production model is Qwen 3.5 9B. The embedding model is Snowflake Arctic Embed 2. Neither makes external API calls. The reranker is a local FlashRank instance running ms-marco-TinyBERT. The OCR service has a configurable endpoint that can point to a local instance.

The result is a system in which, if you choose, no query leaves your network. Not "encrypted in transit." Not "anonymised before transmission." Nothing transmitted at all. This is what the blog means by air-gapped: the system is architecturally capable of it, and several clients run it that way. The deployment post describes a security-sector client whose requirement was "zero external data transmission" and explains how that requirement was met.

Cloud-based model providers (OpenAI, Google, Anthropic) are supported as options. They are not required. The choice belongs to the deploying organisation.

Claim 6: "The pharmaceutical and national security deployments do not exist. The clients are fabricated."

I cannot name the clients. This is standard practice in enterprise software, where every client agreement includes confidentiality provisions, and where regulated industries in particular — pharmaceuticals, defence, financial services — would consider their technology stack a matter of competitive and security sensitivity. The inability to name a client publicly is not evidence that the client does not exist. It is evidence that the client has a normal commercial relationship with a supplier.

What I can say: the clients exist, the deployments are live, and the people who built and operate them know who they are. The claim that they are fabricated is incorrect.

The further claim that pharmaceutical deployments "require SOC2 and ISO certifications, independent security audits, months of due diligence" before any deployment can occur conflates enterprise-wide procurement with pilot and proof-of-concept deployments. Pharmaceutical companies run technology pilots regularly. Many of them have internal innovation teams whose entire function is to evaluate technology on a faster timeline than the main procurement process. The blog's deployment post describes precisely the kind of early production deployment — with elevated confidence thresholds, full audit trails, and human review for below-threshold results — that a regulated environment would accept as a compliant pilot. It does not describe a company-wide deployment approved by a compliance committee after eighteen months of review. It describes what it says it describes.

Claim 7: "Your team knows you have been lying. Sri knows. Emil knows. Mohamed knows. Pranav knows."

I am going to be direct about this one.

Naming individual team members in a public post — people who have no involvement in any commercial dispute, who did not write these blog posts, and who are identifiable human beings with reputations and employment situations — is not a technical criticism. It is an intimidation tactic directed at people who are not party to anything being discussed.

For the record: the team members named are aware of this campaign. They are not troubled by it. They know what they built, they know the clients they built it for, and they know the claims in these posts are accurate. Their knowledge of the technology is, if anything, more detailed than mine, since I write the blog posts and they write the code.

I will not be addressing this particular claim further. It belongs in a legal document, not a blog post.

Context: A Pattern Worth Noting

In the course of researching this situation, I came across a post by the same individual directed at a third party — a lawyer and executive at a US energy company. The structure was identical: a commercial dispute, an allegation of non-payment, a public post naming the individual and their employer, and a deadline. "I am giving Jim until Thursday to make this right before I post the full timeline and documents publicly. His boss at ALLETE will be notified."

I am not in a position to assess the merits of that separate dispute. What I can observe is that the approach — public accusation, named individuals, employer notification, deadline — is consistent with what has been directed at us. This is not, apparently, a response to something specific about our technology. It appears to be a method.

I am noting this because it is relevant context for anyone evaluating the credibility of the claims made about us.

Where This Leaves Things

The technical claims in this series are accurate. The deployments are real. The architecture works as described. The one area where a LinkedIn comment simplified something the blog stated with more precision — the timeline — I have acknowledged here, directly and without qualification.

The $25,000 demand has been declined. The matter is with the relevant authorities. The blog series will remain published, with the harassment notices that are now on each post, because removing accurate content in response to a financial demand would be the wrong thing to do and would set a precedent I have no interest in setting.

If you have genuine technical questions about Genius² or AskDiana — how the consensus works, how the on-premises deployment is structured, how the hallucination rate is measured — I remain happy to discuss them. The whole point of this series was to be transparent about the architecture, not to obscure it behind marketing language. That invitation stands.

What does not stand is the suggestion that we should pay someone to make public posts stop. That is not a commercial conversation. That is something else entirely, and it is being handled accordingly.

— Tony Larcombe, June 2026