Insight · Technology Assurance

The Kill Switch — how HRA runs its AI stack in production

2026-09-06. Written by Harun for HRA's board, clients, and audit-committee counterparts. This is not marketing. It documents the specific operational controls we run over our own AI systems, so that when a client asks "how do you know the AI told you the truth?" we have an answer that stands up to auditor scrutiny.

What this whitepaper is (and is not)

This is a description of production controls we operate over HRA's own AI-first stack — the software running behind harunraaj.com, pvtltd.co, makeitlegit.in, and the internal admin platform. It is not a philosophy paper. Every section names a specific control, the technology it runs on, and the human authority that owns it.

It exists because we are asking clients to trust our AI Governance Audit report. That trust has to be underwritten by evidence that we run the controls we recommend. This document is that evidence.

Six controls

1. Anti-hallucination gate at ingest

Every regulatory update ingested into HRA's knowledge base passes through an evidence gate. The ingestion pipeline extracts a claim (e.g., "TDS on partner remuneration under s.194T from 1 April 2025") and requires that the source document contain a matching literal string. If the source is a paraphrase from a secondary site, the row is flagged for human review before it enters the corpus. This is enforced in code, not policy. Bypass rate for 2026 YTD: 0.

2. Citation guard at output

Every line of regulatory content generated by our AI pipelines must carry a citation to a specific section, rule, notification, or circular in our verified corpus. A pipeline that fails to attach a citation to a claim is halted at the pre-publish stage. Content that has been re-verified against the amended primary source is marked with a verified_on date; content whose source is older than 90 days regenerates the verification pass.

3. Provenance ledger

Our knowledge base uses a graph memory layer (Cognee, running locally against Ollama for privacy) that stores every fact with its source, retrieval path, and verification state. When a fact is used to generate output, the graph node is referenced; when the source changes, the node is invalidated and downstream content is rechecked. This is the same architecture we recommend to clients under Domain 5 of the AI Governance Audit checklist.

4. Approval gates before publish

No AI-generated regulatory content — blog post, social post, client advisory, form draft — publishes without a human approval. Six regulatory-domain partners (GST, Direct Tax, Corporate Law, FEMA, Regulatory & Labour, Capital Markets) each hold approval authority for their domain. Approval is a click, logged with the approver's ID and timestamp. The queue is visible at /admin/knowledge-engine.

5. Kill switches — per automation, not global

Every cron job, every scheduled agent, every automated ingestion pipeline has its own kill switch — a database row (app_settings.<domain>_kill_switch) that halts the automation without a code deploy. This lets us stop a specific pipeline (say, the growth-hack ingestor) without stopping the KB partner crons. The kill switch is testable — we assert it in unit tests — and audited annually.

Who can flip it: Harun, or any partner with admin credentials. Escalation: documented in the incident playbook.

6. Independent review — the loop that closes

Every content piece that ships to a client-facing surface is subject to a delayed independent review. HRA subscribes to Claude (Anthropic) as a second opinion loop and Codex as a third — running the same regulatory question through a different model family and comparing. Divergence is investigated. Not for consensus — for disagreement. The interesting cases are the ones where the models diverge.

What this whitepaper deliberately does not do

1. It does not name the specific ML models we use for classification, extraction, or generation. Model choice changes; the controls above hold across model changes.
2. It does not describe the internal HR / operational side of the firm (staffing, incentives) — this is a control document.
3. It does not claim zero errors. The controls catch a class of error (hallucination, uncited claim, unverified regulatory drift). Different classes need different controls.

Verification path for clients + auditors

1. Every control above is testable. The tests live in the HRA codebase.
2. We are willing to demonstrate any control live during a scoping call.
3. We are willing to share the anonymised audit trail for any period.
4. For audit-committee-level clients, we host an annual "kill switch dry run" — a scheduled test where we flip a switch, observe the automation halt, and file a report.

Why publish this

Two reasons.

First, because we sell AI Governance Audit to clients whose boards want to see that the auditor operates the controls being audited. This document is the evidence.

Second, because Indian AI regulation is going to formalise most of these controls within the next 24 months. Publishing early signals what "mature" looks like, sets the benchmark our peers will compete against, and gives clients something to point to when they answer "who audits your AI?" questions from their own regulators.