DEV Community: Ranjan Kumar

𝐂𝐨𝐦𝐩𝐥𝐢𝐚𝐧𝐜𝐞, 𝐀𝐮𝐝𝐢𝐭 𝐓𝐫𝐚𝐢𝐥𝐬, 𝐚𝐧𝐝 𝐑𝐞𝐠𝐮𝐥𝐚𝐭𝐨𝐫𝐲 𝐑𝐞𝐪𝐮𝐢𝐫𝐞𝐦𝐞𝐧𝐭𝐬 𝐟𝐨𝐫 𝐀𝐠𝐞𝐧𝐭𝐢𝐜 𝐒𝐲𝐬𝐭𝐞𝐦𝐬

Ranjan Kumar — Tue, 25 Aug 2026 11:15:05 +0000

The EU AI Act's full enforcement is near. If your agents touch credit decisions, employment screening, or regulatory reporting, you're in scope. The gap between running agents and running auditable agents is not a documentation problem - it's architectural.

Most teams have logs. Regulators need audit trails. These are not the same thing.

Logs are mutable, unstructured, and missing the fields regulators need - model version, policy version, integrity hash, reviewer identity, intervention points. An audit trail is immutable, correlated across agents, attributed to specific versions, and queryable on demand. A standard logging system satisfies none of Articles 9, 12, 13, 14, or 15 of the EU AI Act.

The technical obligations are concrete. Article 12 demands record-keeping with sufficient detail to reconstruct decision paths. Article 13 requires transparency - tracing every output back to its inputs and model version. Article 14 requires structured human oversight points, not theoretical ones. Article 9 demands active, ongoing risk assessment. Teams that built agents without these properties now face structural rework.

The fix is not adding audit fields to log messages. It's an architectural shift - an immutable audit trail integrated with your agent registry, policy gates, and human oversight interrupts. Each record must capture inputs, outputs, tool calls, policy decisions, and human interventions. Every field must be queryable. Nothing can be modified after creation.

This is what separates compliance theatre from actual auditability.

𝐑𝐞𝐚𝐝 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐠𝐮𝐢𝐝𝐞: https://ranjankumar.in/ai-control-plane-compliance-audit-trails-regulatory-requirements

𝐹𝑜𝑙𝑙𝑜𝑤 𝑓𝑜𝑟 𝑚𝑜𝑟𝑒 𝑜𝑛 𝑏𝑢𝑖𝑙𝑑𝑖𝑛𝑔 𝑝𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑜𝑛 𝑎𝑔𝑒𝑛𝑡𝑖𝑐 𝑠𝑦𝑠𝑡𝑒𝑚𝑠 𝑡ℎ𝑎𝑡 𝑠𝑐𝑎𝑙𝑒 𝑤𝑖𝑡ℎ𝑜𝑢𝑡 𝑏𝑟𝑒𝑎𝑘𝑖𝑛𝑔.

AICompliance #AuditTrail #EUAIAct #AgenticAI #MLOps #Regulatory #ControlPlane

𝐙𝐞𝐫𝐨 𝐓𝐫𝐮𝐬𝐭 𝐀𝐠𝐞𝐧𝐭𝐬: 𝐖𝐡𝐲 '𝐕𝐞𝐫𝐢𝐟𝐲 𝐄𝐯𝐞𝐫𝐲 𝐓𝐨𝐨𝐥 𝐂𝐚𝐥𝐥' 𝐈𝐬 𝐭𝐡𝐞 𝐎𝐧𝐥𝐲 𝐃𝐞𝐟𝐞𝐧𝐬𝐢𝐛𝐥𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞

Ranjan Kumar — Tue, 25 Aug 2026 05:16:34 +0000

You deployed an agent with proper access controls, a well-scoped system prompt, and it worked fine for months. Then a customer sent a link. The agent fetched it. The link contained instructions to leak data. The agent complied. Access controls didn't stop it because access controls don't verify intent - they only verify identity.

This is the core problem: agent behavior emerges from runtime context you don't control. Trusting an agent's decision because you trust its credentials is like trusting a person because you verified their ID. It misses what actually matters - not who is acting, but whether this specific action should happen now.

The shift required is architectural. Traditional security establishes a trust perimeter, verifies permissions once, then trusts all actions within that perimeter. Agents need the opposite: assume every decision is potentially compromised by untrusted context in the window, verify every tool call independently, scope every execution. No exceptions.

This means inserting a verification gateway between decision and execution. The agent proposes actions. A policy engine validates them against explicit rules. A context analyzer checks what influenced the decision. Only verified calls execute, and those execute with minimal credentials and resource limits. Every decision - approve or deny - is logged for audit.

The hard part isn't building the gateway. It's making verification cheap enough that teams actually use it. If verification is slow or expensive, production pressure creates shortcuts, and shortcuts become breaches.

Read the full architecture, implementation patterns, and how to scope tool execution properly:

https://ranjankumar.in/zero-trust-agents-why-verify-every-tool-call-is-the-only-defensible-architecture

Follow for more practitioner-focused pieces on agentic systems and production AI security.

ZeroTrust #AIAgents #SecurityArchitecture #ToolCalling #ProductionSecurity #LLMSecurity #RuntimeSecurity

𝐅𝐢𝐯𝐞 𝐒𝐭𝐚𝐠𝐞𝐬 𝐚𝐭 𝟗𝟓 𝐏𝐞𝐫𝐜𝐞𝐧𝐭 𝐈𝐬 𝐍𝐨𝐭 𝟕𝟕 𝐏𝐞𝐫𝐜𝐞𝐧𝐭

Ranjan Kumar — Mon, 24 Aug 2026 13:03:49 +0000

You've seen it happen in design review - someone pulls out a calculator, multiplies 0.95^5, gets 0.77, and suddenly the entire pipeline architecture is dead. Three months of work pivots to agents based on eleven seconds of arithmetic.

That math is correct. But the compounding-error argument has a fatal flaw: it's computed for the option you're rejecting, never for the option you're authorizing.

Here's what actually matters:

𝐋𝐮𝐬𝐬𝐞𝐫'𝐬 𝐋𝐚𝐰 𝐡𝐚𝐬 𝐚 𝐩𝐫𝐞𝐜𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧. The product rule for reliability only holds if stage failures are statistically independent. Nobody checks that precondition anymore. Real pipelines share inputs, models, prompts, and retry logic - stages fail together, not independently.
𝐓𝐡𝐞 𝐜𝐚𝐥𝐜𝐮𝐥𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐚𝐬𝐲𝐦𝐦𝐞𝐭𝐫𝐢𝐜. 0.95^5 = 0.77 gets computed exactly once, to kill the pipeline option. Nobody runs the same math on agent reliability, error recovery loops, or hallucination rates under dynamic execution. You're comparing a measured number against an unmeasured one.
𝐓𝐡𝐞 𝐟𝐨𝐫𝐦𝐮𝐥𝐚 𝐝𝐞𝐦𝐚𝐧𝐝𝐬 𝐢𝐧𝐟𝐨𝐫𝐦𝐚𝐭𝐢𝐨𝐧 𝐢𝐭 𝐧𝐞𝐯𝐞𝐫 𝐚𝐬𝐤𝐬 𝐟𝐨𝐫. Does the pipeline succeed when all stages work, or when any one works? Can later stages undo earlier mistakes? Do shared inputs create correlated failures? The calculator takes none of this as input and returns a number anyway.
𝐃𝐞𝐩𝐞𝐧𝐝𝐞𝐧𝐜𝐞 𝐜𝐮𝐭𝐬 𝐛𝐨𝐭𝐡 𝐰𝐚𝐲𝐬. When stages fail together because they share an input, the correlation can actually improve reliability - a bad input fails fast instead of cascading. But you'll never know, because the arithmetic stops at 0.77.

The real decision isn't pipeline vs. agent. It's whether you've measured the actual reliability of your system under your conditions. The compounding-error argument lets you skip that work by converting an unexamined assumption into a number that looks like evidence.

Read the full analysis here:

https://ranjankumar.in/genai-architectures-level-3-compounding-error-arithmetic

Follow for more practitioner-focused architecture breakdowns.

GenAIArchitecture #LLMSystems #ReliabilityEngineering #SystemDesign #AIArchitecture #MLEngineering #ProductionAI

𝐖𝐡𝐲 𝐘𝐨𝐮𝐫 𝐀𝐈 𝐀𝐠𝐞𝐧𝐭 𝐅𝐢𝐧𝐢𝐬𝐡𝐞𝐬 𝐓𝐚𝐬𝐤𝐬 𝐁𝐮𝐭 𝐅𝐚𝐢𝐥𝐬 𝐭𝐡𝐞 𝐆𝐨𝐚𝐥

Ranjan Kumar — Mon, 24 Aug 2026 06:03:21 +0000

Your agent completes every task. The execution log is clean. But the outcome is wrong.

This happens when you treat the task list as static config - defined upfront, never revised, regardless of what the agent actually discovers mid-execution. The plan becomes the goal, and mid-course signals get ignored because they weren't on the original list.

The real decision you never consciously made:

Does the next task depend only on whether the previous one completed, or on what it actually found?

That distinction maps to three patterns. Execution Contract (fixed plan, deterministic). Discovery Hypothesis (evolving plan, learning-driven). Hybrid Boundary (designed handoff between them).

Most teams default to the first because it's simple. It works fine until the problem requires adaptive reasoning - then it fails silently.

A task list isn't just a workflow artifact. It's how you externalize the reasoning structure that lives inside an LLM's ephemeral forward pass into persistent, inspectable state. Get this wrong and your agent optimizes for task completion, not goal achievement.

Read the full breakdown on the tradeoffs and how to choose the right pattern for your system:

https://ranjankumar.in/why-your-ai-agent-finishes-tasks-but-fails-the-goal

Follow for more practitioner-focused insights on building agents that actually work.

AIAgents #LLMEngineering #MultiStepReasoning #ProductionAI #AgentArchitecture #SystemDesign

𝐎𝐧-𝐃𝐞𝐯𝐢𝐜𝐞 𝐀𝐈 𝐃𝐨𝐞𝐬𝐧'𝐭 𝐑𝐞𝐦𝐨𝐯𝐞 𝐭𝐡𝐞 𝐀𝐭𝐭𝐚𝐜𝐤 𝐒𝐮𝐫𝐟𝐚𝐜𝐞. 𝐈𝐭 𝐒𝐡𝐢𝐩𝐬 𝐈𝐭.

Ranjan Kumar — Fri, 21 Aug 2026 15:55:27 +0000

𝐎𝐧-𝐃𝐞𝐯𝐢𝐜𝐞 𝐀𝐈 𝐃𝐨𝐞𝐬𝐧'𝐭 𝐑𝐞𝐦𝐨𝐯𝐞 𝐭𝐡𝐞 𝐀𝐭𝐭𝐚𝐜𝐤 𝐒𝐮𝐫𝐟𝐚𝐜𝐞. 𝐈𝐭 𝐒𝐡𝐢𝐩𝐬 𝐈𝐭.

Here is what happened in September 2025, and why it should change how you think about the on-device AI systems you're shipping.

Researchers pulled the model out of SafetyCore, Google's on-device safety classifier in Android Messages. They extracted the weights, converted the architecture, and manipulated the detector to bypass itself. The privacy design that moved inference to the device to protect user data handed every attacker a local, inspectable, differentiable copy of the exact safety control Google wanted to hide.

The privacy win was real. The operational loss was not optional.

𝐓𝐡𝐞 𝐜𝐨𝐫𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐲𝐨𝐮 𝐟𝐚𝐜𝐞: on-device AI does not remove your attack surface. It relocates it onto hardware an attacker owns. Worse, it breaks your ability to revoke, observe, or patch model behavior across your fleet. Privacy moves to a boundary you no longer control. Operational liability does not move with it.

𝐖𝐡𝐚𝐭 𝐠𝐨𝐯𝐞𝐫𝐧𝐬 𝐞𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 𝐞𝐥𝐬𝐞 - 𝐭𝐡𝐞 𝐑𝐞𝐯𝐨𝐜𝐚𝐭𝐢𝐨𝐧 𝐇𝐨𝐫𝐢𝐳𝐨𝐧. In cloud inference, the next request runs your fixed model. On-device, your model runs whether it checked in or not. The time between deciding to change behavior and the last device actually running that change is the window where jailbreaks stay live, guardrails stay loose, and regulatory requirements stay unmet. Apple reaches 79% of all iPhones in nine months. Android sits at 25% adoption thirteen months after release. That is your hard ceiling, and you do not get to know the tail.

A cloud-era safety story does not survive contact with a device. Every control that worked in server inference becomes a local attestation problem the instant the model runs in the user's pocket. Token verification, rate limiting, feature gating, refusal patterns - all of it assumes a server you control can enforce what the model does. On-device, the user owns the boundary. The attacker owns the code path.

The privacy argument for on-device is sound. What is false is the inference people draw from it - that putting data on the device means there is nothing left to defend, nothing left to operate. Both readings are wrong. You still have attack surface. You still have observability debt. You just cannot reach either one.

𝐑𝐞𝐚𝐝 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐛𝐫𝐞𝐚𝐤𝐝𝐨𝐰𝐧 𝐨𝐟 𝐭𝐡𝐞 𝐑𝐞𝐯𝐨𝐜𝐚𝐭𝐢𝐨𝐧 𝐇𝐨𝐫𝐢𝐳𝐨𝐧, 𝐦𝐨𝐝𝐞𝐥 𝐞𝐱𝐭𝐫𝐚𝐜𝐭𝐢𝐨𝐧 𝐫𝐢𝐬𝐤, 𝐚𝐧𝐝 𝐡𝐨𝐰 𝐭𝐨 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐛𝐮𝐢𝐥𝐝 𝐬𝐚𝐟𝐞𝐭𝐲 𝐜𝐨𝐧𝐭𝐫𝐨𝐥𝐬 𝐭𝐡𝐚𝐭 𝐬𝐮𝐫𝐯𝐢𝐯𝐞 𝐛𝐞𝐢𝐧𝐠 𝐬𝐡𝐢𝐩𝐩𝐞𝐝 𝐭𝐨 𝐞𝐯𝐞𝐫𝐲 𝐝𝐞𝐯𝐢𝐜𝐞 𝐢𝐧 𝐲𝐨𝐮𝐫 𝐟𝐥𝐞𝐞𝐭.

https://ranjankumar.in/on-device-ai-privacy-attack-surface

Follow for more practical AI engineering writing on tradeoffs people actually face in production.

OnDeviceAI #AISecurit #MLEngineering #EdgeAI #ModelSecurity #AIArchitecture #PlatformEngineering

𝐌𝐨𝐝𝐞𝐥 𝐂𝐨𝐥𝐥𝐚𝐩𝐬𝐞 𝐌𝐨𝐯𝐞𝐝: 𝐑𝐀𝐆 𝐈𝐬 𝐖𝐡𝐞𝐫𝐞 𝐈𝐭'𝐬 𝐎𝐩𝐞𝐧

Ranjan Kumar — Fri, 21 Aug 2026 05:57:37 +0000

Your frontier model was trained on 30-40% synthetic data and it works fine. Your retrieval-augmented generation corpus is where the loop never closed, and every eval metric you're running is structurally blind to it.

Here's what happened. In 2024, researchers ran a simple experiment - feed an LLM's answers back into your retrieval corpus, retrieve again, repeat ten times. By iteration ten, human-written text fell from 77.7% to 5.8%. Retrieval accuracy dropped 19-21%. But exact match stayed flat. Every dashboard stayed green over a corpus that had been hollowed out.

That's model collapse arriving through your retrieval layer instead of training, and it's the version almost nobody is watching for.

𝐓𝐡𝐞 𝐫𝐞𝐚𝐥 𝐬𝐩𝐥𝐢𝐭 𝐭𝐡𝐚𝐭 𝐦𝐚𝐭𝐭𝐞𝐫𝐬 - 𝐚𝐜𝐜𝐮𝐦𝐮𝐥𝐚𝐭𝐢𝐨𝐧 𝐯𝐞𝐫𝐬𝐮𝐬 𝐫𝐞𝐩𝐥𝐚𝐜𝐞𝐦𝐞𝐧𝐭. Frontier labs solved this. They don't replace training data, they accumulate it. Stanford proved that accumulation produces bounded error independent of iteration count. Replacement degrades linearly. That's why Llama and GPT variants trained on 97% synthetic multilingual data work. That's not your RAG system.

𝐘𝐨𝐮𝐫 𝐞𝐯𝐚𝐥 𝐬𝐭𝐚𝐜𝐤 𝐡𝐚𝐬 𝐚 𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐚𝐥 𝐛𝐥𝐢𝐧𝐝 𝐬𝐩𝐨𝐭. Correctness and provenance are independent properties. You measure the first one. A retrieved answer can be right and come entirely from machine-generated text. You need different instrumentation - tracking provenance chains, measuring source diversity decay, detecting when your corpus has shifted from human to synthetic dominance without waiting for accuracy to fall off a cliff.

The arithmetic forbids detection as your defense. By the time your metrics break, your corpus has already been replaced. You need to measure the corpus itself, not just its output.

Read the full analysis on how frontier labs manage synthetic data, why accumulation prevents collapse, and what metrics actually catch it before your retrieval breaks.

https://ranjankumar.in/the-ai-ouroboros-how-gen-ai-is-eating-its-own-tail

Follow for more practitioner-focused writing on RAG systems, LLM infrastructure, and real-world failure modes.

RAG #ModelCollapse #SyntheticData #LLMInfrastructure #DataQuality #AIEngineering #Evaluation

𝐂𝐥𝐚𝐮𝐝𝐞'𝐬 𝐖𝐚𝐭𝐞𝐫𝐦𝐚𝐫𝐤 𝐈𝐬𝐧'𝐭 𝐋𝐢𝐯𝐞. 𝐘𝐨𝐮𝐫 𝐏𝐫𝐨𝐯𝐞𝐧𝐚𝐧𝐜𝐞 𝐃𝐞𝐛𝐭 𝐈𝐬.

Ranjan Kumar — Wed, 19 Aug 2026 11:35:06 +0000

𝐂𝐥𝐚𝐮𝐝𝐞'𝐬 𝐖𝐚𝐭𝐞𝐫𝐦𝐚𝐫𝐤 𝐈𝐬𝐧'𝐭 𝐋𝐢𝐯𝐞. 𝐘𝐨𝐮𝐫 𝐏𝐫𝐨𝐯𝐞𝐧𝐚𝐧𝐜𝐞 𝐃𝐞𝐛𝐭 𝐈𝐬.

Open your model picker. Opus 5 shipped 24 July 2026. Sonnet 5 on 30 June. Fable 5 on 9 June. Every Claude model you can select today launched before 2 August 2026 - the date Anthropic set for watermarking to begin. Nothing you generated this month is marked. Nobody can check anything. Both facts have an expiry date.

The core problem: you are about to mix marked and unmarked Claude output in your training corpora, fine-tuning datasets, retrieval indexes, and product copy. Without a generation timestamp on each row, you cannot separate them yourself. The only instrument that can is a detector owned by Anthropic - which means shipping your corpus to the vendor to ask.

I call this Provenance Debt. It is the liability you take on when vendor-marked output enters an asset you own, and you keep no record of which is which. You cannot read the balance because the detector belongs to the vendor. You cannot pay it down afterwards because the only payment is a record you had to write at generation time. Ordinary technical debt gives you both.

Here is what actually matters for your infrastructure:

Anthropic scoped watermarking by model launch date, not calendar date. The detection API does not exist yet. Their own words: "We will soon be offering a watermark detection API. We're in the process of working out the details of its implementation."
No opt-out is documented - not a header, not a setting, not an enterprise carve-out. The marking is global because it is driven by EU AI Act Article 50(2), which became applicable on 2 August 2026.
Existing SynthID-Text research shows watermarks are cheaper to strip than other schemes. This is not about watermark robustness. It is about the provenance record you did not write, cannot recover, and now own liability for.
The window is now. Every byte you generate before marking starts is permanently unmarked and unrecorded. When marked bytes arrive, you cannot separate them.

Audit your generation timestamps today. Write down what you own and when it was generated. Build that into your pipeline before the cutoff matters.

Read the full breakdown:

http://ranjankumar.in/claude-watermark-provenance-debt-training-data

Follow for more practitioner-focused AI engineering writing on provenance, infrastructure, and vendor decisions.

ClaudeAI #AIEngineering #Provenance #DataLineage #EUAIAct #SyntheticData #MLOps

The 7 GenAI Architectures

Ranjan Kumar — Wed, 19 Aug 2026 10:08:32 +0000

https://7genai.ranjankumar.in/

𝐖𝐡𝐲 𝐘𝐨𝐮𝐫 𝐃𝐞𝐟𝐚𝐮𝐥𝐭 𝐁𝐫𝐚𝐧𝐜𝐡 𝐚𝐧𝐝 𝐘𝐨𝐮𝐫 𝐋𝐋𝐌 𝐀𝐫𝐞 𝐭𝐡𝐞 𝐒𝐚𝐦𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞

Ranjan Kumar — Wed, 19 Aug 2026 06:53:39 +0000

If you think deterministic code doesn't need a refusal path - you're watching two different systems fail in identical ways without realizing it.

Cloudflare's bot detection failure illustrates the trap perfectly. When input validation failed, the newer proxy crashed. The older one returned a bot score of zero - a decision it had no basis for. Both were failures. But they were failures of the same underlying architecture: a path that always answers, whether it should or not.

Here's what most teams get wrong about the Level 0 floor:

𝐈𝐭'𝐬 𝐧𝐨𝐭 𝐚𝐛𝐨𝐮𝐭 𝐭𝐡𝐞 𝐚𝐛𝐬𝐞𝐧𝐜𝐞 𝐨𝐟 𝐚 𝐦𝐨𝐝𝐞𝐥. A default branch that always fires is not simpler than an LLM fallback - it's the same architecture wearing different clothes. Both invent answers where no rule applied. Both hand the caller a result indistinguishable from a decided answer. Both have coverage of 1.0 by construction, which means coverage tells you nothing.

The real floor is explicit refusal. A system with an intentional "I cannot answer this" path - one that declares which inputs it can handle and routes the rest somewhere else - that's Level 0. A rules router with a catch-all default? You're already off the floor.

𝐓𝐡𝐞 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐦𝐞𝐚𝐬𝐮𝐫𝐞𝐦𝐞𝐧𝐭: Anthropic tells you to use the simplest thing and add complexity only when it demonstrably improves outcomes. That's directionally correct and operationally useless. You need a runtime measurement, not a design-time judgement. The deterministic implementation itself must measure coverage on real traffic and tell you when it hits its limit.

The question isn't whether to use an LLM. The question is whether you can close the domain and prove it. If you can't, your router needs to say so - not crash, not guess, but refuse explicitly and let something downstream decide what comes next.

Read the full breakdown:

https://ranjankumar.in/genai-architectures-level-0-deterministic-floor-refusal-path

Follow for more on production AI architecture.

GenAIArchitecture #AIEngineering #SystemDesign #Reliability #Production #MLOps #Deterministic

𝐇𝐨𝐰 𝐒𝐲𝐧𝐭𝐡𝐈𝐃 𝐖𝐨𝐫𝐤𝐬: 𝐁𝐮𝐢𝐥𝐝 𝐚 𝐖𝐚𝐭𝐞𝐫𝐦𝐚𝐫𝐤 𝐢𝐧 𝐏𝐲𝐭𝐡𝐨𝐧

Ranjan Kumar — Mon, 17 Aug 2026 09:28:59 +0000

Google's SynthID watermarks AI-generated text so it can be identified later. The mechanism is simpler than most coverage suggests - and this tutorial builds it from scratch.

The core problem: how do you mark text without degrading quality or making the mark obvious? The answer is elegant. A language model generates scores for 50,257 tokens at once. Before sampling, you split the vocabulary into green and red lists using a secret key and the previous token. Add a small constant to green tokens. The sampler picks from slightly-biased scores. The finished text contains more green tokens than chance predicts - but only if you have the key.

This tutorial builds that green-list watermark on GPT-2 and detects it from plain text alone at p = 3.07e-56. You'll measure how many tokens detection needs and how much editing it survives. By the end you'll run a detector that reads text and answers: watermarked or not, with statistical confidence.

The approach uses Kirchenbauer's green-list algorithm - not Google's tournament sampling, but the right thing to build first because you can implement, detect, and break it in an afternoon. Hugging Face transformers ships it natively so you can check your work. The closing section explains how the real thing differs.

Budget 45 minutes. You need Python 3.13, 1.5 GB of free disk, and no API keys. Everything is open source and runs locally.

Read the full walkthrough here:

https://ranjankumar.in/how-googles-synthid-actually-works-a-visual-breakdown

Follow for more practitioner-focused AI engineering guides.

SynthID #Watermarking #LLMs #AIEngineering #NLP #GPT2 #AISafety

𝐒𝐮𝐩𝐞𝐫𝐩𝐨𝐰𝐞𝐫𝐬 𝐏𝐥𝐮𝐠𝐢𝐧 𝐟𝐨𝐫 𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞: 𝐈𝐧𝐬𝐭𝐚𝐥𝐥 𝐚𝐧𝐝 𝐕𝐞𝐫𝐢𝐟𝐲

Ranjan Kumar — Wed, 12 Aug 2026 13:20:05 +0000

You installed the Superpowers plugin. But which skills actually fired? And what did it cost you in tokens?

Most AI engineers assume a plugin works because it loaded. That assumption is wrong. Superpowers injects a hook that tells your model to prefer certain skills - but a hook is a paragraph, not a guarantee. You need to prove which skills actually fired in each run, measure the token cost, and decide whether to keep it on everywhere or scope it off.

This guide walks you through installing Superpowers, building a detector that names exactly which skills fired on any Claude Code session, and running a real feature twice - once by hand, once through the plugin - so you see the difference in token cost and behavior. You'll also get a token budget for what the plugin charges every session, whether or not it does anything useful.

What you're really learning here is how plugins work. Superpowers is 14 skills and one hook. The hook is policy-as-code: it injects a paragraph into your model's context on every session start, telling Claude to check for an applicable skill before doing anything. Only the names and short descriptions stay in context. The full skill body loads on demand. If the hook doesn't run, the skills go dormant and your model ignores them. This is why a Windows box without Git Bash gets a plugin that reports itself as enabled and does nothing.

You'll need Claude Code 2.1.228+, Git 2.51.0+, Python 3.13.9+, and pytest 8.4.2+. Allow 45 minutes. The actual Claude API calls cost about 2-3 USD total - skip steps 6, 7, 8, 11, and 12 if you want to avoid the charge, though you'll lose live proof that a skill fired on your machine.

Read the full guide and build the detector yourself:

https://ranjankumar.in/superpowers-plugin-claude-code-setup-and-cost

Follow for more practitioner guides on AI engineering, agents, and Claude Code.

ClaudeCode #AIEngineering #Plugins #AgentSkills #Superpowers #MLEngineering #PractitionerGuide

𝐓𝐡𝐞 𝐂𝐡𝐚𝐭 𝐓𝐞𝐦𝐩𝐥𝐚𝐭𝐞𝐬 𝐇𝐚𝐧𝐝𝐛𝐨𝐨𝐤: 𝐴 𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑒𝑟'𝑠 𝐺𝑢𝑖𝑑𝑒 𝑡𝑜 𝐽𝑖𝑛𝑗𝑎, 𝑎𝑝𝑝𝑙𝑦𝑐ℎ𝑎𝑡𝑡𝑒𝑚𝑝𝑙𝑎𝑡𝑒, 𝑎𝑛𝑑 𝑅𝑒𝑛𝑑𝑒𝑟𝑖𝑛𝑔 𝑀𝑜𝑑𝑒𝑙-𝑅𝑒𝑎𝑑𝑦 𝑃𝑟𝑜𝑚𝑝𝑡𝑠

Ranjan Kumar — Wed, 12 Aug 2026 10:37:09 +0000

Your model passed every benchmark. Then it quietly got worse in production - and nothing in the logs explains why.

The usual culprit isn't the model. It's the chat template: the code that turns your list of messages into the exact tokens the model was trained on. Get it wrong and the model still answers - just worse, silently, with no error to chase.

I wrote a book on that layer.

𝐓𝐡𝐞 𝐂𝐡𝐚𝐭 𝐓𝐞𝐦𝐩𝐥𝐚𝐭𝐞𝐬 𝐇𝐚𝐧𝐝𝐛𝐨𝐨𝐤: 𝐴 𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑒𝑟'𝑠 𝐺𝑢𝑖𝑑𝑒 𝑡𝑜 𝐽𝑖𝑛𝑗𝑎, 𝑎𝑝𝑝𝑙𝑦𝑐ℎ𝑎𝑡𝑡𝑒𝑚𝑝𝑙𝑎𝑡𝑒, 𝑎𝑛𝑑 𝑅𝑒𝑛𝑑𝑒𝑟𝑖𝑛𝑔 𝑀𝑜𝑑𝑒𝑙-𝑅𝑒𝑎𝑑𝑦 𝑃𝑟𝑜𝑚𝑝𝑡𝑠

𝐼𝑛𝑠𝑖𝑑𝑒: rendering conversations the way the model was actually trained, reading and writing Jinja templates (including the whitespace bugs that silently break tokenization), handling tool-calling, reasoning, and multimodal templates, authoring a correct template for your own fine-tuned model, debugging with golden-token tests in CI, and fixing the cross-engine differences between Transformers, vLLM, and llama.cpp. There's a chapter on the security side too - chat templates are a real, documented inference-time attack surface.

If you ship LLM features, fine-tune open models, or serve them across multiple engines, this is written for you.

LLM #MachineLearning #AIEngineering #OpenSourceAI

Out now on Kindle:
IN: https://www.amazon.in/dp/B0H6STBYWT
US: https://www.amazon.com/dp/B0H6STBYWT