🤝 Open to Collab

Dipankar Sarkar PRO

dipankarsarkar

7 1777 345

https://www.dipankar.cc

AI & ML interests

Building the AI-native stack. Agents as infrastructure, safety as architecture, performance as plumbing. I publish the receipts: papers, datasets, demos.

Recent Activity

reacted to kanaria007's post with 🔥 1 minute ago

✅ Article highlight: *Proof-Carrying Messages, Claim Packets, and Redress Triggers* (art-60-315, v0.1) TL;DR: This article argues that not every message is “just communication.” Some messages carry proof. Some publish claims others may rely on. Some trigger dispute, reopen, or remedy. 315 separates those surfaces so delivery, evidentiary sufficiency, challengeability, and redress routing do not silently collapse into one thing. Read: https://huggingface.co/datasets/kanaria007/agi-structural-intelligence-protocols/blob/main/article/60-supplements/art-60-315-proof-carrying-messages-claim-packets-and-redress-triggers.md Why it matters: • prevents “attachment received” from meaning “proof accepted” • prevents “claim published” from meaning “safe to rely on” • prevents harm reports from disappearing into generic support queues • connects communication to audit, reopen, and remedy paths • makes correction and challengeability part of claim dissemination What’s inside: • proof-carrying messages • claim packet profiles • redress-trigger envelopes • separate transport acknowledgment and proof acceptance • proof-to-audit, claim-to-audit, and redress-to-audit linkage • routing by consequence rather than payload shape • worked examples for benchmark evidence, public corrections, harm reports, and federated disputes Key idea: Do not say: *“the message was delivered.”* Ask: *“Was the proof accepted? Is the claim challengeable? Did the harm report enter a reopen or remedy path? And can all of that be reconstructed later?”* Communication is not one surface. Proof, claims, and redress carry different governance consequences.

liked a dataset 2 minutes ago

JevAgentHarness/AgentDecisionBench

liked a dataset about 1 hour ago

klein-ml/klein-code-bench

View all activity

Organizations

Posts 4

Post

312

Privacy is moving ad decisions onto the device. The auction runs locally, next to the context it scores.

The budget still lives on a server.

So every device bids against the balance it saw at its last sync. Between syncs, campaigns spend money they no longer have.

I simulated how much that costs: 50 devices, 36 campaigns, about 300,000 auctions per run, 30 seeds per cell, budgets frozen before evaluation. Even pacing, second-score payment:

- Sync every tick: spend lands 18% over budget (32% with iPinYou-calibrated values).
- Sync every 10 ticks: 5.8 times the budget.
- Sync every 50 ticks: 17.7 times the budget (10.1 times with iPinYou-calibrated values).

Zero-lag sync stays within about 1%. The lag alone does the damage.

The incentive side runs the other way. With second-score payment and zero lag, 98% of auctions are manipulable (92% with iPinYou values). Switch the payment rule to critical-bid and that drops to 0 at every sync interval, in both setups.

Sync fixes the budget. The payment rule, not the sync interval, is what removes manipulability.

All 12 result sets are on the Hub, plus the 50,808 context labels every run samples from.

Paper: When Privacy Moves ML-Mediated Decisions On Device: Information and Incentive Misalignment in Auctions (2609.33312)
Dataset: skelfresearch/on-device-auction-audit
Code: https://github.com/sarkar-dipankar/on-device-auction-audit

If your ads stack moves on device, how often does the device learn its budget?