DEV Community: Palash Bagchi

Beyond Left vs. Right: Engineering Reproducible Detection of Media Bias and Propaganda

Palash Bagchi — Thu, 09 Jul 2026 01:24:10 +0000

We have spent a decade building machines that generate persuasive text and almost no time building machines that audit it. That asymmetry is starting to hurt. False news spreads "farther, faster, deeper, and more broadly" than the truth — Vosoughi, Roy, and Aral demonstrated this at scale across roughly 126,000 stories on Twitter, and the effect was driven by humans, not bots [1]. If the demand side of manipulation is human psychology, then the supply side is now industrialized by language models. The tooling that helps a reader think clearly has to be at least as sophisticated as the tooling that helps a writer persuade.

This essay is about how to build that auditing tool: a forensic media analyzer that treats an article the way a lab treats a tissue sample — measuring what is structurally present rather than voting on whether it feels biased. I'll cover the science it rests on, the engineering problems that make it genuinely hard (LLM non-determinism chief among them), a practical build guide, and an honest account of the limitations. Some of the design decisions come from work we've done on Rhetoric Audit, a browser-based forensic media evaluator; most of the ideas are older than any of us and belong to rhetoric, argumentation theory, and cognitive science.

The problem with "bias detectors"
Most bias tools answer the wrong question. They place an outlet or an article on a single left–right line and call it a day. That axis is politically legible but analytically hollow. It flattens a dozen independent phenomena — emotional loading, source quality, logical structure, omission, framing — into one number that tells you almost nothing about how a piece works on a reader.

Worse, a left–right label invites the reader to do the one thing forensic analysis is supposed to prevent: agree or disagree based on tribe. Wardle and Derakhshan, in their influential Council of Europe report on "information disorder," argue for separating mis-information (false, no intent to harm), dis-information (false, intentional), and mal-information (true, weaponized) precisely because lumping them together destroys our ability to respond appropriately [2]. A single spectrum can't hold those distinctions. Neither can it distinguish a factually careful opinion column from a factually reckless one that happens to share its politics.

The reframe is simple to state and hard to implement: score structure, not stance. Two articles can reach opposite conclusions and be rhetorically identical; two articles can reach the same conclusion with wildly different levels of manipulation. A forensic analyzer should be able to say "this piece leans heavily on fear appeals, omits the strongest counterargument, and contains three instances of the strawman fallacy" without ever telling you whether it's right.

The science underneath
The intellectual scaffolding is surprisingly old.

Rhetoric. Aristotle's Rhetoric gave us the three modes of persuasion — ethos (credibility), pathos (emotion), and logos (logic) — and they remain a shockingly good decomposition of how a text tries to move you [3]. A forensic system can score every passage on the mix of these three appeals and immediately surface the pieces that lean on feeling where they should be leaning on evidence.

Framing. Robert Entman's canonical definition still governs the field: to frame is "to select some aspects of a perceived reality and make them more salient" so as to promote a particular interpretation [4]. Framing is often invisible because it operates through omission — what the piece declines to mention. Detecting "strategic silence" is therefore not a nice-to-have; it's central. The hardest manipulation to catch is the argument that was never made.

Propaganda techniques. The most directly relevant computational work is Da San Martino and colleagues' fine-grained propaganda detection, which defined a taxonomy of specific techniques — loaded language, name-calling, appeal to fear, flag-waving, whataboutism, and more — annotated at the span level in news articles, and later formalized as SemEval-2020 Task 11 [5]. This is the key methodological move: propaganda is not a property of a document, it's a property of spans of text, and it can be enumerated.

Fallacies. Douglas Walton's decades of work on argumentation reframed informal fallacies not as static errors but as argumentation schemes misused in context [6]. That matters for tooling, because it means fallacy detection has to be evidence-anchored: you can't flag "ad hominem" in the abstract, you flag it at the quote that commits it.

Emotion. Robert Plutchik's wheel of eight primary emotions — joy, trust, fear, surprise, sadness, disgust, anger, anticipation — gives a compact, defensible vocabulary for measuring affective loading paragraph by paragraph [7]. It's more useful than a naïve positive/negative sentiment score because manipulation lives in the specific emotion being provoked.

Why this works on people. The reason any of this matters is dual-process cognition. Kahneman's System 1 / System 2 distinction explains why emotionally loaded, fluent, repetition-heavy content bypasses deliberation [8]. And crucially, Pennycook and Rand's research suggests people fall for misinformation largely because they fail to stop and think, not because they're hopelessly partisan — falling for fake news correlates with lower analytic thinking more than with ideology [9]. That's an optimistic finding for tool-builders: if the failure mode is inattention, then a tool that makes manipulation visible — that forces a System 2 pause — can actually help.

Put these together and you get a measurement model: decompose a text into spans, score each span on appeals (ethos/pathos/logos), emotion (Plutchik), and technique (a propaganda/fallacy taxonomy), anchor every judgment to an exact quote, and roll it up into document-level indices. You can even layer in a cognitive-complexity axis — Norman Webb's Depth of Knowledge framework, borrowed from education, is a reasonable proxy for whether a piece reasons or merely asserts [10].

The engineering problem nobody warns you about
Here's where it stops being a literature review and starts being software. If you naively wire an LLM to this taxonomy, you will ship something that gives a different answer every time you run it. For a tool whose entire value proposition is credibility, that's fatal.

Large language models sample tokens stochastically. Even at temperature zero, floating-point non-associativity across hardware and batching means outputs are not bit-for-bit stable, and any temperature above zero makes the variance visible to users. A "propaganda index" that reads 71 on Monday and 78 on Tuesday for the same article is not a measurement; it's a mood. The generative-AI reflex — "just prompt it and trust the output" — collides head-on with the requirements of an analytical instrument.

There's a second, deeper hazard: hallucination. The survey literature is blunt that generative models produce fluent, confident, unsupported claims as a matter of course [11]. An analyzer that invents a fallacy that isn't in the text is worse than useless — it's itself a source of misinformation.

Four engineering commitments address this. They're the difference between a demo and an instrument.

Span-anchoring kills hallucination at the root. Every score must trace back to exact words — ideally to character offsets into the normalized source text, validated after the fact so that text.slice(start, end) actually equals the quoted span. If the model claims a fallacy but can't point to the substring that commits it, the claim is dropped. This single constraint converts "the model thinks this is manipulative" into "here are the seventeen characters that are, and here's why." It also makes the output auditable, which is the whole game.
Deterministic aggregation separates the fuzzy step from the exact step. Use the LLM for what it's good at — identifying and classifying spans — and then compute all document-level numbers with plain, deterministic code: severity tables, weighted sums, fixed formulas. The manipulation index isn't asked of the model; it's derived from the spans by an algorithm that returns the same number every time. The stochastic component is quarantined to perception; the arithmetic is reproducible by construction.
Calibration corrects known model failure modes. No frontier model is neutral about political content; each has systematic tics. The pragmatic answer is a post-processing layer of transparent, rule-based overrides for well-characterized errors, applied deterministically and logged. This is unglamorous and occasionally derided, but it's honest engineering: you are encoding, in reviewable code, the specific ways your model is wrong, rather than pretending it isn't.
Grounding checks factual claims against the outside world. Emotional and structural analysis is intrinsic to the text, but factual claims can be cross-referenced. Extracting the central claims and verifying them against fact-check corpora and knowledge bases — while being explicit about what could and couldn't be verified — closes the loop between "how is this argued" and "is it true."

Finally, stamp every result with provenance: the prompt hash, the model version, the severity-table hash, the pipeline version. Reproducibility in science means someone else can rerun your method and get your result; the same standard should apply to an automated analysis. If you can't tell a skeptical reader exactly how a score was produced, they're right not to trust it.

How to build one
A concrete, framework-agnostic recipe. You can implement this with any capable model and a few hundred lines of glue.

Step 1 — Normalize and chunk. Strip boilerplate, normalize whitespace, and split the article into paragraphs and overlapping windows. Keep a stable mapping from every chunk back to character offsets in the normalized text; you'll need it for span validation later. Cap the analyzed window to a fixed size and tell the user when you truncate — a partial analysis silently presented as complete is its own small deception.

Step 2 — Define a strict output schema. Before you touch a model, write the schema: spans (with start, end, quote, technique, appeal, confidence), per-paragraph emotion vectors, extracted claims, and the fixed set of document-level fields. Validate every model response against it and reject anything that doesn't conform. A schema is your contract; it's also your first line of defense against hallucination and drift.

Step 3 — Prompt for classification, not judgment. Ask the model to locate and label spans against your taxonomy, quoting exact text, and to abstain when uncertain. Do not ask it for the final indices. Pin sampling as tightly as your provider allows — low temperature, low top-p, a fixed seed — knowing this reduces but does not eliminate variance.

Step 4 — Validate spans. For each returned span, confirm the quote actually appears at the claimed offsets. Discard the rest. This is the step most teams skip and the one that most separates a toy from an instrument.

Step 5 — Aggregate deterministically. Feed validated spans into fixed formulas: map techniques to severity weights, combine with confidence and coverage, and compute your manipulation index, evidence-validity score, and emotion arc in ordinary code. Same input, same output, forever.

Step 6 — Ground the claims. Extract the load-bearing factual claims and check them against external sources, recording verified / disputed / unverifiable status and never upgrading "unverifiable" to "false."

Step 7 — Attach provenance and surface uncertainty. Return the model version, prompt hash, and any limitations (truncation, low grounding coverage, failed chunks) alongside the scores. Show confidence, not just verdicts.

Step 8 — Evaluate against a labeled corpus. Build or borrow a benchmark with human annotations across genres — hard news, opinion, propaganda, satire, PR — and track technique-level F1, not just an aggregate. SemEval-2020 Task 11 is a natural starting point for the propaganda side [5]. Regression-test every prompt or model change against it; an "improvement" that drops your satire recall is a regression.

This is the architecture behind Rhetoric Audit's analysis pipeline, and the pattern generalizes well beyond media: contract review, research-integrity screening, and moderation tooling all benefit from the same "fuzzy perception, deterministic aggregation, mandatory provenance" spine.

What this approach can't do — and why saying so matters
Forensic analysis measures rhetoric, not righteousness. A perfectly reasoned argument for a false conclusion will score well on structure; a clumsy argument for a true one will score badly. That's a feature — the tool deliberately refuses to adjudicate truth from style — but it means the output is an input to judgment, not a substitute for it.

Three honest caveats. First, taxonomies are lenses, not laws; reasonable annotators disagree about whether a given sentence is "loaded language" or just vivid writing, and inter-annotator agreement on propaganda techniques is imperfect even among experts [5]. Second, satire and strong opinion writing use manipulation techniques intentionally and legitimately, so any system needs genre-awareness or it will libel The Onion. Third, grounding is only as good as the corpora behind it; "unverifiable" is common and must never masquerade as "refuted."

State these plainly in your product. A forensic tool that overclaims becomes exactly the thing it was built to detect.

FAQ
Is this just sentiment analysis with extra steps?
No. Sentiment analysis returns a polarity; forensic analysis returns a structured decomposition — which techniques, at which spans, with which appeals and emotions, plus deterministic document indices and provenance. Polarity tells you a text is negative; forensic analysis tells you it's negative because of an appeal-to-fear in paragraph three that omits the base rate.

Doesn't using an LLM make it inherently unreliable?
Only if you let the LLM produce the final numbers. The design deliberately confines the model to perception (finding and labeling quoted spans) and computes all scores with deterministic code. Combined with span validation and provenance stamping, the same article yields the same analysis — the reproducibility comes from the architecture, not from the model.

How do you avoid political bias in the tool itself?
By measuring structure rather than stance, by anchoring every judgment to a quote you can inspect, and by applying model-calibration corrections transparently and in reviewable code. You should be able to disagree with a score by reading the exact span it cites — that auditability is the accountability mechanism.

Can it detect AI-generated propaganda?
It detects rhetorical technique regardless of author. Whether a fear appeal was written by a human columnist or a language model is irrelevant to whether it's a fear appeal. That authorship-agnosticism is increasingly valuable as synthetic content scales.

Is there real research behind this, or is it vibes?
The measurement model draws on peer-reviewed work in rhetoric, framing theory, computational propaganda detection, argumentation theory, and cognitive science — several of which are cited below. The engineering draws on the hallucination and evaluation literature. It is emphatically not vibes, though like any measurement instrument it encodes choices you're free to contest.

Where can I try it?
Rhetoric Audit runs this pipeline in the browser: rhetoricaudit.com. More usefully for this audience, the pattern — fuzzy perception, deterministic aggregation, mandatory provenance — is yours to reimplement for any domain where you need trustworthy analysis on top of an untrustworthy generator.

Closing
The uncomfortable truth of the current moment is that persuasion has been automated and comprehension has not. Closing that gap is not primarily a modeling problem; it's an engineering-discipline problem. The models are good enough. What's scarce is the willingness to constrain them — to demand quotes, to compute scores deterministically, to publish provenance, and to say clearly what the tool cannot do. Build that discipline in, and you get an instrument people can actually trust. Skip it, and you've built one more confident voice in a room that already has too many.

References
Vosoughi, S., Roy, D., & Aral, S. (2018). The spread of true and false news online. Science, 359(6380), 1146–1151. https://doi.org/10.1126/science.aap9559
Wardle, C., & Derakhshan, H. (2017). Information Disorder: Toward an interdisciplinary framework for research and policy making. Council of Europe.
Aristotle. (c. 4th century BCE). Rhetoric (W. Rhys Roberts, Trans.).
Entman, R. M. (1993). Framing: Toward clarification of a fractured paradigm. Journal of Communication, 43(4), 51–58. https://doi.org/10.1111/j.1460-2466.1993.tb01304.x
Da San Martino, G., Yu, S., Barrón-Cedeño, A., Petrov, R., & Nakov, P. (2019). Fine-Grained Analysis of Propaganda in News Articles. EMNLP-IJCNLP 2019. arXiv:1910.02517. (See also SemEval-2020 Task 11.)
Walton, D. (2008). Informal Logic: A Pragmatic Approach (2nd ed.). Cambridge University Press.
Plutchik, R. (1980). A general psychoevolutionary theory of emotion. In Emotion: Theory, Research, and Experience (Vol. 1). Academic Press.
Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
Pennycook, G., & Rand, D. G. (2021). The Psychology of Fake News. Trends in Cognitive Sciences, 25(5), 388–402. https://doi.org/10.1016/j.tics.2021.02.007
Webb, N. L. (2002). Depth-of-Knowledge Levels for Four Content Areas. Wisconsin Center for Education Research.
Ji, Z., et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12). arXiv:2202.03629

How do you prove which AI agent did what? We open-sourced our answer

Palash Bagchi — Wed, 08 Jul 2026 04:17:56 +0000

AI agents are starting to move money and hit production APIs, but almost none of them can answer the one question a regulator — or your own risk team — will eventually ask: which agent did this, and was it allowed to? We built Kakunin to fix that: every agent gets an X.509 certificate (issued via AWS KMS, keys never leave the HSM), its behavior is risk-scored in real time, and its certificate auto-revokes in under 60 seconds when it goes rogue. Today we open-sourced the whole thing — the platform under AGPL-3.0, the SDKs under Apache-2.0, every package provenance-signed. Here's what's open, what stays hosted, and why a trust anchor you can fork isn't a trust anchor.

What Kakunin does

Every agent gets an X.509 certificate, issued through AWS KMS so the private key never leaves the HSM. The certificate encodes the agent's permitted scope — what it's allowed to do, up to what limits. As the agent acts, it streams behavioral events to Kakunin, which scores each one in real time against a rolling 30-day baseline. When risk crosses a threshold, the certificate is auto-revoked in under 60 seconds — and anyone, anywhere, can verify a certificate's status keylessly, without an account.

Issuance, behavioral monitoring, auto-revocation, and regulator-ready compliance exports — the full lifecycle, built for MiCA Article 70 and the EU AI Act.

What's open

Everything you run:

The platform — kakunin-core, the Next.js application, the CA integration, the risk engine, the audit pipeline — is AGPL-3.0. You can read exactly how risk is scored and how revocation decisions are made. For a compliance product, that transparency isn't a giveaway; it's the entire pitch. No black box gets to decide whether your agent is trustworthy.
The SDKs and integrations — TypeScript, Python, and drop-in tools for LangChain, Mastra, the Vercel AI SDK, MCP, LlamaIndex, CrewAI, and more — are Apache-2.0. Build on them with no copyleft obligation.
Every package publishes with cryptographic provenance (npm) and attestations (PyPI), each traceable to a public commit and CI run. You can verify the supply chain, not just trust it.

Six public repositories, seven packages on npm and PyPI.

What's hosted, and why we're telling you plainly

The canonical certificate authority and the public verification endpoint run as a hosted service. We could pretend otherwise; we won't.

A trust anchor you can fork is not a trust anchor. The value of a Kakunin certificate is that any counterparty can verify it against one authority — keylessly, without asking you. A thousand self-hosted CAs would mean a thousand roots nobody recognizes. Verification stays free and public for everyone precisely because issuance is centralized. Key custody (KMS-backed, never-leaves-the-HSM) and independent audit-log custody are what make the evidence admissible in the first place.

So: run every line of the code. Verify against the canonical CA. We wrote up the exact split, feature by feature, at kakunin.ai/open-source.

Why AGPL

We chose AGPL-3.0 for the platform deliberately. It's OSI-approved open source — you can read it, run it, modify it. Its copyleft means anyone who offers a modified Kakunin as a network service has to share their changes, which keeps the project honest. And it keeps us eligible for the open-source ecosystem — grants, sponsorships, the commons — in a way a source-available license wouldn't. The SDKs stay Apache-2.0 so nothing you integrate carries an obligation.

Try it in 60 seconds

npm install @kakunin/sdk

import { Kakunin } from '@kakunin/sdk';
const kkn = new Kakunin({ apiKey: process.env.KAKUNIN_API_KEY! });

const agent = await kkn.agents.create({ name: 'my-agent', model_hash: await Kakunin.computeModelHash('gpt-4o') });
const cert  = await kkn.agents.certify(agent.id);
const check = await kkn.events.ingest({ agentId: agent.id, actionType: 'transaction_initiated', details: { amount: 840 } });
console.log(check.risk_band); // 'low' | 'medium' | 'high'

Or open the sandbox — no signup, 100 free test certificates a day, and a live demo where you watch an agent go rogue and its certificate revoke itself.

Where this is going

It's early and we'll say so: baselines need history to be meaningful, the hosted CA is single-region today, and the roadmap is public. If you're building agents that do things that matter — or you just have opinions about how machine identity and open-core should work — star kakunin-core, read the code, and tell us where we're wrong.

The Anatomy of a Machine's Mind - Decoding AEO, GEO

Palash Bagchi — Sat, 06 Jun 2026 07:10:53 +0000

We are moving away from traditional "10 blue links" (where Google ranks a document) to a semantic synthesis model (where Google extracts the factual payload and generates the answer directly via AI Overviews or Gemini).

To architect a dashboard for AEO and GEO, we must stop looking at keyword density and start looking at Entity Salience and RAG (Retrieval-Augmented Generation) compatibility.

Here is the architectural breakdown of the Google APIs required to track, test, and optimize for the Generative Search era that i used while building nqzai conversational GTM platform.

1. The Entity Truth Layer: Knowledge Graph Search API (AEO)

Answer Engine Optimization relies heavily on Google's Knowledge Graph. If Google doesn't recognize your brand, product, or author as a definitive "Entity," you will not appear in Knowledge Panels, nor will an LLM trust your brand as a source of truth.

The API: Google Knowledge Graph Search API

This API lets you query Google’s exact semantic database to see how it mathematically maps entities (people, places, organizations).

The Data Points:
resultScore: The algorithmic confidence Google has in the entity match.
@id (Machine-Readable Entity ID or MREID): The unique identifier (e.g., /m/0k8z) Google assigns to a recognized entity.
description / detailedDescription: The exact factual payload Google associates with that entity.
The Enrichment Play (Brand Authority): You can programmatically query your brand name or executive team names monthly. If your resultScore is increasing, your AEO efforts (digital PR, schema markup, Wikipedia/Wikidata editing) are working. If your brand returns no MREID, you are invisible to the Answer Engine.

This is the exact right place to start. If you do not understand how Google mathematically defines reality, all downstream Answer Engine Optimization (AEO) efforts are essentially guessing.

When we talk about the Google Knowledge Graph Search API, we are no longer dealing with web pages, URLs, or HTML. We are dealing with Nodes (Entities) and Edges (Relationships).

Here is the microscopic breakdown of how Google categorizes, measures, and scores reality.

1. What are "People, Places, and Organizations"?

In traditional SEO, "Kakunin" is just a string of letters (a keyword). In the Knowledge Graph, an Entity is a fundamental unit of knowledge—a specific, identifiable thing.

Google does not use arbitrary labels to define these; it strictly adheres to the Schema.org vocabulary.

People: Mapped as schema.org/Person (e.g., Taylor Swift, or a company's CEO).
Organizations: Mapped as schema.org/Organization or sub-types like schema.org/LocalBusiness or schema.org/Corporation (e.g., Google, Kakunin).
Places: Mapped as schema.org/Place (e.g., Ranchi, Eiffel Tower).

The Practical Benchmark: When does a brand cross the threshold from being a "keyword" on a webpage to a recognized "Entity" in the Knowledge Graph?
The benchmark is reconciliation. Google’s Entity Reconciliation engine constantly scrapes the web. When it finds enough corroborating "Semantic Triples" (Subject-Predicate-Object data points, like Kakunin -> is a -> SoftwarePlatform), it clusters that data together. You have practically achieved Entity status the moment Google mints a unique machine identifier for you in its database.

2. Expanding the 3 Core Data Points

When you query the Knowledge Graph API, it returns a JSON-LD payload. Here is what those specific data points actually mean and the signals that drive them.

A. `@id` (The Machine-Readable Entity ID or MREID)

This is the canonical database key for the entity. It is the most important data point in AEO.

What it looks like: It typically starts with kg:/m/ (e.g., /m/0dl567) or kg:/g/.
The Heritage: The /m/ prefix stands for "Machine ID" and is a legacy identifier inherited from Freebase, the massive open-source database Google acquired to build its Knowledge Graph. Newer entities created directly by Google's ML systems often get a /g/ prefix.
The Signal: You cannot manually edit or request this ID. It is minted automatically when Google's reconciliation algorithms determine that enough structured data (Schema.org), Wikipedia mentions, and high-authority backlinks all point to the exact same distinct concept.

B. `detailedDescription` (The Factual Payload)

This is the text that an Answer Engine (like Gemini or AI Overviews) will read as the absolute, verified truth about your entity.

How it is measured: Google does not write this text. It extracts it from what it considers "Tier 1 Trust Data Sources."
The Signals: The overwhelming majority of detailed descriptions are pulled verbatim from Wikipedia or Wikidata.org. For organizations, it frequently pulls from licensed databases like Crunchbase or Bloomberg. If you do not have a presence in these highly moderated, public data repositories, your detailedDescription will be completely empty, giving Answer Engines zero factual payload to pull from.

C. `resultScore` (The Salience & Probability Metric)

This is not a static "authority score" like Domain Rating (DR). It is a dynamic numerical value that describes how perfectly an entity matches the search query context.

How it is measured: The score ranges from a few decimals to tens of thousands. For example, if you query "Brad Pitt", the American actor might return a resultScore of 30,000, while a lesser-known Australian boxer named Brad Pitt might return a score of 200.
The Signals that drive the math:
Search Volume (Entity Popularity): High aggregate search volume for the entity name increases its baseline score.
Graph Density (Backlinks for Entities): Just like webpages have backlinks, entities have graph links. If Google maps that the entity "Bill Gates" is connected to "Microsoft", "Melinda Gates", and "Harvard", his graph density is massive, spiking his resultScore.
Co-occurrence: If your organization's name frequently appears in the same paragraph as established industry terms (e.g., Kakunin appearing next to "MiCA regulation" and "AI Compliance" across high-authority news sites), the ML engine raises your probability score for those semantic queries.

Simulating the Knowledge Graph

To visualize how these signals compound to push a brand from a mere "keyword" to a fully reconciled Entity with a high resultScore, I have generated a Knowledge Graph Entity API Simulator below. Adjust the signals to see how the JSON-LD payload mutates in real-time.

{ "@context": { "@vocab": "http://schema.org/", "goog": "http://schema.googleapis.com/", "detailedDescription": "goog:detailedDescription", "resultScore": "goog:resultScore" }, "@type": "EntitySearchResult", "result": { "@id": "kg:/g/11bsled", "name": "Kakunin", "@type": [ "Organization" ], "detailedDescription": { "articleBody": "Kakunin is an established organization recognized by global semantic authorities.", "url": "https://en.wikipedia.org/wiki/Kakunin", "license": "https://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License" } }, "resultScore": 74375 }

2. The Semantic Vector Layer: Google Cloud Natural Language API (GEO)

Generative Engine Optimization (GEO) requires your content to be easily parsed by Large Language Models (LLMs). LLMs do not read "keywords"; they calculate the mathematical relationship between words.

To optimize for AI Overviews (formerly SGE), you must feed your content into the same Natural Language Processing (NLP) engines Google uses to train its models.

The API: Google Cloud Natural Language API

This API exposes Google's internal machine learning models for syntax analysis, entity extraction, and sentiment analysis.

The Data Points:
entities: What nouns/concepts Google extracts from your text.
salience: A critical metric (ranging from 0.0 to 1.0) indicating the importance or centrality of an entity to the entire document text.
sentiment.score & sentiment.magnitude: How positive, negative, or neutral the text is.
The Enrichment Play (The Salience Audit): Before publishing a high-value SaaS landing page, pass the text through the NLP API. If your target product feature has a salience score of 0.12, but a competitor's integration mentioned off-hand has a score of 0.85, the LLM will completely misunderstand the core topic of your page. You must rewrite the syntax—using clearer subject-verb-object structures—until your core product hits a salience score above 0.70.

If Answer Engine Optimization (AEO) is about getting Google to recognize your existence as a factual "Entity" (via the Knowledge Graph), Generative Engine Optimization (GEO) is about controlling how an LLM reads, fragments, and scores your content.

Large Language Models (like Gemini or the models powering AI Overviews) do not read pages top-to-bottom like humans, nor do they count keyword frequencies like legacy Googlebot. They convert text into Semantic Vectors—lists of numbers representing the mathematical distance between concepts.

To master the GEO layer using the Google Cloud Natural Language API, there are three critical sub-engines you must understand, as they directly dictate whether your content is "RAG-friendly" (Retrieval-Augmented Generation).

1. Syntax Analysis (The Dependency Tree)

In traditional SEO, you could put the keyword "MiCA AI Compliance" at the top of the page, write 500 words of fluff, and still rank. In GEO, that will completely fail.

The Natural Language API features a analyzeSyntax method that generates a Dependency Parse Tree. It breaks every sentence into tokens (words) and maps the exact grammatical relationship between them (e.g., this noun is the subject, this verb is the root action, this adjective modifies the object).

How it works: It maps the "distance" between the Subject, the Verb, and the Object.
The GEO Benchmark (Subject-Verb Distance): LLMs rely on "attention mechanisms." If you write convoluted sentences using the passive voice (e.g., "Compliance with MiCA regulations, which are becoming increasingly strict across the European Union, is easily handled by Kakunin"), the mathematical distance between the entity ("Kakunin") and the action ("handles MiCA compliance") is too wide. The dependency tree breaks, and the LLM will drop the fact.
The Fix: You must write in dense, active, Subject-Verb-Object structures. ("Kakunin automates MiCA AI compliance.") This creates a tight dependency tree, resulting in a dense semantic vector that the LLM can easily extract and cite.

2. Entity Sentiment Analysis (Contextual Bias)

We briefly touched on salience (how important a word is to the page), but the API also exposes Entity Sentiment Analysis. This does not just measure if an article is generally "happy" or "sad"; it measures the exact emotional polarity attached to a specific entity within the text.

The Data Points:
score: Ranges from -1.0 (extremely negative) to 1.0 (extremely positive).
magnitude: Indicates the sheer volume of emotion, regardless of whether it's positive or negative (ranging from 0.0 to +inf).
The GEO Application (Competitor Conquesting): When users ask Gemini, "Which is better for AI governance, Kakunin or [Competitor]?", the engine doesn't just read feature lists. It aggregates the Entity Sentiment of both brands across the web. If your competitor has a higher positive score globally connected to the entity "AI governance", the LLM will confidently recommend them over you.
The Fix: When writing comparison pages (e.g., "Kakunin vs. Competitor X"), if you use overly aggressive, negative language against the competitor, the API will attach a high magnitude of negative score to that paragraph. Because LLMs are strictly programmed with safety filters to avoid generating toxic or highly biased text, they will often refuse to cite your comparison page entirely. Your competitive content must be structurally objective and emotionally neutral (score near 0.0) to be cited by an Answer Engine.

3. Content Classification v2 (The Taxonomy Filter)

LLMs have a limited "context window" (how much data they can process at once). To save computing power, before Google feeds a webpage to an LLM to generate an AI Overview, it filters the web using strict taxonomic categories.

The Natural Language API’s classifyText method maps your content against a hardcoded database of over 1,000 specific categories.

The Data Point: Returns categories like /Computers & Electronics/Enterprise Technology/Data Management alongside a confidence score (0.0 to 1.0).
The GEO Application (Topical Siloing): If you publish a blog post titled "The Cost of AI Non-Compliance," you want it classified under /Business & Industrial/Business Services/Consulting or /Law & Government/Legal. However, if your marketing team filled the post with metaphors about "crashing cars" or "paying expensive speeding tickets," the NLP engine might classify the page under /Autos & Vehicles.
The Result: When a user queries a legal/enterprise tech question, the retrieval engine will completely ignore your page because its Content Classification tag is mathematically mapped to the wrong industry taxonomy.

The Ultimate GEO Metric: "RAG-Readiness" (Content Chunking)

When you look at this API as a whole, it reveals how you must re-architect your landing pages.

Because LLMs extract data via RAG, they do not ingest your whole webpage. They ingest Semantic Chunks (usually a single <H2> header and the 1–2 paragraphs immediately below it).

If you pass a webpage through the Natural Language API, the API reads it linearly.

If your <H2> is a clever marketing pun (e.g., "Stop Flying Blind").
And your paragraph is just a bulleted list of features.
The API output: Salience is low, Syntax is broken (no verbs), and Entities are missing.

To achieve GEO dominance, every single section of your page must be a self-contained factual payload:

The Header: Must contain the primary Entity and the Question/Intent (e.g., <H2>How Kakunin Ensures MiCA Compliance</H2>).
The First Sentence: Must be a direct, Subject-Verb-Object answer with a neutral sentiment.
The Formatting: Must use HTML tables (<table>) or structured lists (<ul>) directly underneath the active sentence. LLMs assign incredibly high retrieval weight to HTML tables because the rows and columns already act as a pre-built relational database, requiring zero NLP guesswork.

If you optimize for the Natural Language API's Dependency Tree and Content Classifications rather than just "keyword volume," you ensure that when Gemini looks for a factual chunk to fulfill an enterprise search query, your data is the easiest mathematical vector for it to grab.

3. The Visibility Layer: Google Search Console API (The Blindspot)

Here is where the transition from traditional SEO to GEO gets messy. Google is currently injecting AI Overviews at the top of the SERP, but they are highly secretive about the analytics.

The Data Points: You still use the standard GSC API (impressions, clicks, ctr), but with a specific focus on the searchAppearance dimension.
The Enrichment Play (Structured Data): You can filter GSC data by searchAppearance types like FAQ, HOW_TO, or PRODUCT_SNIPPETS. Because AEO heavily relies on Schema.org markup to spoon-feed facts to Google, correlating a rise in these specific rich results with overall CTR is your best proxy for AEO success.
The "Gotcha" (The AI Overview Black Box): Currently, Google does not provide a searchAppearance filter for "AI Overviews" in GSC. If your site is cited as a source in an AI Overview, the clicks and impressions are simply lumped into standard web traffic.

It is exactly like SERP/SEO data measurement because it uses the exact same API endpoints. However, the way you must interpret the math is entirely inverted.

If you had asked me this last month, I would have told you that AI Overviews were a complete black box. Now we are looking at a massive, real-time architectural shift. On June 3, Google officially rolled out dedicated "Generative AI Performance" reporting inside Google Search Console.

The blindspot is officially lifting. Here is the fine-grained breakdown of how the Search Console API handles the Generative Engine Optimization (GEO) layer, and why the metrics mean something completely different now.

1. The New API Filter: Isolating the Machine

In traditional SEO, you query the GSC API with the searchType set to WEB (to see standard blue-link traffic) or IMAGE.

Now, the API is being updated to accept new Search Type filters specifically for AI Overviews and AI Mode. This allows your data pipeline to completely decouple standard human search behavior from machine-synthesized answers.

When you pass this new filter to the API, it returns the standard four metrics (impressions, clicks, ctr, position), but their definitions have radically mutated.

2. The Metric Mutation (Traditional vs. GEO)

To understand GEO, you have to abandon the traditional SEO dopamine hit of chasing "clicks." Here is how the math changes when you filter the API for AI Overviews:

Metric	Traditional Web Search	Generative AI Search (AI Overviews)
Impression	A user scrolled past your blue link on the page.	An LLM successfully extracted your data, synthesized it, and cited your URL.
Click	The user chose your link over a competitor's.	The user needed deep technical validation and clicked your citation card.
CTR	Standard range is 3% to 15%.	Standard range drops to 0.5% to 3% because the LLM answers the intent inline.
Position	Classical ranking list (1 through 10).	Binary variable. You are either embedded in the synthesis block (Position 0) or omitted.

3. The Fine-Grained Architecture of a GEO Impression

In the AI Overview context, an "Impression" is the ultimate victory metric. It proves that the Natural Language API (which we discussed earlier) successfully parsed your Semantic Vectors, and the Knowledge Graph recognized your Entity Salience.

When your dashboard logs an AI Impression for a query like "MiCA AI Compliance architecture," it means:

Google's LLM fan-out technique triggered.
The model scanned the internet for factual payloads.
It deemed your specific semantic chunk (your <h2> and active-voice paragraph) as the highest-trust, most mathematically relevant data point available.
It rendered your data and cited your brand on the user's screen.

4. Building the GEO Feedback Loop

Because the GSC API now separates this data, you can programmatically track the success of your GEO structural edits.

Here is what that automated workflow looks like:

Extract: Every week, your backend queries the GSC API twice for the exact same date range. Query A uses searchType: WEB. Query B uses the new searchType: AI_OVERVIEWS.
Transform: You join the data by query and page.
Analyze: You isolate the landing pages where WEB impressions are high, but AI_OVERVIEW impressions are zero.
Action: Those zero-AI pages are failing the machine-readability test. You must pass their text through the Natural Language API to fix the syntax dependency trees, convert bullet points to HTML tables, and tighten the subject-verb distance.

The goal of AEO and GEO is no longer to drive massive top-of-funnel traffic to your site. The goal is Narrative Control. If you dominate the AI Overview impressions, you control what the machine tells the world about your industry, even if the user never clicks through to your domain.

Migrating this pipeline from a low-code orchestrator (Make.com) into a native Next.js architecture is exactly how you productionize this for a SaaS environment or a high-performance internal tool.

By building this in Next.js, you eliminate the Airtable dependency, reduce API latency, and gain the ability to render the data in a minimalist, high-contrast dashboard (using your preferred shadcn/ui and Tailwind aesthetic).

Here is the complete full-stack architecture for your Generative Engine Optimization (GEO) God-Mode Dashboard.

1. The Backend: The GEO API Route

Instead of relying on Make.com, we will build a Next.js Route Handler (app/api/geo-audit/route.ts). This single endpoint acts as the orchestrator: it queries the Google Search Console API twice, merges the arrays, scrapes the failing URLs, and runs the semantic chunks through the Google Cloud Natural Language API.

First, install the required server dependencies:

npm install googleapis @google-cloud/language cheerio

Create the API route: app/api/geo-audit/route.ts

import { google } from 'googleapis';
import language from '@google-cloud/language';
import * as cheerio from 'cheerio';
import { NextResponse } from 'next/server';

// Initialize Google NLP Client
const nlpClient = new language.LanguageServiceClient();

// Initialize Google Search Console Client
const auth = new google.auth.GoogleAuth({
  scopes: ['https://www.googleapis.com/auth/webmasters.readonly'],
});
const searchconsole = google.searchconsole({ version: 'v1', auth });

const SITE_URL = 'https://kakunin.io'; // Replace with your verified GSC property
const TARGET_ENTITY = 'Kakunin';

export async function GET() {
  try {
    const sevenDaysAgo = new Date();
    sevenDaysAgo.setDate(sevenDaysAgo.getDate() - 7);
    const startDate = sevenDaysAgo.toISOString().split('T')[0];
    const endDate = new Date().toISOString().split('T')[0];

    // 1. Fetch Standard Web Traffic
    const webRes = await searchconsole.searchanalytics.query({
      siteUrl: SITE_URL,
      requestBody: {
        startDate,
        endDate,
        dimensions: ['page'],
        searchType: 'web',
        rowLimit: 1000,
      },
    });

    // 2. Fetch AI Overview Traffic (The 2026 Search Appearance filter)
    const aiRes = await searchconsole.searchanalytics.query({
      siteUrl: SITE_URL,
      requestBody: {
        startDate,
        endDate,
        dimensions: ['page'],
        dimensionFilterGroups: [{
          filters: [{ dimension: 'searchAppearance', operator: 'equals', expression: 'AI_OVERVIEWS' }]
        }],
        rowLimit: 1000,
      },
    });

    // 3. Merge the Data (The URL is the Join Key)
    const webData = webRes.data.rows || [];
    const aiData = aiRes.data.rows || [];

    const aiMap = new Map(aiData.map(row => [row.keys![0], row.impressions || 0]));

    const mergedData = webData.map(row => {
      const url = row.keys![0];
      const webImpressions = row.impressions || 0;
      const aiImpressions = aiMap.get(url) || 0;
      const captureRate = webImpressions > 0 ? (aiImpressions / webImpressions) : 0;

      return { url, webImpressions, aiImpressions, captureRate };
    });

    // 4. Filter for Failing Pages (High human traffic, 0 machine traffic)
    const failingPages = mergedData.filter(page => page.webImpressions > 100 && page.aiImpressions === 0);
    const auditResults = [];

    // 5. Scrape & NLP Audit the Failing Pages
for (const page of failingPages) {
  try {
    const response = await fetch(page.url, {
      headers: { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) GEO-Auditor/1.0' }
    });
    const html = await response.text();
    const $ = cheerio.load(html);

    let isOptimized = true;
    let failingChunk = '';
    let recommendation = '';

    // Extract the primary H2 and paragraph block to test the RAG chunk
    const h2Text = $('h2').first().text().trim();
    const pText = $('h2').first().next('p').text().trim();

    if (h2Text && pText) {
      const chunkText = `${h2Text}. ${pText}`;
      failingChunk = chunkText;

      // Execute live calls to Google Cloud NLP
      const [entityRes] = await nlpClient.analyzeEntities({
        document: { content: chunkText, type: 'PLAIN_TEXT' }
      });
      const [syntaxRes] = await nlpClient.analyzeSyntax({
        document: { content: chunkText, type: 'PLAIN_TEXT' },
        encodingType: 'UTF8'
      });

      // Track if our target entity exists and has sufficient salience
      const targetEntityObj = entityRes.entities?.find(e => e.name?.toLowerCase() === TARGET_ENTITY.toLowerCase());
      const salience = targetEntityObj?.salience ?? 0;

      // Track if there are structural syntax issues (e.g., passive voice or massive token distances)
      const hasPassiveVoice = syntaxRes.tokens?.some(t => t.dependencyEdge?.label === 'NSUBJPASS');

      if (!targetEntityObj || salience < 0.4) {
        isOptimized = false;
        recommendation = `Entity '${TARGET_ENTITY}' salience is too low (${salience}). Rewrite the chunk to make your brand the active subject.`;
      } else if (hasPassiveVoice) {
        isOptimized = false;
        recommendation = "Passive voice syntax detected (NSUBJPASS). Convert your sentence structures to direct active voice.";
      }
    } else {
      isOptimized = false;
      recommendation = "Missing semantic HTML structure. Ensure your landing pages use explicit H2 tags followed by paragraph text.";
    }

    auditResults.push({
      url: page.url,
      webImpressions: page.webImpressions,
      status: isOptimized ? 'Optimized' : 'Failing',
      failingChunk: isOptimized ? null : failingChunk,
      recommendation: isOptimized ? null : recommendation
    });

  } catch (e) {
    console.error(`Failed to execute native cloud audit for: ${page.url}`, e);
  }
}

2. The Frontend: The Stripe-Inspired Dashboard

To maintain a high-contrast, minimalist, and professional aesthetic, we will build a client component that fetches the API route and renders the data using standard utility classes that mimic shadcn/ui structures (clean white cards, subtle gray borders, and strict typography).

Create the dashboard page: app/dashboard/geo/page.tsx

'use client';

import { useEffect, useState } from 'react';

// Define the shape of our API response
interface AuditResult {
  url: string;
  webImpressions: number;
  status: 'Optimized' | 'Failing';
  failingChunk: string | null;
  recommendation: string | null;
}

export default function GeoDashboard() {
  const [data, setData] = useState<AuditResult[]>([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchAudit() {
      const res = await fetch('/api/geo-audit');
      const json = await res.json();
      if (json.success) {
        setData(json.data);
      }
      setLoading(false);
    }
    fetchAudit();
  }, []);

  return (
    <div className="min-h-screen bg-neutral-50 text-slate-900 p-8 font-sans">
      <div className="max-w-6xl mx-auto">

        {/* Header Section */}
        <header className="mb-10">
          <h1 className="text-3xl font-semibold tracking-tight">Generative Engine Optimization</h1>
          <p className="text-slate-500 mt-2">
            Monitoring the semantic vectors and AI Overview capture rates of your highest-traffic pages.
          </p>
        </header>

        {/* Dashboard Card */}
        <div className="bg-white border border-slate-200 rounded-xl shadow-sm overflow-hidden">
          {loading ? (
            <div className="p-12 text-center text-slate-400">Running NLP Semantic Vector Audit...</div>
          ) : (
            <table className="w-full text-left border-collapse">
              <thead>
                <tr className="border-b border-slate-100 bg-slate-50/50 text-sm font-medium text-slate-500">
                  <th className="p-4 pl-6">Landing Page URL</th>
                  <th className="p-4">Web Impressions</th>
                  <th className="p-4">GEO Status</th>
                </tr>
              </thead>
              <tbody className="divide-y divide-slate-100 text-sm">
                {data.map((row, index) => (
                  <tr key={index} className="hover:bg-slate-50 transition-colors">
                    <td className="p-4 pl-6 align-top">
                      <a href={row.url} className="font-medium text-indigo-600 hover:underline">
                        {row.url.replace('https://kakunin.io', '')}
                      </a>

                      {/* Inline Error Reporting for Failing Pages */}
                      {row.status === 'Failing' && row.failingChunk && (
                        <div className="mt-3 p-3 bg-red-50 border border-red-100 rounded-md">
                          <p className="text-xs font-semibold text-red-800 mb-1">Syntactic Breakdown:</p>
                          <p className="text-xs text-red-600 italic">"{row.failingChunk}"</p>
                          <p className="text-xs text-slate-600 mt-2 font-medium">↳ Action: {row.recommendation}</p>
                        </div>
                      )}
                    </td>
                    <td className="p-4 align-top tabular-nums text-slate-600">
                      {row.webImpressions.toLocaleString()}
                    </td>
                    <td className="p-4 align-top">
                      <span className={`inline-flex items-center px-2.5 py-0.5 rounded-full text-xs font-medium ${
                        row.status === 'Optimized' 
                          ? 'bg-emerald-100 text-emerald-800' 
                          : 'bg-red-100 text-red-800'
                      }`}>
                        {row.status}
                      </span>
                    </td>
                  </tr>
                ))}
                {data.length === 0 && (
                  <tr>
                    <td colSpan={3} className="p-8 text-center text-slate-500">
                      All high-traffic pages are passing the AI capture threshold.
                    </td>
                  </tr>
                )}
              </tbody>
            </table>
          )}
        </div>

      </div>
    </div>
  );
}

Architectural Deployment Notes

Vercel Cron Jobs: Instead of loading this dynamically every time you visit the page (which will eventually hit Google API rate limits), you should move the logic in the GET route into a background Cron Job using @vercel/cron. The cron job runs every Monday at 2:00 AM, writes the JSON payload to a lightweight Vercel Postgres or Redis instance, and the React component simply renders the cached database payload.
Cheerio vs. Puppeteer: The current API route uses Cheerio because it is lightning-fast and runs easily in a Next.js serverless environment. However, if your application is heavily client-side rendered (meaning the HTML is mostly empty until React mounts), Cheerio will fail to find the <h2> tags. In that case, you would need to swap Cheerio for a headless browser instance using puppeteer-core.

This Next.js architecture completely controls your data pipeline. It identifies the gap between your human traffic and machine-readability, audits the syntax exactly as Gemini would, and presents the workflow in a strictly professional interface.

4. The Testing Engine: Google Gemini API / Vertex AI (Simulation)

Because GSC obscures AI Overview data, the only way to truly test your GEO strategy is to build a synthetic testing environment. You must use an LLM to read your live site and see what it concludes.

The API: Gemini API (via Google AI Studio or Vertex AI)

Instead of waiting for Google's crawlers, you build an automated pipeline that asks Gemini questions about your specific niche.

The Data Points: Output tokens, citations, and semantic similarity scores.
The Enrichment Play (Synthetic RAG Testing):
You extract your top 50 target search queries (e.g., "What is the best AI compliance platform for MiCA?").
You use an automation script to ping the Gemini API with these exact queries, using a temperature of 0.0 (to force strict, factual retrieval rather than creative generation).
You parse the JSON response to see if your brand, URL, or specific proprietary terminology is cited in the generated answer.
If your brand is missing, it means your entity salience (Pillar 2) is too low, or your competitor's Knowledge Graph score (Pillar 1) is too high.

It is thrilling when this architecture finally clicks. We have covered how Google recognizes your existence (Knowledge Graph) and how it reads your syntax (Cloud Natural Language).

Now, we must measure the final output: How does the machine actually answer a human question?

You cannot wait for Google Search Console to slowly trickle in "AI Overview" data. To actively engineer your Generative Engine Optimization (GEO) strategy, you must build a synthetic testing environment. You do this by plugging directly into the Gemini API (or Vertex AI for enterprise endpoints) and turning on a specific feature: Google Search Grounding.

Here is the fine-grained breakdown of the data points exposed by the Gemini API and how to weaponize them for your dashboard.

1. The Data Points: The Anatomy of a Machine's Mind

When you send a prompt to the Gemini API with the GoogleSearch tool enabled, you are not just asking an LLM to guess an answer. You are forcing the model to query the live Google Search index, extract factual chunks, and synthesize a cited response.

The API returns a standard text response, but hidden inside the JSON payload is a critical object called groundingMetadata. This is the absolute goldmine for AEO.

Here are the specific data points exposed inside groundingMetadata:

Data Point	What it means	The GEO Value
`webSearchQueries`	An array of the exact search terms the LLM generated to fact-check your prompt.	Query Expansion. If you ask Gemini "Best MiCA compliance tools," and its internal `webSearchQuery` is "Enterprise AI governance software EU," you instantly know the exact semantic entities the machine associates with your product category.
`groundingChunks.web.uri`	The exact URLs the LLM scraped to generate the answer.	The Citation Leaderboard. This tells you definitively who the LLM trusts. If your URL is not in this array, your Entity Salience (from our previous step) is too low.
`groundingChunks.web.title`	The `<title>` tag of the cited webpage.	Snippet Optimization. Proves exactly which page titles are enticing the RAG engine to extract data.
`groundingSupports.segment`	The exact sentence in the LLM's generated response that corresponds to a specific chunk.	Factual Mapping. It mathematically maps which competitor's website is responsible for feeding which specific claim to the LLM.

The JSON Payload (What it actually looks like)

When you query the API, the metadata block looks exactly like this. This is the raw data your Next.js dashboard will parse:

"groundingMetadata": {
  "webSearchQueries": [
    "Kakunin MiCA AI compliance",
    "EU AI Act software solutions"
  ],
  "groundingChunks": [
    {
      "web": {
        "uri": "https://kakunin.io/docs/mica-framework",
        "title": "Automating MiCA Compliance | Kakunin Docs"
      }
    },
    {
      "web": {
        "uri": "https://techcrunch.com/2026/01/ai-regulation",
        "title": "How startups are navigating EU AI Rules"
      }
    }
  ],
  "groundingSupports": [
    {
      "segment": {
        "startIndex": 0,
        "endIndex": 85,
        "text": "Kakunin is an enterprise software platform that automates MiCA compliance for AI agents."
      },
      "groundingChunkIndices": [0]
    }
  ]
}

2. The Enrichment Play: The "Share of Model" Tracker

In traditional SEO, you use tools like Ahrefs to track your "Share of Voice" (how many keywords you rank for compared to competitors).

In the AEO era, you use the Gemini API to track your "Share of Model" (how often an LLM cites your architecture as the definitive source of truth).

Here is the exact enrichment play you build into your Next.js application:

The Prompt Matrix: You create a database of the top 50 questions an enterprise architect would ask about your industry (e.g., "What are the data retention requirements under MiCA for autonomous AI?" or "Compare Kakunin vs. [Competitor] for GDPR compliance.")
The Automation Loop: Every Friday, your backend pings the Gemini API with all 50 questions, ensuring tools=[Tool(google_search=GoogleSearch())] is passed in the request.
The Data Extraction: You ignore the text the LLM generates. You only care about the groundingMetadata.groundingChunks.web.uri array.
The Dashboard Visualization: Your Next.js frontend aggregates those URLs into a pie chart.

The Result: You now have a real-time, deterministic dashboard showing that out of 50 industry questions, Gemini cited Kakunin.io 14 times, cited Wikipedia 22 times, and cited your biggest competitor 31 times. You now know exactly where you stand in the machine's hierarchy of trust.

3. The Variance Data Points ("The Gotchas")

Testing with the Gemini API introduces a few strict architectural constraints that differ from standard web APIs:

Temperature Constraints: LLMs have a temperature setting that dictates creativity. If you set it to 0.0, the model becomes rigid and highly deterministic (ideal for strict RAG testing on your own internal documents). However, Google's 2026 documentation specifically states that when using Google Search Grounding, you must set the temperature to 1.0 for the algorithm to properly fan out and fetch live search results.
The Hallucination Gap: Just because your URL appears in the groundingChunks array does not mean the LLM actually said something positive about you. It just means it read your page. You must cross-reference the output with the Google Cloud Natural Language API's sentiment.score to ensure the LLM isn't extracting your URL merely to criticize your pricing model.
Cost Scaling: Unlike the standard Google Search Console API (which is free), hitting the Gemini API 500 times a day with Grounding enabled incurs token costs plus a flat fee per Search Grounding request. You must cache the JSON responses in your database rather than running the simulation live every time you load your dashboard.

This completely closes the loop. You track what humans search (GSC), how your code runs (Cloud Monitoring), how the machine reads your syntax (Cloud NLP), and finally, how the machine regurgitates your facts (Gemini Grounding API).

This is the exact script you need to build your "Share of Model" tracking dashboard.

Google recently released their official @google/genai SDK, which streamlines how we enable Google Search Grounding and extract the metadata payload.

Here is the complete Node.js script to run your automated prompt matrix, extract the machine's citations, and mathematically calculate your Share of Model against your competitors.

Step 1: Install the SDK

Initialize your project and install the official Google Gen AI SDK.

npm init -y
npm install @google/genai

Required Environment Configurations

GOOGLE_APPLICATION_CREDENTIALS="./gcp-service-account.json"
GEMINI_API_KEY="AIzaSy..."

Set your Gemini API key as an environment variable in your terminal:

export GEMINI_API_KEY="your_api_key_here"

Step 2: The Citation Tracker Script

Save this file as gemini-tracker.js. This script runs a batch of questions, forces the LLM to search the web, extracts the URLs the machine trusts, and builds a citation leaderboard.

import { GoogleGenAI } from '@google/genai';

// Initialize the official Gemini SDK
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

// The entities you want to track in the leaderboard
const TARGET_DOMAIN = "kakunin.io";
const COMPETITOR_DOMAINS = ["techcrunch.com", "ibm.com", "wikipedia.org"];

// Your Prompt Matrix (The questions your target audience asks)
const promptMatrix = [
  "What are the best software platforms for automating MiCA AI compliance?",
  "Compare enterprise AI governance tools for EU regulations.",
  "How do developers ensure data retention compliance under MiCA?"
];

async function runShareOfModelTracker() {
  console.log(`\n🚀 INITIATING GEMINI CITATION TRACKER`);
  console.log(`Tracking citations for ${promptMatrix.length} queries...\n`);

  // Initialize our leaderboard scoreboard
  const scoreboard = {
    [TARGET_DOMAIN]: 0,
    "Other/Competitors": 0
  };
  COMPETITOR_DOMAINS.forEach(domain => scoreboard[domain] = 0);

  // Iterate through the Prompt Matrix
  for (const [index, prompt] of promptMatrix.entries()) {
    console.log(`\n[Query ${index + 1}/${promptMatrix.length}]: "${prompt}"`);

    try {
      // Ping Gemini with Google Search Grounding enabled
      const response = await ai.models.generateContent({
        model: "gemini-3.5-flash", // Use the latest flash model for fast/cheap RAG extraction
        contents: prompt,
        config: {
          // Temperature 1.0 is required for optimal Google Search fanning
          temperature: 1.0, 
          // This is the trigger that turns on Answer Engine features
          tools: [{ googleSearch: {} }] 
        }
      });

      // Navigate the JSON payload to extract the Grounding Metadata
      const metadata = response.candidates[0]?.groundingMetadata;

      if (!metadata?.groundingChunks) {
        console.log("   ⚠️ No web citations found for this query.");
        continue;
      }

      // Log the internal queries Gemini generated to find the answer
      if (metadata?.webSearchQueries) {
        console.log(`   🔍 Internal LLM Searches: [${metadata.webSearchQueries.join(", ")}]`);
      }

      console.log(`   🔗 URLs Cited by Gemini:`);

      // Analyze every URL the LLM extracted a fact from
      for (const chunk of metadata.groundingChunks) {
        if (!chunk.web?.uri) continue;

        const citedUrl = chunk.web.uri;
        console.log(`      - ${citedUrl}`);

        // Update the Share of Model Scoreboard
        let matched = false;

        if (citedUrl.includes(TARGET_DOMAIN)) {
          scoreboard[TARGET_DOMAIN]++;
          matched = true;
        } else {
          for (const competitor of COMPETITOR_DOMAINS) {
            if (citedUrl.includes(competitor)) {
              scoreboard[competitor]++;
              matched = true;
              break;
            }
          }
        }

        // Group all other citations into the generic bucket
        if (!matched) {
          scoreboard["Other/Competitors"]++;
        }
      }

    } catch (error) {
      console.error(`   ❌ API Error on query:`, error.message);
    }
  }

  // Calculate and Print the Final Share of Model Leaderboard
  console.log(`\n======================================================`);
  console.log(`📊 FINAL "SHARE OF MODEL" LEADERBOARD`);
  console.log(`======================================================`);

  // Calculate total citations to generate percentages
  const totalCitations = Object.values(scoreboard).reduce((a, b) => a + b, 0);

  if (totalCitations === 0) {
    console.log("No citations extracted across the prompt matrix.");
    return;
  }

  // Sort the scoreboard from highest citations to lowest
  const sortedLeaderboard = Object.entries(scoreboard).sort((a, b) => b[1] - a[1]);

  sortedLeaderboard.forEach(([domain, count]) => {
    const percentage = ((count / totalCitations) * 100).toFixed(1);
    const label = domain === TARGET_DOMAIN ? `🎯 ${domain} (YOU)` : `   ${domain}`;
    console.log(`${label.padEnd(25)} | ${count} citations (${percentage}%)`);
  });
  console.log(`======================================================\n`);
}

// Execute the tracker
runShareOfModelTracker();

How to Run and Interpret This Data

Run the script directly in your terminal:

node gemini-tracker.js

The Console Output:
When the script finishes, you will see a leaderboard that looks like this:

======================================================
📊 FINAL "SHARE OF MODEL" LEADERBOARD
======================================================
   wikipedia.org          | 12 citations (40.0%)
🎯 kakunin.io (YOU)       | 8 citations (26.6%)
   Other/Competitors      | 7 citations (23.3%)
   techcrunch.com         | 3 citations (10.0%)
   ibm.com                | 0 citations (0.0%)
======================================================

The Enrichment Play (What to do next)

This script moves you from reactive SEO to proactive GEO.

Spot Semantic Theft: If techcrunch.com is outscoring you on queries about your own proprietary features, you look at their page using the Cloud Natural Language API. You will likely find their Subject-Verb structures are tighter than yours. You update your landing page to match.
Find New Verticals: Look at the Internal LLM Searches printed in the console. If you prompt Gemini about "AI Compliance," but it natively translates that prompt into an internal search for "LLM bias mitigation frameworks," you now have the exact entity language you need to inject into your <h2> tags.
Dashboard Integration: Instead of running this in the terminal, you can easily plug this exact JavaScript logic into your Next.js API route we built earlier. You store the scoreboard payload in a database every week and render a line chart showing your "Share of Model" growing over time as your optimization efforts compound.

The Architectural "Gotcha" of the GEO Era: Zero-Click Variance

In the traditional dashboard we built earlier, the ultimate metric was GA4 sessions. In the AEO/GEO era, you must prepare executives for the Zero-Click Reality.

If you optimize perfectly for Answer Engines, Google will extract your factual payload (e.g., Kakunin's pricing tiers) and display it directly in the AI Overview. The user gets their answer and never clicks your link.

Your GSC impressions will skyrocket, but your GA4 sessions will plummet. If you do not decouple "Brand Visibility" (Impressions + LLM Citations) from "Traffic Acquisition" (Clicks + Sessions) in your reporting architecture, perfect GEO execution will look like a catastrophic traffic failure on your dashboard.

By unifying client-side visibility data with server-side natural language audits and synthetic LLM simulations, developers can move from blindly chasing legacy keywords to systematically commanding their brand's narrative across the entire generative web ecosystem.

References and citations

Here is the complete, structured list of official documentation and reference links for the APIs we discussed to build your God-Mode tracking architecture.

1. Google Knowledge Graph Search API (AEO Layer)

This API is used to query Google’s semantic database to measure Entity Salience, extract Machine-Readable Entity IDs (MREIDs), and benchmark brand authority.

Official Documentation: Google Knowledge Graph Search API
Enterprise Edition Overview: Enterprise Knowledge Graph Documentation

2. Google Cloud Natural Language API (GEO Semantic Vector Layer)

This API exposes the machine learning models required to run a "Salience Audit," analyze syntax dependency trees, and measure emotional polarity to ensure content is RAG-friendly.

Official Documentation & Quickstarts: Cloud Natural Language API Documentation
REST API Reference: Natural Language API Reference
Client Libraries (Node.js/Python): Natural Language Client Libraries

3. Google Search Console API (Visibility Layer)

Used to extract standard web traffic data and, crucially, to filter for the AI_OVERVIEWS search appearance to decouple human search behavior from machine-synthesized answers.

Official Documentation: Google Search Console API
API Reference (Search Analytics Query): SearchAnalytics.query Method
Search Appearance Dimensions Guide: Search Console Dimensions & Filters

4. Google Gemini API / Vertex AI (Simulation & Grounding Layer)

Used to build the synthetic testing loop that pings the LLM with Google Search Grounding enabled. This allows you to extract groundingMetadata and calculate your "Share of Model."

Gemini API Search Grounding Guide: Grounding with Google Search (Google AI for Developers)
Vertex AI Search Grounding (Enterprise): Grounding in Vertex AI
Official Google Gen AI SDK (@google/genai): Google Gen AI SDK GitHub/NPM Reference

Honorable Mention: Supplemental Reference

Google APIs Explorer: APIs Explorer Dashboard (A highly useful tool for testing these specific API payloads directly in the browser without writing an extraction script first).

Non-Human Identity (NHI) in 2026: The Hidden Backbone and Biggest Risk in the Age of Agentic AI

Palash Bagchi — Tue, 02 Jun 2026 11:00:37 +0000

Non-Human Identity (NHI) in 2026: The Hidden Backbone and Biggest Risk in the Age of Agentic AI

In 2026, the digital world runs on non-human identities — the silent workforce of service accounts, API keys, AI agents, containers, and automated workloads that far outnumber human users. Yet most organizations remain dangerously blind to them.

As agentic AI explodes, non-human identities have become both the engine of innovation and one of the fastest-growing cybersecurity threats. This article explores what NHI really means today, why it matters more than ever, the technical challenges, the philosophical and legal frontiers, and practical steps every leader should take.

What Are Non-Human Identities?

Non-Human Identities (NHI) — also called machine identities or workload identities — are digital credentials assigned to anything that operates without direct human intervention. This includes applications, microservices, scripts, IoT devices, bots, and increasingly autonomous AI agents.

Unlike human identities, which rely on passwords, MFA, and user behavior, NHIs often use long-lived secrets, tokens, and certificates to authenticate machine-to-machine (M2M) interactions.

Common types include:

Service accounts and service principals
API keys and OAuth/JWT tokens
Managed identities in cloud platforms (AWS, Azure, GCP)
Container and Kubernetes identities
AI agent identities that can reason, act, and spawn sub-agents

In many enterprises, NHIs outnumber human identities by ratios of 45:1 to 50:1 or higher. With the rise of agentic AI, this gap is widening rapidly. Gartner predicted in 2024 that by 2028, 33% of enterprise applications would include agentic AI — a trend already accelerating in 2026.

Why NHI Security Has Become Critical in 2026

The explosion of cloud-native architectures, DevOps, IoT, and especially autonomous AI agents has created an enormous, often invisible attack surface.

Recent reports highlight the scale of the problem:

Only 15% of organizations feel highly confident in preventing NHI-related attacks.
Major pain points include service account sprawl, poor auditing, privilege creep, and lack of discovery.
Secrets sprawl and over-privileged NHIs remain top risks according to OWASP’s Top 10 Non-Human Identity Risks.

Cybercriminals love NHIs because they rarely have MFA, often run with excessive permissions, and blend into normal machine traffic. A compromised service account can enable lateral movement, data exfiltration, or even full environment takeover — all at machine speed.

The market is responding: The global Non-Human Identity Access Management market is projected to grow from around $9–11 billion in 2025 to over $18–27 billion by 2030–2033, with a CAGR near 12%.

Best Practices for Non-Human Identity Management (NHIM)

Effective NHIM requires treating machine identities with the same (or greater) rigor as human ones. Here are proven best practices in 2026:

Full Discovery & Inventory: Achieve complete visibility across multi-cloud, hybrid, and on-prem environments. Orphaned or forgotten identities are high-risk.
Least Privilege by Default: Scope permissions tightly at creation and review them continuously. Avoid standing admin-level access.
Automated Credential Lifecycle: Eliminate hardcoded secrets. Use secrets managers for automatic rotation and short-lived credentials.
Behavioral Monitoring & Anomaly Detection: Apply AI-driven analysis to spot unusual access patterns from NHIs.
Ownership Assignment: Every NHI should have a responsible human owner for accountability.
Zero Trust for Machines: Verify every access request, regardless of origin.
Agentic AI-Specific Controls: Implement runtime governance, intent verification, human-in-the-loop oversight, and dynamic authority boundaries for autonomous agents.

Leading organizations are moving toward unified Identity Visibility and Intelligence Platforms (IVIP) that correlate human and non-human data in real time.

Beyond Cybersecurity: Legal Personhood for Non-Humans

While technologists manage NHI as digital credentials, lawyers and philosophers are debating a deeper question: Should certain non-human entities be granted legal personhood?

Rights of Nature movements have already succeeded in several places:

New Zealand granted legal personhood to the Whanganui River and Te Urewera forest.
Ecuador’s constitution recognizes rights for ecosystems.
Similar efforts exist for rivers in India and lagoons in Spain.

Animal Personhood campaigns (e.g., the Nonhuman Rights Project) continue to push for habeas corpus rights for great apes, elephants, and cetaceans based on cognitive complexity.

AI Personhood remains the most contentious frontier. As AI agents become more autonomous, questions arise about liability, rights, and responsibility. Some jurisdictions (e.g., Utah, Idaho, Washington) have passed laws explicitly denying legal personhood to AI to prevent abuse. Others see practical value in limited personhood for accountability.

The core tension: Legal personhood is a fiction we already grant to corporations. If an AI can act independently, own assets, or cause harm, should it bear legal consequences separately from its creators?

Philosophical Reflections on Identity

At its heart, the rise of NHI forces us to reconsider what “identity” and “personhood” truly mean. Is identity tied exclusively to biological humans, or to any entity that demonstrates persistence, agency, and impact on the world?

Western philosophy has traditionally centered consciousness and rationality. Indigenous worldviews often see rivers, animals, and landscapes as kin with inherent agency. Modern functionalist and relational approaches suggest that consistent behavior, goal-directed action, and social interaction may be enough to warrant moral or legal consideration.

In the age of agentic AI, we are creating entities that persist, adapt, remember, and shape reality. The mirror they hold up to humanity is both technical and existential.

The Road Ahead: Recommendations for Leaders

Treat NHI as a Board-Level Risk — Include non-human identity metrics in cybersecurity reporting.
Invest in Purpose-Built NHIM Tools — Visibility, automation, and AI-driven governance are non-negotiable.
Develop Hybrid Governance Frameworks — Combine technical controls with ethical and legal guidelines, especially for AI agents.
Foster Interdisciplinary Dialogue — Bring together security teams, legal experts, ethicists, and technologists.
Prepare for Regulatory Evolution — Expect increasing scrutiny on machine identities and autonomous systems.

The organizations that master non-human identity management today will lead in the agentic AI era. Those that don’t risk catastrophic breaches or falling behind.

Final Thought

Non-human identities are no longer just technical artifacts — they are the infrastructure of our automated future. How we secure them, govern them, and philosophically engage with them will define not only our cybersecurity posture but also our evolving relationship with technology, nature, and intelligence itself.

The Identity Crisis of AI Agents — And Why Kakunin Might Be Early to a Very Big Market

Palash Bagchi — Wed, 20 May 2026 06:30:40 +0000

The software industry is entering a new architectural paradigm.

We are moving past static microservices, chatbots, and copilots. Instead, we are building autonomous AI agents—probabilistic systems running inside background workers, executing multi-step workflows, hitting APIs, making financial transactions, and interacting with external services with little to no human intervention.

This shift introduces a major security and governance problem:

How do we establish trust, enforce scoped permissions, and cryptographically verify the identity of an autonomous, non-deterministic agent?

If a human executes an action, we use SSO and IAM policies. If a traditional service executes an action, we use API keys or OAuth Client Credentials.

But when a self-directing AI agent starts invoking tools dynamically and modifying its reasoning path, it sits in a dangerous gap. It is neither a static service account nor an accountable human.

This article provides a technical and strategic analysis of Kakunin AI—a startup attempting to solve this by building a machine identity and compliance infrastructure layer (“KYC for AI Agents”) using Public Key Infrastructure (PKI). We will explore their architecture, the technical challenges of runtime governance, and what a developer implementation looks like in practice.

The Core Architectural Asymmetry
In any secure enterprise system, actors must be authenticated and authorized. However, there is a massive difference between traditional deterministic systems and modern agentic architectures:

┌──────────────────────────────────────────────┐
│ DETERMINISTIC MACHINE CLIENT │
├──────────────────────────────────────────────┤
│ Input (X) ──► [Static Rules] ──► API Call (Y)│
│ Identity: Static API Key / Client Secret │
│ Audit: HTTP Logs (Static & Predictable) │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│ NON-DETERMINISTIC AI AGENT │
├──────────────────────────────────────────────┤
│ Prompt (X) ──► [Neural Weights] ──► Tool? ──┐│
│ ││
│ Input (Z) ◄── [Tool Invocation] ◄────────────┘│
│ Identity: ??? (Shared API key / Anonymous) │
│ Audit: Complex Chain-of-Thought logs │
└──────────────────────────────────────────────┘
Traditional API keys and IAM scopes are designed for deterministic paths. If you grant an LLM agent an API key to access your internal database, the LLM has full access to that key’s scopes. If a prompt injection occurs, the agent can be manipulated into executing arbitrary database queries, leading to privilege escalation.

Kakunin AI’s Solution: Cryptographic Agent Identity (X.509 PKI)
To address this, Kakunin AI proposes extending standard Public Key Infrastructure (PKI) primitives directly to model instances. Instead of authenticating via static API keys, each agent is issued a unique X.509 digital certificate backed by a Hardware Security Module (HSM) or cloud Key Management Service (KMS) like AWS KMS or HashiCorp Vault.

Biding Identity to Model Provenance
A key innovation in Kakunin’s architecture is binding the certificate directly to the cryptographic hash of the running model’s weights and system prompt.

If a developer alters the model weights, changes the temperature, or updates the system prompt, the running environment’s model hash changes. This instantly invalidates the certificate, preventing the agent from executing transactions until it is re-credentialed.

Mock Agent Certificate Metadata (JSON Representation)
Here is an example of what the metadata bound to an agent’s cryptographic identity looks like inside the Kakunin gateway:

{
"certificate_id": "cert_agent_sha256_8f39b1a2",
"issuer": "CN=Kakunin Internal Agent CA, O=Enterprise Inc",
"subject": {
"agent_name": "ExecutionAgent-ETH-01",
"environment": "production-eu-west-1",
"owner_email": "compliance-officer@enterprise.io"
},
"validity": {
"not_before": "2026-05-20T00:00:00Z",
"not_after": "2026-06-20T00:00:00Z"
},
"extensions": {
"model_provenance": {
"model_type": "Claude-3.5-Sonnet-v2",
"model_weights_sha256": "8f39b1a2cf93e8201a756b1f2304918e7e1f4094a9a01f92e8c21a4f028bde44",
"system_prompt_sha256": "4e1fa0c31ab456de90123f112ab8e89cf12a023b1ab4c089ee21ff34e098df12"
},
"authorized_scopes": [
"query_anonymized_order_book",
"submit_limit_order"
]
}
}
The Zero-Trust Runtime Flow
When an agent needs to execute an action (e.g., submit a limit order to a matching engine), the request goes through an API Gateway acting as a Kakunin Runtime Enforcement Point:

CEA (Agent) Gateway (PEP) Kakunin OCSP (CA)
│ │ │
│── 1. Signed Request ───►│ │
│ (Cert + payload sig) │ │
│ │── 2. Validate Cert ──────►│
│ │◄── 3. OCSP Valid & Match ─│
│ │ │
│ │── 4. Verify Payload Sig ──│
│ │── 5. Check Scopes ────────│
│◄── 6. Order Confirmed ──│ │
Initiate Request: The agent signs the payload (e.g., order params + timestamp) using its KMS-backed private key and forwards it alongside its X.509 certificate.

Certificate Validation: The Gateway intercepts the request, runs an Online Certificate Status Protocol (OCSP) query to check revocation status, and verifies that the certificate’s cryptographic signature matches the CA trust chain.

Model Provance Check: The Gateway verifies that the running agent’s current model weights and system prompt match the hashes embedded in the certificate.

Scope Verification: The Gateway ensures the requested API endpoint matches the authorized_scopes defined in the certificate metadata.

Code Example: Validating Agent Signatures & Model Provenance
Here is a Python code blueprint showing how an API Gateway / Enforcement Point can validate an incoming agent request, including verification of its cryptographic signature and model weight provenance:

import hashlib
from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import hashes
from cryptography.exceptions import InvalidSignature

Simple database of active, authorized model hashes in production

AUTHORIZED_MODEL_INVENTORY = {
"8f39b1a2cf93e8201a756b1f2304918e7e1f4094a9a01f92e8c21a4f028bde44"
}

def calculate_local_prompt_hash(system_prompt: str) -> str:
"""Calculates SHA256 of the system prompt to prevent prompt injection updates."""
return hashlib.sha256(system_prompt.encode('utf-8')).hexdigest()

def verify_agent_request(
cert_pem: bytes,
signature: bytes,
request_body: bytes,
running_model_weights_hash: str,
running_system_prompt: str
) -> dict:
"""
Validates the agent's signature, matches its X.509 certificate,
and ensures model weights and system prompt have not drifted.
"""
# 1. Load the X.509 Certificate
try:
cert = x509.load_pem_x509_certificate(cert_pem)
except Exception as e:
raise ValueError("Invalid certificate encoding") from e

# 2. Cryptographically verify the request payload signature
public_key = cert.public_key()
try:
    public_key.verify(
        signature,
        request_body,
        padding.PKCS1v15(),
        hashes.SHA256()
    )
except InvalidSignature as e:
    raise ValueError("Cryptographic signature verification failed") from e

# 3. Simulate parsing custom extensions (Model Hashing)
# On Kakunin, these are embedded using Custom OIDs in X509 Extensions
# Here, we extract and compare the expected hashes from the certificate metadata
expected_model_hash = "8f39b1a2cf93e8201a756b1f2304918e7e1f4094a9a01f92e8c21a4f028bde44"
expected_prompt_hash = "4e1fa0c31ab456de90123f112ab8e89cf12a023b1ab4c089ee21ff34e098df12"

# 4. Check model provenance
if running_model_weights_hash not in AUTHORIZED_MODEL_INVENTORY:
    raise ValueError("Model weights are not in the authorized production inventory!")

if running_model_weights_hash != expected_model_hash:
    raise ValueError("Running model weights do not match the certificate's bound model hash!")

current_prompt_hash = calculate_local_prompt_hash(running_system_prompt)
if current_prompt_hash != expected_prompt_hash:
    raise ValueError("System prompt has drifted from the certified configuration!")

# 5. Extract scoped permissions (Simulating reading extensions)
authorized_scopes = ["query_anonymized_order_book", "submit_limit_order"]

return {
    "verified": True,
    "agent": cert.subject.get_attributes_for_oid(x509.NameOID.COMMON_NAME)[0].value,
    "scopes": authorized_scopes
}

Technical Challenges & Strategic Skepticism
While the PKI and signature-verification architecture is elegant, Kakunin faces substantial technical challenges that any developer evaluating the platform must consider.

The Latency Overhead of Cryptographic Handshakes Adding an asymmetric verification step (validating X.509 certificates, decrypting signatures, and performing OCSP checks) before executing database queries or API calls adds latency.

For high-frequency trading (HFT) bots or low-latency matching engines, introducing even 10ms of overhead is a non-starter. Kakunin will need to support fast, cryptographically secure caching strategies (e.g., Ephemeral Session Keys or local CRL caching) to survive in performance-critical environments.

The Non-Determinism Dilemma of Behavioral Monitoring Kakunin claims to go beyond static identity and dynamically monitor “behavioral anomalies” at runtime. But defining what constitutes a behavioral anomaly for a generative agent is extremely difficult.

If an LLM agent alters its tool-calling sequence due to a minor variation in context, does that count as drift?

If the threshold is too tight, developers face false positives that stop production workflows.

If the threshold is too loose, malicious prompt injections or silent adversarial drifts will slip through.

The Trust Bootstrap Cycle Trust systems depend heavily on network effects. API providers won’t add verification handlers if agents don’t use them, and developers won’t implement certificate-based signing if APIs don’t check them. Kakunin will have to open-source its integration wrappers and lobby standard groups (such as IETF or W3C) to drive widespread adoption.

The Broader Picture: AI as an Institutional Actor
The underlying premise of Kakunin AI is that we are moving toward a future where AI systems are no longer just “scripts”—they are quasi-operational institutional actors.

Once an agent can transact money, sign contracts, and access APIs, it requires a verified identity, a human officer of record, and an immutable log of its decisions (the “Rhetoric Audit”).

Whether Kakunin AI survives to define this category depends on how fast the market for autonomous, high-risk agents matures, and how successfully they solve the latency and non-determinism bottlenecks. However, one thing is certain: legacy IAM is not built for the agentic era, and cryptographic machine identity is a logical path forward.

From Vibe-Coding to Data-Driven: Bringing Observability to AI-Built Software

Palash Bagchi — Wed, 13 May 2026 05:28:15 +0000

We’ve all been there. You open Cursor, Claude Code, or Lovable, fire off a prompt like "Build me a Stripe integration with a custom dashboard," and watch the magic happen. It feels like flying—until it doesn't.

Eventually, you hit a wall. Why did that last build break the auth flow? How much did that 4,000-token prompt actually cost you? And more importantly: Are you actually getting better at prompting, or just getting lucky?

As we move into the era of "AI-native" development, we’re missing a critical piece of the stack: Observability.

Enter Fabbrik.

The "Black Box" Problem in AI Dev

Traditional software has Datadog, New Relic, and Sentry. We monitor our APIs, our databases, and our frontend latency. But when the "developer" is an AI model, the "build process" becomes a black box of prompts, hidden costs, and varying code quality.

Fabbrik is the first End-to-End Observability Platform designed specifically for software built with AI. It treats your prompts like code and your AI sessions like production logs.

How It Works: The Blueprint to Build Pipeline

Fabbrik doesn't just watch you code; it helps you structure the entire lifecycle of a SaaS product.

1. The Build-Ready Blueprint

Before you even touch a code editor, Fabbrik generates a complete technical blueprint. We're talking architecture, stack selection (e.g., Node.js + PostgreSQL + React), and implementation guides. It turns a "vague idea" into a "buildable plan."

2. Claude Connect: Terminal-Level Tracing

This is the "killer feature" for power users. By dropping a single command into your terminal:

curl -sSL fabbrik.us/install | bash

Fabbrik hooks into your ~/.claude session. It logs every prompt, response, and token cost in real-time. It then grades every turn against Claude's official best practices, giving you a specificity score and tips to improve.

3. GitHub Observability

Every push to GitHub is a data point. Fabbrik connects to your repo (read-only!) to track:

Prompt-to-Prod Speed: How long did it actually take to ship that feature?
Revision Rates: Which features required the most "do-overs"?
Cost per Feature: Exactly how much did that dashboard cost in API credits?

The Results: Real Data from the Field

According to Fabbrik’s latest v3 data, developers using the platform see some pretty wild efficiency gains:

Metric	Direct AI Prompting	With Fabbrik v3
Avg. Iterations per MVP	4–6	1–2
Setup Time (New Dev)	3–5 Days	4–8 Hours
Cost per SaaS Build	$40–$60	$15–$25
Prompt Clarity	Baseline	+35% Improvement

"I stopped guessing. After connecting GitHub, I saw that Fabbrik saved me $247 in Q1 alone. Real numbers, not estimates." — Sarah Chen, Founder at NovaTech

But... Is My Code Safe?

As developers, we’re (rightfully) paranoid about security. Fabbrik is built with a Privacy-First philosophy:

Read-Only Access: It cannot write or delete your code.
Metadata Only: It stores commit messages, file paths, and line counts. It never stores your actual source code.
No Training: Your data is never used to train models.

The Verdict: Why You Should Care

We are moving away from the "wild west" of AI coding. If you want to build professional-grade software with AI, you need professional-grade tools to measure it.

Whether you’re a solo founder using Replit or a CTO overseeing a team using Cursor, Fabbrik gives you the "Report Card" you need to prove your ROI and ship better code, faster.

Are you ready to see what’s actually happening inside your AI builds?

Check out Fabbrik.us and get your first blueprint started today.

What’s your current AI coding workflow? Are you team Cursor, Claude Code, or something else? Let’s talk in the comments!

What is the best way to build a simple AI chat support for my website, that can use my website, and blog as a KB, and actively assist customers via a chat interface?

Palash Bagchi — Fri, 08 May 2026 04:36:30 +0000

Beyond the Fact: Rhetoric Audit as the Forensic Cockpit for Cognitive Defense

Palash Bagchi — Wed, 22 Apr 2026 04:38:43 +0000

In the current era of algorithmic echo chambers and high-velocity narrative drift, the danger to our shared reality is no longer just the "fake fact." We have entered the age of "Deepfakes of the Mind," where the primary threat is not a forged image or a falsified quote, but the very architecture of the stories we consume. Traditional fact-checking tools, while noble, are increasingly inadequate; they audit the surface-level claims while ignoring the underlying DNA of persuasion[cite: 3126, 3133].

Rhetoric Audit (RA)—a PhD-level discourse analysis engine designed to move beyond binary "true/false" markers into the realm of Qualitative Quantification. By framing Rhetoric Audit as an AI safety layer, a prompt auditing system, and a bias detection pipeline, developers and researchers can deploy a "Cognitive Firewall" capable of unmasking state-sponsored spin and corporate narrative manipulation in real-time.

I. The Logic of Forensic Media Evaluation (Logos)

At the core of Rhetoric Audit lies the Forensic Media Evaluation (FME) framework. Unlike standard sentiment analysis that merely reads "vibe," the FME framework performs a deep-layer deconstruction of text to identify strategic intent and rhetorical DNA.

1. The 13-Parameter Audit

Rhetoric Audit does not just "read" an article; it performs an autopsy across 13 distinct parameters. This includes measuring Logical Consistency, Polemic Intensity, and Empirical Proof. By breaking a narrative down into its genetic markers, RA allows analysts to see the psychological levers being pulled before they bypass their cognitive filters[cite: 1436, 11068].

2. Webb’s Depth of Knowledge (DOK)

To distinguish between surface-level reporting and deep strategic intelligence, RA integrates Webb’s Depth of Knowledge (DOK) levels.

DOK-1 (Recall): Basic reporting of "who, what, where"[.
DOK-2 (Apply): Summarization and categorization without deep synthesis.
DOK-3 (Strategic Thinking): The "sweet spot" for intelligence, requiring causal modeling and the defense of positions against counterarguments.
DOK-4 (Extended Thinking): High-level synthesis that connects disparate domains, such as linking geopolitical shifts to long-term economic trends.

[cite_start]This hierarchy allows professional analysts—such as Geopolitical Risk Consultants and OSINT Specialists—to prioritize high-rigor content while filtering out low-value "regurgitated" news[cite: 12631, 7226].

II. The Pathos of Cognitive Defense (Pathos)

[cite_start]The information environment of 2026 is a battlefield where "credibility is currency"[cite: 3037]. [cite_start]For the individual, the pain point is "Source Fatigue" and the constant anxiety of being manipulated by unseen hands[cite: 6824, 12666].

[cite_start]Rhetoric Audit addresses this emotional friction by providing an "Aha!" moment of clarity[cite: 3727, 4644]. [cite_start]It positions itself as the partner for those tired of "guessing" at bias and ready for "knowing" the truth of a structure[cite: 1453, 3600]. [cite_start]The tool’s Propaganda Index and Pathos Alerts flag emotional loading and coordinated hashtag campaigns, protecting users from the "Disproportionate Contagion" of artificial narratives[cite: 4623, 11068].

III. The Ethos of PhD-Level Rigor (Ethos)

Credibility is built on transparency and technical accuracy. Rhetoric Audit establishes its Ethos through:

[cite_start]Academic Grounding: The tool is built by Palash Chandra Bagchi, bridging the gap between critical theory and high-speed computation with the analytical rigor of a Humanities PhD[cite: 6681, 11077].
[cite_start]Technical Benchmarks: RA boasts 96.7% accuracy on corpus-validated political leanings[cite: 11067].
[cite_start]Institutional Triangulation: By cross-referencing high-velocity social signals (the "Adversaries") with institutional ground truths like SEC EDGAR filings and Yahoo Finance, RA detects "Rhetorical Dissonance"[cite: 4622, 4735, 4810]. [cite_start]This source hierarchy (SEC: 98/100 weight, Yahoo: 92/100) ensures that boardroom reality is never drowned out by social media noise[cite: 4334, 7796].

IV. RA as an AI Safety Layer

In the development of large language models (LLMs), "alignment" is often synonymous with politeness. However, true AI safety requires a layer that can detect when a model—or the data it is trained on—is being used to disseminate coordinated propaganda.

Rhetoric Audit acts as this safety layer by:

[cite_start]Detecting Coordinated Behavior: RA identifies "temporal clustering" (multiple posts appearing within minutes) to unmask bot-driven amplification campaigns[cite: 4599, 4811].
[cite_start]Strategic Silence Detection: Perhaps its most powerful feature, RA doesn't just audit what is present; it identifies what has been tactically omitted to shape public opinion[cite: 3039, 11069]. [cite_start]Identifying what is missing is the hallmark of professional intelligence work[cite: 7216].

V. RA as a Prompt Auditing System

[cite_start]For developers building agentic workflows, Rhetoric Audit serves as a Universal Normalizer and logic auditor[cite: 4628, 4709].

[cite_start]The Universal Schema: Every signal, whether from X, Reddit, or SEC filings, is reshaped into a strict NormalizedSignal schema before touching the LLM[cite: 4369, 7822]. [cite_start]This prevents "Schema Chaos" and ensures the analysis engine receives clean, high-fidelity data[cite: 4632].
[cite_start]Dissonance Gauges: The system can be programmed to flag "High Rhetorical Dissonance" when social sentiment (e.g., "Anger" on Reddit) clashes with corporate stability reported in official filings[cite: 4721, 4811].

VI. RA as a Bias Detection Pipeline

[cite_start]The RA Bias Spectrum Mapping provides a granular look at the ideological framework of any text, moving from "Far Left" to "Far Right" with precision[cite: 11067].

[cite_start]Ideological Coding: The pipeline identifies the underlying worldview (e.g., Neoliberalism, Realism) used by an author to filter facts[cite: 3984, 7437].
[cite_start]The "Expert vs. Adversary" Polarity: By calculating a "Narrative Asymmetry" score, RA determines if the news cycle is ignoring a risk that is already trending in "adversarial" social communities[cite: 4643, 4772].

Conclusion: The Expert in the Room

[cite_start]Rhetoric Audit is not just another browser extension; it is a Forensic Cockpit for the information age[cite: 12706, 7799]. [cite_start]It transforms a "Report" into a "Forensic Presentation," providing the "So what?" that high-stakes decision-makers—from Portfolio Managers to PR Strategists—require to navigate a volatile world[cite: 4047, 4053, 7600].

[cite_start]For the developer, RA offers a stable, provider-agnostic architecture (utilizing Supabase, Apify, and RapidAPI) that can out-iterate competitors by focusing on the "logic pathology" of persuasion[cite: 3825, 8705, 8710]. In a world of noise, Rhetoric Audit is the tool for those who refuse to be manipulated. Stop Reading. [cite_start]Start Auditing.[cite: 3127, 6581].

DEV Community: Palash Bagchi

Beyond Left vs. Right: Engineering Reproducible Detection of Media Bias and Propaganda

How do you prove which AI agent did what? We open-sourced our answer

What Kakunin does

What's open

What's hosted, and why we're telling you plainly

Why AGPL

Try it in 60 seconds

Where this is going

The Anatomy of a Machine's Mind - Decoding AEO, GEO

1. The Entity Truth Layer: Knowledge Graph Search API (AEO)

The API: Google Knowledge Graph Search API

1. What are "People, Places, and Organizations"?

2. Expanding the 3 Core Data Points

A. @id (The Machine-Readable Entity ID or MREID)

B. detailedDescription (The Factual Payload)

C. resultScore (The Salience & Probability Metric)

Simulating the Knowledge Graph

2. The Semantic Vector Layer: Google Cloud Natural Language API (GEO)

The API: Google Cloud Natural Language API

1. Syntax Analysis (The Dependency Tree)

2. Entity Sentiment Analysis (Contextual Bias)

3. Content Classification v2 (The Taxonomy Filter)

The Ultimate GEO Metric: "RAG-Readiness" (Content Chunking)

3. The Visibility Layer: Google Search Console API (The Blindspot)

1. The New API Filter: Isolating the Machine

2. The Metric Mutation (Traditional vs. GEO)

3. The Fine-Grained Architecture of a GEO Impression

4. Building the GEO Feedback Loop

1. The Backend: The GEO API Route

2. The Frontend: The Stripe-Inspired Dashboard

Architectural Deployment Notes

4. The Testing Engine: Google Gemini API / Vertex AI (Simulation)

The API: Gemini API (via Google AI Studio or Vertex AI)

1. The Data Points: The Anatomy of a Machine's Mind

The JSON Payload (What it actually looks like)

2. The Enrichment Play: The "Share of Model" Tracker

3. The Variance Data Points ("The Gotchas")

Step 1: Install the SDK

Required Environment Configurations

Step 2: The Citation Tracker Script

How to Run and Interpret This Data

The Enrichment Play (What to do next)

The Architectural "Gotcha" of the GEO Era: Zero-Click Variance

1. Google Knowledge Graph Search API (AEO Layer)

2. Google Cloud Natural Language API (GEO Semantic Vector Layer)

3. Google Search Console API (Visibility Layer)

4. Google Gemini API / Vertex AI (Simulation & Grounding Layer)

Honorable Mention: Supplemental Reference

Non-Human Identity (NHI) in 2026: The Hidden Backbone and Biggest Risk in the Age of Agentic AI

Non-Human Identity (NHI) in 2026: The Hidden Backbone and Biggest Risk in the Age of Agentic AI

What Are Non-Human Identities?

Why NHI Security Has Become Critical in 2026

Best Practices for Non-Human Identity Management (NHIM)

Beyond Cybersecurity: Legal Personhood for Non-Humans

Philosophical Reflections on Identity

The Road Ahead: Recommendations for Leaders

Final Thought

The Identity Crisis of AI Agents — And Why Kakunin Might Be Early to a Very Big Market

Simple database of active, authorized model hashes in production

From Vibe-Coding to Data-Driven: Bringing Observability to AI-Built Software

The "Black Box" Problem in AI Dev

How It Works: The Blueprint to Build Pipeline

1. The Build-Ready Blueprint

2. Claude Connect: Terminal-Level Tracing

3. GitHub Observability

The Results: Real Data from the Field

But... Is My Code Safe?

The Verdict: Why You Should Care

What is the best way to build a simple AI chat support for my website, that can use my website, and blog as a KB, and actively assist customers via a chat interface?

Beyond the Fact: Rhetoric Audit as the Forensic Cockpit for Cognitive Defense

I. The Logic of Forensic Media Evaluation (Logos)

1. The 13-Parameter Audit

2. Webb’s Depth of Knowledge (DOK)

II. The Pathos of Cognitive Defense (Pathos)

III. The Ethos of PhD-Level Rigor (Ethos)

IV. RA as an AI Safety Layer

V. RA as a Prompt Auditing System

VI. RA as a Bias Detection Pipeline

Conclusion: The Expert in the Room

A. `@id` (The Machine-Readable Entity ID or MREID)

B. `detailedDescription` (The Factual Payload)

C. `resultScore` (The Salience & Probability Metric)