DEV Community: holistis

I built a judge that argues with itself before you submit a bug bounty finding

holistis — Tue, 11 Aug 2026 12:58:14 +0000

I built a judge that argues with itself before you submit a bug bounty finding

A few days ago I published data on what actually gets paid in smart contract audit contests. The short version: submitting everything you find is a bad strategy. Rejected and duplicate submissions cost you time, reputation, and sometimes a stake. Being selective about what you actually submit is worth more than volume.

So I built the tool I wish existed for that: Al-Mizaan Judge, a CLI that takes your finding and puts it through a strict, adversarial review before you spend a real Sherlock, Immunefi, or Cantina submission on it.

How it works

Two layers.

Mechanical gates run first, free, no API call. They catch the cheap, obvious kills: a trusted actor (owner/admin/governance) as the sole attacker, a deployer misconfiguration with no external attacker, an oracle-manipulation finding that never proves economic viability.

Adversarial debate runs for anything that survives that. A Defender agent argues the code is safe. An Attacker agent tries to break that defense. A Judge decides, walking through scope, reachability, threat model, invariant breach, protocol intent, and dollar impact in that order. If it goes three rounds, the final round restricts the Judge to only code citations that were mechanically checked against the code you actually provided. No rhetoric, only what's in the code. Doubt always defaults to KILL.

A real example

I ran it against a textbook reentrancy bug:

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "insufficient balance");
    (bool ok, ) = msg.sender.call{value: amount}("");
    require(ok, "transfer failed");
    balances[msg.sender] -= amount;
}

Verdict: SUBMIT CANDIDATE, 90 to 98% confidence across all three rounds.

The Vault.sol code is in scope, and withdraw() performs a classic checks-effects-interactions violation: it sends ETH via a low-level call before decrementing balances[msg.sender], with no reentrancy guard present. This is reachable by any untrusted external account, directly breaching the solvency/accounting invariant.

Then I ran it against a finding that sounds scary but isn't: an oracle that falls back to a manipulable TWAP during Chainlink downtime.

Verdict: LIKELY REJECTED, one round, 72% confidence.

Fails Gate 5 (Impact): no dollar/TVL quantification from either side. Additionally, the finding's trigger condition is fundamentally Chainlink-staleness-driven fallback behavior, which Sherlock's SJIP-21 rule marks invalid as a primary finding.

That second one matters. It didn't just say "seems fine," it cited the actual platform rule that kills this specific pattern on Sherlock. That's the difference between a generic "is this a bug" prompt and something that actually knows how contest judging works.

What it deliberately doesn't do

No code execution, no Foundry builds, no repo scanning, no hosting. You run it locally with your own Anthropic API key. Your code never leaves your machine except to the API you're already paying for directly.

Try it

export ANTHROPIC_API_KEY=sk-ant-...
npx al-mizaan-judge your-finding.md

Repo and full format docs: https://github.com/holistis/al-mizaan-judge

One honesty note, because I'd rather say this myself than have someone find it: the mechanical gates encode Sherlock's own published judging policy, not our own statistics. We haven't yet statistically validated verdicts against a large, representative outcome dataset, that corpus work is still in progress and I'll write about it when it's real. Until then, treat this as a strict second opinion grounded in real audit methodology, not a proven hit rate.

What actually gets paid in smart contract audit contests

holistis — Mon, 10 Aug 2026 15:33:56 +0000

I run a smart contract audit pipeline, and I keep a labeled record of what judges actually reward. I pulled 20,720 findings across 81 Sherlock contests and counted only the ones that carried a real Reward label. The thing that turned out to matter most was not the one I expected, and it corrected something I believed going in.

Most valid findings do get paid. The rate just swings wildly.

Across all 81 contests, 66 percent of submissions were rewarded. But that average hides the real story. Per contest, the paid rate ran from near 0 percent to near 99 percent, with a median of 60 percent. Twenty-three of the contests paid less than a quarter of submissions. Thirty-eight paid more than three quarters.

So the single biggest lever on your odds is not your skill or the bug you find. It is which contest you enter. Same researcher, same ability, wildly different outcome depending on the codebase, the field of competitors, and how strict the judging was.

The bug type barely matters. This was the surprise.

I expected the prestigious bugs, reentrancy and oracle manipulation, to separate cleanly from the boring ones. At 20,000 findings, they do not. Every major pattern pays inside a narrow band.

Pattern	Paid rate	Paid / submitted
liquidation	77%	1624 / 2118
fee miscalculation	76%	1601 / 2105
oracle manipulation	75%	1949 / 2586
mev / slippage	75%	1053 / 1410
flash loan	71%	330 / 465
rounding	70%	1480 / 2104
dos / griefing	70%	1828 / 2610
access control	68%	1241 / 1812
reentrancy	67%	548 / 820
overflow	66%	656 / 990
trusted actor	65%	4547 / 6948
staleness	65%	2983 / 4585

The whole spread from top to bottom is twelve points. The pattern you find is close to a rounding error next to the contest you picked. If you are choosing what to hunt based on which bug class feels most valuable, you are optimizing the wrong variable.

One category is worth a note for a different reason. Trusted actor is by far the largest, 6,948 submissions, nearly a third of everything. Most of it is people arguing that an owner or admin could misbehave. It pays about the same as the rest here, but in my own pipeline it is the category I reject most often, because when the only attacker is an already-trusted role, most programs do not treat it as a finding. High volume, ordinary hit rate.

Claiming High barely helps, and it rarely survives.

Findings submitted as High got paid 74 percent of the time. Findings submitted as Medium got paid 65 percent. A real but modest gap.

The bigger tell is what happens to the label. Only 10 percent of findings submitted as High actually ended up rated High. The other 90 percent were downgraded or dropped. The market over claims severity by a wide margin, and the judges cut most of it back down.

Even when you win, sometimes you split the pot.

17 percent of the findings that got paid were duplicates. Real bugs, but someone else reported the same thing, so the reward was shared. It is not the majority, but it is common enough that finding a bug others will also find is worth less than finding one they will miss.

What this is, and what it is not

The sample is 20,720 findings across 81 fully crawled Sherlock contests from 2024. Every one of these contests has its complete finding list, not a partial crawl. It is one platform and one year, so treat it as a large slice, not the whole market.

I count a finding as paid only if it carries the Reward label in the public judging result. That counts each individual submission, including duplicate submitters who shared a payout. Confirmed but unrewarded, disputed, and rejected all count as not paid.

Each finding is tagged by bug class from its title and judge notes. Reasonable people would tag a few differently. The direction of the numbers is what matters, not the second decimal.

One honest note on method, because it is the whole point. I first ran this on a small set of 10 contests and got a very different picture, a low overall pay rate and reentrancy on top. When I widened it to 81 contests, both of those flipped. The small sample happened to be full of low paying contests. That is exactly why the contest you pick matters more than the pattern, and it is a good reminder that a clean looking number from a small sample can point the wrong way.

Try it

The skill all of this rewards is judgment: before you spend a submission on a finding, knowing whether it will actually be rewarded, or whether it is a dup, a known issue, or an argument the judges will wave away. I built the judge I use for exactly that, and it is live and free to run:

npx al-mizaan-judge

It runs your finding through a strict 7-gate validity check and tells you where it would fail and why, before you spend the submission. Package: https://www.npmjs.com/package/al-mizaan-judge

If the verdict surprises you, or you just want the full data behind this, leave a comment or reach out. I read everything.

Your AI-built app is impressive. It is just not yours yet.

holistis — Sun, 09 Aug 2026 16:37:52 +0000

A pattern I keep seeing: someone builds a real, working product in a weekend using Lovable, Bolt, Replit Agent, or Manus. It looks great, it works, people sign up. Then they hit the wall nobody warned them about.

The code doesn't live in a repo they control. It lives inside the platform. Want to add a developer to the team who isn't inside that tool's workflow? Want to self-host, or move to a different host? Want to just git clone it and work on it in your own editor like a normal codebase? Often you can't, not cleanly. You're renting your own product.

That's not a knock on those tools — they're genuinely good at getting from zero to a working prototype fast. But "fast to build" and "yours to keep" turned out to be two different problems, and most of these platforms only solve the first one.

What "owning it" actually requires

Three things, mainly:

A real GitHub repo, not an export button that dumps a zip once and calls it done.
A history that makes sense — commits, not a single "initial state" blob you can't diff against.
A way to keep improving it that doesn't require going back through the platform that built it.

What I built: MergeFix

I built MergeFix to solve exactly this. The "Migrate & Own" flow takes whatever you've got — AI-built or not, existing GitHub repo or none at all — and puts it into a repo you fully own, no lock-in, no dependency on us to keep working. If you already have a GitHub repo, it's a normal PR-based handoff. If you don't (which is the common case coming out of an AI builder), it crawls your live site and bootstraps a real repo from it, first commit onward.

Once it's in your repo, the same underlying engine can keep working for you: continuous audits for SEO, performance, accessibility and security, shipped as actual pull requests you review and merge — not a dashboard telling you things are wrong with no fix attached.

The honest way to think about it: migration gets you ownership. The ongoing subscription (Pro/Scale) is optional maintenance on top, only if you want it — there's no obligation to keep paying us once your code is yours.

If you want to try Migrate & Own for free

I'm running a genuinely time-boxed offer while this is fresh: code MIGRATEFREE gives 100% off Migrate & Own, valid through August 16, capped at 25 uses. Not a fake countdown — those are the real limits.

If you've built something with an AI app builder and it's starting to feel like it isn't quite yours, I'd like to hear about it either way — happy to look at your specific setup even if MergeFix isn't the right fit.

A payment gateway for MCP servers, and the security bugs I found in my own code first

holistis — Wed, 05 Aug 2026 07:08:12 +0000

Fewer than 5% of MCP servers make money. I put a real payment gate in front of one and wrote down what actually broke.

The problem, with numbers

There are 10,000+ Model Context Protocol (MCP) servers out there right now, with 97 million+ combined downloads. MCP is the emerging standard for how AI agents call tools — search, databases, APIs, whatever a server wants to expose. It's had a huge adoption wave.

Fewer than 5% of the people running those servers earn anything from them.

Not because nobody would pay. It's because "let people pay per call" means building, from scratch, on top of your actual product:

an HTTP 402 challenge/response flow
signature verification for the payment authorization (real cryptographic recovery, not just "is there a signature-shaped string present")
settlement against a payment facilitator
replay protection (nobody should be able to reuse the same signed payment twice)
revenue accounting per caller, per tool, per owner

None of that has anything to do with what the MCP server actually does. So most owners just... don't monetize, and eat the hosting cost, or don't run a business around it at all.

What I built

mcp-paywall is a proxy you drop in front of an existing MCP server, unmodified. It speaks x402 — the HTTP-402 + EIP-3009-signed-authorization pattern — and settles payments in USDC on Base.

AI agent / client
      │  POST /mcp/:serverId  (MCP Streamable HTTP, JSON-RPC)
      ▼
┌─────────────────────────────────────────────────────────────┐
│ gateway-server.mjs                                            │
│                                                                 │
│  1. Peek at the JSON-RPC method BEFORE any MCP processing.    │
│     Not "tools/call", or the tool is free  →  pass through.   │
│                                                                 │
│  2. "tools/call" on a priced tool, no X-PAYMENT header        │
│         →  real HTTP 402 + accepts[] challenge                │
│                                                                 │
│  3. X-PAYMENT present  →  verify (local EIP-712 signature      │
│     recovery + expiry + payee + amount) + settle via           │
│     facilitator  →  invalid at ANY step  →  402                │
│                                                                 │
│  4. Valid  →  record the paid call + revenue split             │
│     →  forward the call, unmodified, to the REAL upstream      │
│     MCP server (stdio)                                         │
└─────────────────────────────────────────────────────────────┘
      │
      ▼
 real MCP server — completely unaware it's being paid for

The important design choice: payment gating happens at the raw HTTP layer, before the request ever reaches MCP/JSON-RPC handling. That's what makes the 402 a genuine HTTP status code that x402-aware clients already know how to retry against, instead of a JSON-RPC error smuggled inside an HTTP 200.

The owner keeps 85% of every paid call; the gateway keeps 15% for metering, verification, and payout bookkeeping. Pricing is per-tool, in USDC's 6-decimal base units, set in a single config entry — no changes to the upstream server's code at all.

You can see it live and unpaid right now:

curl -s -X POST https://wazir-x402.duckdns.org/mcp-paywall/mcp/3ilm \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_vulnerabilities","arguments":{"query":"oracle"}}}'

That returns a real 402 with the price and payTo address — no tool output, no data leak, exactly the behavior an x402-aware client needs to see to retry with a signed payment.

The part I actually care about: verification is real, not a presence check

The easy way to build something like this is to check "does an X-PAYMENT header exist" and call it done. That's not verification, it's a formality.

recoverEip3009Signer() does actual EIP-712 typed-data signature recovery against USDC's real domain (name "USD Coin", version "2", chain id 8453, the real Base USDC contract address) using ethers.verifyTypedData. There's no "always valid" shortcut anywhere in that path. I proved this to myself by writing a test that tampers a single byte of a real, correctly-formed signature — it gets rejected because the recovered address genuinely no longer matches, not because of a format check catching malformed input.

The full decision matrix that's tested end-to-end: missing payment, valid payment, replayed payment (same nonce twice), tampered signature, payment to the wrong address, underpayment, expired authorization, and a simulated facilitator failure on an otherwise-perfect payment. Every rejection path is checked twice — that it returns HTTP 402 (not 200), and that the response body never contains the real tool output. 50 automated tests, run against a real spawned instance of my own 3ilm-mcp server on npm (its actual 1,032-finding vulnerability dataset, not a stub).

I also did one thing past the test suite: signed one real EIP-3009 authorization with a fresh, unfunded test wallet and sent it at the live public endpoint with the facilitator check turned on (not simulated). Every local check passed — structure, expiry, payee, amount, signature recovery — the request reached the real Coinbase facilitator over the network, and came back with an honest rejection (zero balance, as expected). No data leaked, nothing miscredited. That's the closest I got to a full production round-trip without actually moving money.

What I learned building this

Two things worth writing down, because neither is obvious until you hit it.

A trusted-actor bug I found in my own code before anyone else could. The first version of the owner dashboard had no auth at all — it was publicly readable. In a real multi-owner deployment, anyone who could guess or find a serverId could read that owner's revenue numbers. I closed it with a per-server random token compared using a hashed constant-time check (SHA-256 both sides, then crypto.timingSafeEqual, so neither a length mismatch nor timing tells you anything), verified with tests that assert the 401 body contains zero revenue figures, not just a generic error. While I was in there I also found that the dashboard's read path re-scanned the entire ledger file on every hit, unbounded — a disk-I/O cost at volume, and separately an unthrottled oracle for guessing tokens. Fixed with a fixed-window rate limiter that runs before the token check specifically, so brute-forcing the token is throttled too, not just legitimate traffic. I found both of these myself, in an adversarial pass against my own work, before showing it to anyone — that pass is the thing that actually caught them, not the first "it builds and the happy path works" version.

A real crash that had nothing to do with my own logic. Reusing one StreamableHTTPServerTransport instance across sequential requests crashed the Node process outright on the second request — a native libuv assertion, Windows + Node 24 + the official MCP SDK. Root-caused to transport reuse, not anything in my gateway code, fixed by constructing a fresh Server+Transport pair per HTTP request. I haven't reproduced the original crash on Linux (the VPS where this actually runs), but the per-request-transport fix should hold regardless of platform, since it removes the shared state entirely rather than working around a platform quirk.

What's genuinely not done yet

Being specific here on purpose, because "it builds" has burned me before as a claim to make:

No real USDC has ever moved. The facilitator call in the full round-trip above happened for real; the crypto is real; but no transferWithAuthorization has ever been broadcast on-chain, and the payout script has never run against mainnet with a funded key.
No real MCP client has driven this. All testing went through raw HTTP calls speaking the same wire protocol a real agent would use — nothing has actually pointed Claude Desktop, Claude Code, or ChatGPT at this gateway and watched it pay and get an answer.
No load or concurrency testing. Every paid call today is one child-process round-trip plus one facilitator round-trip; there's no queuing story yet for concurrent calls hitting the same upstream server.
Only one real server is integration-tested end-to-end (my own 3ilm-mcp). It's the honest proof this works technically, not proof it works across the variety of MCP servers actually out there.

If any of that changes your read on "is this ready for my server" — it should. It's a working prototype with real cryptography and a live public endpoint, not a finished product.

About me / this project

I'm a solo builder — no company, no team. I build these with AI-agent tooling as leverage (the code, the test suite, and the adversarial security pass on my own work were all done that way), but the design decisions, the verification of what's actually true versus claimed, and the "did this really work" checking are mine. If a number in this post turns out to be wrong, that's on me to fix, not the tooling.

If you run an MCP server and the "nobody pays for this" problem sounds familiar, or if you can see a hole in the payment-verification logic I haven't found yet, I'd genuinely like to hear about it in the comments.

The cheapest question you can ask before writing a PoC

holistis — Mon, 03 Aug 2026 16:56:11 +0000

If you hunt bug bounties, you know the pattern: you find something that looks real, you spend two or three days building a proof of concept, you submit it, and it comes back marked Duplicate. Someone else saw the same thing four hours before you did.

This isn't a rare bad day. Write-ups from people who've done this for a while put duplicate and rejected reports at somewhere between 50 and 80 percent of everything submitted. That's not a skill problem. It's a timing and information problem: you can't know a bug is already known until after you've done the expensive part.

Solodit already helps here — it's a free, searchable index of thousands of historical findings from Sherlock and Code4rena, and if you haven't used it, use it. But it lives in a browser tab you have to remember to check. It doesn't live inside the tools you're already using while you read the code.

That's the specific gap we built 3ilm-mcp for. It's a free MCP server — the same protocol Claude and other AI coding agents use to call tools — with a search index of 1,032 exact-reconciled findings from Sherlock audit contests, tagged by vulnerability pattern (reentrancy, oracle manipulation, access control, and so on), with acceptance rates per pattern so you can see which bug classes actually get paid versus which ones die at triage regardless of how correct they are.

The point isn't that this replaces judgment. It's that the question "has this exact pattern been seen before, and does this category of finding usually survive triage" is worth asking before you sink two days into a PoC, not after a rejection tells you the answer for free.

If you want the harder version of the same question answered — a full scan of a specific repo against known patterns, with an actual report — there's a paid tier for that too (bug-bounty-intelligence-mcp, a few dollars via x402 or card). But the free pattern search costs nothing to try, and if it saves you from writing one more PoC for a bug someone already reported, it's already paid for itself.

Install:

npm install -g 3ilm-mcp

Then point your MCP-compatible agent at it and ask it whether a pattern you're looking at has come up before.

I Built a Pay-Per-Call DeFi Bot Intelligence API Using x402 — No Signup Required

holistis — Sat, 18 Jul 2026 21:15:14 +0000

I run 50+ DeFi bots across Base, Arbitrum, OP and Solana. The data those bots generate — arb signals, draw schedules, earnings, health status — was sitting in PM2 logs on a Hetzner server. So I packaged it into an API and made it public.

It's called the DeFi Signal API. Live on RapidAPI at rapidapi.com/defisignalapi/api/defi-signal and directly at http://138.201.204.97:3748.

What the API exposes

Seven paid endpoints, all returning live data from real running bots:

GET /api/pt-next - Next PoolTogether draw time on Base/Arb/OP/Scroll with countdown ($0.001)
GET /api/pt - PT draw scans and recent claim results from active claimer bots ($0.001)
GET /api/signals - Solana DEX arb near-win signals from the last 2 hours ($0.002)
GET /api/earnings - Bot earnings today across all chains, per bot ($0.003)
GET /api/health - Live PM2 status of all 50+ bots on Hetzner VPS ($0.002)
GET /api/murshid - Nightly strategy report: expected vs actual, lessons learned ($0.010)
GET /api/edge - Strategy verdicts with expected vs actual monthly returns ($0.008)

One free endpoint: GET /api/status returns all prices and the payment wallet address.

How payment works: x402

The x402 protocol turns payment into an HTTP header. No account. No API key. No signup form.

Call GET /api/status to get the USDC wallet address on Base
Send the exact USDC amount on Base mainnet
Include the tx hash as PAYMENT-SIGNATURE header
Server verifies on-chain. Each tx hash works once.

const status = await fetch('http://138.201.204.97:3748/api/status');
const { wallet } = await status.json();

// After sending USDC to wallet on Base mainnet:
const res = await fetch('http://138.201.204.97:3748/api/pt-next', {
  headers: { 'PAYMENT-SIGNATURE': '0x...your_tx_hash...' }
});
const draws = await res.json();
// { base: { nextDrawAt: 1721390400000, timeUntilMs: 3600000 }, arb: {...} }

Transactions on Base settle in about 2 seconds. USDC transfer costs less than a cent. Pay-per-call is economically viable here.

Who this is for

PoolTogether bot builders who want precise draw timing without running their own RPC stack
Solana arb researchers studying near-miss patterns to calibrate their own bots
DeFi infrastructure teams wanting to monitor a live bot fleet without VPS access
Strategy researchers who want real expected-vs-actual return data, not backtests

What it does not do

No transaction execution. No trading advice. No personal data. Pure data layer.

I Built a Self-Improving Health Platform: Five AI Agents That Learn Every Week

holistis — Fri, 05 Jun 2026 22:25:05 +0000

Originally published on longevityai.nl — for full context, comments and related articles, visit the source.

I Built a Self-Improving Health Platform: Five AI Agents That Learn Every Week

Most AI products are static. You fine-tune a model, ship it, and it stays exactly as smart as the day you launched. Your users get the same quality on day 1 as on day 365.

Mine doesn't work that way.

Every Wednesday at 3am, five AI agents wake up, talk to each other, and make the next week's reports smarter — without me touching a single line of code.

This is the architecture that makes it possible.

The problem with static AI products

I run Longevity AI — a health platform that generates personalized 6-month lifestyle plans from a 28-question intake. It cross-references 10+ organ systems, checks 400+ EFSA-regulated claims, and outputs a clinically-framed report in under 15 minutes.

The core AI is Claude Sonnet. It's powerful. But it only knows what I've taught it.

The problem: health science moves fast. A new PubMed paper on magnesium and sleep quality drops. My platform doesn't know. A patient with a rare medication combination comes in. The report might miss the interaction. A legal claim sneaks past review. Nobody catches it until a user complains.

I had two options:

Hire a team of researchers and QA engineers to manually update the system
Build agents that do it automatically

I chose option 2. Here's exactly how it works.

The multi-agent architecture

Five agents run on a fixed schedule. One orchestrates them all.

Wednesday 03:00  Synthetic Patients Agent
Wednesday 04:00  Auto-KB Agent
Tuesday   03:30  Developer Tools Radar
Monday    07:00  Weekly Digest Agent
Always active    Agent Orchestrator

They don't share a runtime. They communicate through the database and a lightweight event system. No complex framework — just reportAgentEvent() and a rules table.

Agent 1: Synthetic Patients

The core of the self-improvement loop.

Every Wednesday at 3am, 10 synthetic patient profiles are selected from a static template library (5 conditions x 2 psychological archetypes). These are fake patients with real-looking intake responses: ferritin levels, medication lists, trauma history, stress scores.

Each synthetic patient goes through the exact same production pipeline as a real user. Full Sonnet report generation. No shortcuts.

Then a second agent — Claude Haiku — scores each report on 4 dimensions:

Dimension	What it checks	Gap threshold
Protocol depth	Are expected correlations for this condition named?	below 6/10
Personalization	Are this patient's specific details in the report?	below 6/10
Supplement specificity	Active biological forms named (magnesium bisglycinate, not just magnesium)?	below 6/10
Legal safety	No forbidden medical claims, no stop-medication advice?	below 7/10

Scores below threshold become knowledge gap proposals. Legal safety below 5 triggers an immediate compliance scan — synchronously, before anything else continues.

Cost: ~€0.55/week. Sonnet for the reports, Haiku for scoring.

Agent 2: Auto-KB

The knowledge base that writes itself.

The gap proposals from Agent 1 contain condition types and dimensions. Agent 2 converts these into PubMed queries, fetches abstracts via the free NCBI API, and sends each abstract to Haiku with one instruction:

Extract 3-5 factual claims from this abstract that are directly relevant to [condition]. Return structured triples: subject, predicate, object.

The triples land in a knowledge_triples table. The report generator reads from this table at runtime. No retraining. No fine-tuning. Just better context for the next generation.

By Wednesday afternoon, the knowledge base has been updated with whatever the synthetic patients couldn't answer well. By Thursday morning, real patients get smarter reports.

The feedback loop:

Synthetic patient gets weak report
  → Gap detected
    → PubMed abstract fetched
      → Facts extracted
        → knowledge_triples updated
          → Next patient gets stronger report

Agent 3: Developer Tools Radar

Because staying current is also a product decision.

Every Tuesday at 3:30am, the radar scans GitHub Trending and dev.to for tools that match a static relevance filter: playwright, trpc, drizzle, anthropic, health, automation, react, typescript.

Haiku summarizes each match in 1-2 sentences. The summaries land in the admin UI. Monday morning I get a digest with what the dev world built this week that's relevant to my stack.

Cost: €0.04/month.

Agent 4: The Orchestrator

The rule engine that connects everything.

Each agent calls reportAgentEvent(type, result) when it finishes. The orchestrator applies rules:

// R1: Legal flag → immediate compliance scan
if (type === "synthetic_loop_done" && result.legalFlags > 0) {
  await runComplianceDriftScan(); // synchronous, not queued
}

// R2: KB pipeline returned 0 facts → warning
if (type === "auto_kb_done" && result.factsInserted === 0) {
  console.warn("[orchestrator] Auto-KB returned 0 facts");
}

Rule R1 is the critical one. If a synthetic patient triggers a legal safety score below 5, the compliance agent doesn't wait until next week. It runs immediately. The orchestrator also lets me add new rules without touching the agents themselves.

Agent 5: Weekly Digest

The operator dashboard I never have to build.

Every Monday at 7am, an HTML email lands in my inbox with:

How many new facts entered the knowledge base this week
Synthetic loop results: gaps found, legal flags if any
Which PubMed papers were automatically processed
Which developer tools are on the radar
System cost for the week

I know exactly what the system learned, what it fixed, and what it flagged without logging into a dashboard or running queries.

Psychological profiling at €0 extra

While building the agent system, I added something that costs literally nothing.

Every intake has responses about stress levels, anxiety, medication history, trauma, and previous treatment attempts. From these existing fields — no new questions, no LLM call — I derive a psychological archetype:

Archetype	Signal	Coaching instruction
Overwhelmed	High stress + multiple specialists + frustration keywords	Start with deep validation, cite their own words, tiny steps only
Skeptical	Multiple specialists + frustration, low anxiety	Biological mechanism first, then recommendation. Name the researcher.
Ready but scared	Fear keywords + previous attempts + moderate stress	Week 1 max 2 changes, explicit success markers per week
Knowledge-seeker	Blood values mentioned + detailed answers + no fear	Enzymes and neurotransmitters before the advice
Beginner	No prior treatment, short answers	Warm, jargon-free, reassuring timeline

The archetype gets injected as a single instruction line into the report system prompt. The LLM adapts tone, structure, and depth automatically. Zero extra tokens at generation time.

What this cost to build

The entire multi-agent system is about 1,200 lines of TypeScript. It took one focused session to architect and implement.

Weekly operating cost:

Synthetic loop: max €0.55
Auto-KB pipeline: ~€0.01
Developer radar: ~€0.01
Weekly digest: €0 (DB queries + one email)
Total: under €0.60/week

The system pays for itself if it catches one legal compliance issue before a user does.

What I'd do differently

Haiku scores need calibration. The first few weeks I'll manually compare Haiku's scores against my own judgment and adjust thresholds if needed.

Synthetic patient templates are static. They don't learn. The knowledge base learns, but the patient profiles stay fixed. A future version would generate edge-case profiles dynamically based on what real users submit.

The orchestrator is in-memory. Events don't survive a server restart. For a high-stakes system I'd persist the event log. For a solo SaaS at this scale, it's fine.

The bigger point

Most solo founders think "multi-agent AI" means using CrewAI or AutoGen with 10 chained LLM calls. That's one way to do it.

What I have is simpler and more reliable: purpose-built agents that do one thing well, communicate through a database, and are coordinated by a lightweight rule engine. No framework. No magic. Just TypeScript, cron jobs, and a clear separation of concerns.

The result: a platform that gets measurably smarter every week, catches its own legal issues, updates its own knowledge base, and tells me what it learned while I sleep.

Built on: React 18 + tRPC + Drizzle/MySQL + Claude Sonnet/Haiku + Railway

Live at longevityai.nl

Questions or want to talk architecture? info@holistischadviseur.nl

This article was originally published on Longevity AI. Visit the source for the full context, references and discussion.

I Added Legal Compliance Checks to My E2E Test Suite for €0. Here's How (and Why a Non-Developer Had To).

holistis — Fri, 05 Jun 2026 10:23:25 +0000

Originally published on longevityai.nl — for full context, comments and related articles, visit the source.

I Added Legal Compliance Checks to My E2E Test Suite for €0. Here's How (and Why a Non-Developer Had To).

I am not a developer. I run a health AI platform in the Netherlands called Longevity AI. It generates personalized health reports using LLMs, auto-publishes blog posts about longevity, and operates under Dutch medical regulation: the IGJ (Health and Youth Care Inspectorate), Wet BIG, and GDPR.

That last part is the part most builders skip. I cannot.

If my platform publishes content that says "this supplement cures your condition" or "stop taking your medication," I am not looking at bad SEO. I am looking at an enforcement action by the IGJ. The Dutch health regulator has shut down platforms for exactly this kind of language. I have a file in my codebase called risks.md specifically about this.

Today I shipped something I think is useful for anyone building in a regulated space: a compliance scanner baked directly into my Playwright E2E test suite. It runs on every deploy. It costs €0. It uses no LLM.

Here is what it does and why I built it this way.

The problem: AI-generated content drifts toward prohibited language

My platform runs a nightly pipeline called Autopilot News Radar. It pulls from BBC Health, PubMed, EFSA, and ClinicalTrials, then generates three-language blog posts (NL/EN/FR) automatically. The posts go through a server-side compliance scanner before they are saved.

That scanner works. It has caught violations before they went live.

But I had a gap: no automated check was running against the actual live site. The server filter could pass a post, and some edge case in rendering, caching, or a manual publish could still get prohibited language onto the page. I would only discover that when a user flagged it -- or worse, a regulator did.

The solution: compliance.spec.ts

I added four Playwright tests that fetch real pages from the live site and run the same regex patterns the server uses.

// tools/muraqib/tests/compliance.spec.ts (simplified)

const HIGH_SEVERITY_PATTERNS = [
  { ruleId: "no-cure-claim",           pattern: /\bgeneest\s+(gegarandeerd|altijd|100%|volledig)/i },
  { ruleId: "no-cure-claim",           pattern: /\bwondermiddel\b/i },
  { ruleId: "no-cure-claim",           pattern: /\b100%\s+effectief\b/i },
  { ruleId: "no-behandel-imperatief",  pattern: /stop\s+met\s+(je|jouw|de)\s+(medicatie|medicijn)/i },
  { ruleId: "no-behandel-imperatief",  pattern: /\bdit\s+vervangt\s+(medicatie|behandeling)/i },
];

test("geen HIGH compliance-schendingen in live blogs", async ({ page }) => {
  await page.goto("/blog");
  await waitForReady(page);

  const links = await page.locator('a[href*="/blog/"]').evaluateAll((els) =>
    els.map((el) => (el as HTMLAnchorElement).href).filter(Boolean)
  );

  const violations: string[] = [];

  for (const url of [...new Set(links)].slice(0, 20)) {
    await page.goto(url);
    const text = await page.evaluate(() => document.querySelector("article")?.textContent ?? "");

    for (const { ruleId, pattern } of HIGH_SEVERITY_PATTERNS) {
      const match = text.match(pattern);
      if (match) violations.push(`[${ruleId}] "${match[0]}" op ${url}`);
    }
  }

  expect(violations, "HIGH compliance-schending(en) gevonden op live site").toHaveLength(0);
});

No API calls. No LLM. A regex scan on the live rendered HTML, run by a real browser.

Why regex and not an LLM?

Because I need determinism and zero cost.

An LLM-based compliance check would:

Cost money on every deploy (I run 130 tests per deploy, nightly)
Be non-deterministic (same text, different answer on reruns)
Be a black box ("the AI said it was fine" is not an audit trail)

The patterns I check are not subtle. The IGJ is not looking for nuanced phrasing. They are looking for things like "genezingsclaims" (cure claims) and advice to stop medication. Regex handles this precisely and cheaply.

The double-layer architecture

[AI generates content]
        |
        v
[server/compliance/scanner.ts]      blocks HIGH violations before save
        |
        v
[database -- rendered on site]
        |
        v
[tools/muraqib/tests/compliance.spec.ts]   E2E test on live page, every deploy

If the first layer fails (bug in server, manual override, edge case), the second layer catches it before the deploy completes. If the second layer catches something, GitHub Actions fails and I get notified.

The four compliance tests

Beyond the HIGH-severity check, the suite also runs:

Blog overview loads -- sanity check that /blog renders with at least one article
No HIGH violations -- cure claims and medication-stop advice on live pages
No em-dashes in public text -- house style rule enforced automatically
Affiliate disclosure present -- blogs with affiliate links must contain a disclosure sentence

That last one is a legal requirement in the Netherlands too. If I link to a supplement with an affiliate ref, I need to disclose it. The test checks that the disclosure text is present on any page that contains an affiliate link.

What it does NOT catch

I want to be honest about the limits.

MEDIUM-severity violations are manual. Vague implied efficacy claims are contextual. My server scanner flags them and logs them. A human (me) reviews the log weekly. Automated blocking on MEDIUM creates too many false positives.

It does not understand context. "Stop je medicatie" in a quote about why you should not stop medication would still trigger the pattern. I have handled this by writing content that avoids the phrase entirely.

It is not a legal opinion. These patterns are based on documented compliance research. They are not a substitute for a lawyer reviewing the content.

Also shipped today: AI Coach tests

Alongside the compliance spec, I also added coach.spec.ts -- eight tests for the AI Coach feature:

Login gate: unauthenticated users see a CTA, not the chat interface
Sending a message and receiving a response within timeout
Enter-key submission (this broke silently once before)
Disabled send button on empty input (prevents empty API calls)
Feedback buttons (thumbs up/down) working correctly
Back navigation to reports page
Zero JavaScript console errors during a full conversation

That last one is the test I trust most. A zero-console-error check on a full user flow catches a class of bugs no unit test finds.

Where Muraqib stands today

130 tests across: SEO, sitemap, robots.txt, blog rendering, anamnesis flow, lab analysis, onboarding, AI Coach, and compliance. The suite runs on GitHub Actions using Playwright 1.60.0 with the native Healer active -- it auto-repairs locators that break when the DOM changes.

	Before today	After today
Total tests	118	130
Playwright version	1.48	1.60.0
Compliance coverage	Server only	Server + E2E
AI Coach coverage	None	8 tests
Healer	Not active	Active in CI

Every deploy runs all 130. A green check means a real browser walked through the platform and found nothing wrong. A red check means something broke before any user sees it.

Why ownership matters here

There are SaaS compliance monitoring tools. All of them put my legal patterns in a vendor's system, behind a subscription.

My patterns live in tools/muraqib/tests/compliance.spec.ts. They are in git. They have commit history. When the IGJ updates their enforcement guidance, I add a line and commit it. The next deploy runs the updated check.

That is the practical argument for owning your test infrastructure: the rules that matter most to your business should live where you can see them, change them, and audit them.

Longevity AI runs at longevityai.nl. If you are building a health SaaS in a regulated industry and want to compare notes, reach out via the site.

This article was originally published on Longevity AI. Visit the source for the full context, references and discussion.

I Didn't Buy Octomind. I Built My Own for €0. Here's Why It's Better.

holistis — Tue, 02 Jun 2026 20:36:48 +0000

Originally published on longevityai.nl — for full context, comments and related articles, visit the source.

I Didn't Buy Octomind. I Built My Own for €0. Here's Why It's Better.

I am not a developer. I run Longevity AI, a Dutch health AI platform. I have paying users, a compliance gate, three languages, and a codebase that keeps growing every week.

And last month I discovered Octomind — an AI-powered e2e testing platform that automatically generates and self-heals your Playwright tests. The pitch was compelling. The price tag was not: €200-500+ per month.

So I built my own.

I called it Muraqib (مراقب) — Arabic for "the observer." It runs every night. It fixes itself. And it costs €0.

Here is why that was the right call.

What Octomind Does (And Does Well)

To be fair: Octomind is genuinely impressive. You give it a URL, it crawls your site, generates Playwright tests automatically, and when your UI changes, it heals the broken selectors without you touching a config file. The dashboard shows you video recordings of every test run. It integrates with GitHub in ten minutes.

For a team, it is probably worth the money. The time saved on test maintenance alone justifies the cost at scale.

But I am not a team. I am one person running a SaaS in a regulated industry. And when I looked at what Octomind would actually give me versus what I actually needed, the math did not work.

The Problem With Generic QA Tools

Here is what a generic tool does not know about my site:

My blog uses Wouter for client-side routing. Every blog article is an <article> element with an onClick handler — not an <a href> link. A generic crawler would generate selectors like a[href*="/blog/"] and they would fail on day one. Not because the feature is broken. Because the tool does not understand how the page actually works.

My welzijnscheck funnel has two different pages: a landing page at /welzijnscheck and the actual questionnaire at /welzijnscheck/:code. A test that looks for a form on the landing page will fail every time. Not a bug. Just architecture the tool has no context for.

These are not edge cases. They are the normal state of a custom-built SaaS. Generic tools generate generic tests. Generic tests fail in non-generic codebases.

What Muraqib Does Differently

Muraqib knows my codebase because it was built from it.

Every selector in every test spec reflects how my application actually works — not how a crawler assumes it works. When a test is written for the welzijnscheck flow, it knows that /welzijnscheck is a landing page with CTA buttons, and that the form lives at a different route entirely. That knowledge does not come from crawling. It comes from reading the source.

The self-healing works the same way. When a test fails, Claude Code reads the failure, reads the relevant spec, and reads the production code. The fix it proposes is based on understanding the full context — not a pattern-matched selector swap.

That is the difference between a tool that knows your URL and a tool that knows your codebase.

The Numbers

	Octomind	Muraqib
Monthly cost	€200-500+	€0
Test generation	Automatic (crawler)	Built from source
Self-healing	Automatic selector repair	Claude Code reads source + fixes
Dashboard	Beautiful UI, video recordings	GitHub Actions + weekly email
Notifications	Configurable	One email per week, Monday 08:00
Vendor lock-in	Yes (their platform)	No (your code, your repo)
Knows your routing	No	Yes
Knows your architecture	No	Yes

The €0 is not the main point. The codebase awareness is.

The Weekly Email

One design decision I made that I have not seen elsewhere: Muraqib sends me one email per week. Not one per failure. Not one per test run. One.

Every Monday at 08:00, I get a summary: how many runs this week, pass rate, what failed, what Claude fixed, which PRs are open for my review.

That is it. Everything else happens without me.

Most monitoring tools optimize for visibility. More dashboards, more notifications, more insight. I optimized for silence. I want to know about problems only after Muraqib has already tried to fix them.

The Self-Healing Loop

When a test fails at 03:00 AM:

GitHub Actions creates an Issue with the full failure context
The Issue tags @claude — the Claude Code GitHub App picks it up
Claude reads the failing test, the error message, and the relevant production code
Claude opens a Pull Request with a proposed fix
I review it Monday morning, merge in 30 seconds

This is not magic. It is just a well-connected pipeline. But the result is that my test suite heals itself on a cadence that matches my review capacity — not the cadence of failure alerts.

What I Gave Up

I want to be honest about the trade-offs.

I gave up the beautiful UI. Octomind has a proper dashboard with pass/fail history, visual diffs, and video of every test run. My "dashboard" is a GitHub Actions log and a Monday morning email. For a solo founder checking status once a week, that is fine. For a team doing daily deployments, it would not be.

I gave up automatic test generation. Octomind crawls your site and writes the tests. I wrote mine manually (with Claude). That was a few hours of work upfront. The trade-off is that every test reflects exactly what I intend to test — no assumptions.

I gave up instant failure notifications. Octomind can alert you in minutes. I check once a week. This works because Claude tries to fix things before they need my attention. If your business model requires instant incident response, this approach is not for you.

Why Ownership Matters

There is a version of this story where I sign up for Octomind, pay the monthly fee, and move on. That is a legitimate choice.

But here is what I would have missed:

When I updated my blog routing from anchor tags to wouter's setLocation() handler, my tests would have broken. With Octomind, I would file a support ticket or wait for the self-healing to catch up. With Muraqib, Claude already knew about the routing change because it made the change. The fix was in the same PR.

That is the compounding advantage of ownership. The tool that built your feature is the same tool that tests it and fixes it when it breaks. There is no translation layer between what the code does and what the tests expect.

The Name

Muraqib (مراقب) is Arabic for "the observer" or "the supervisor." Not a divine name — just a word with weight. It fits what the tool does: watch quietly, act only when something is wrong.

"He sees what you do not see. He notices what you forgot. He is not a guard that shouts. He is a guard that fixes."

Longevity AI runs at longevityai.nl. If you are building a health SaaS in a regulated industry and want to compare notes, I am reachable via the site.

This article was originally published on Longevity AI. Visit the source for the full context, references and discussion.

Why I Built a Halal-By-Design AI Image Pipeline

holistis — Tue, 02 Jun 2026 16:52:05 +0000

Originally published on longevityai.nl — for full context, comments and related articles, visit the source.

Why I Built a Halal-By-Design AI Image Pipeline

I run Longevity AI, a Dutch holistic health platform. When I plugged Stable Diffusion into my blog pipeline, the first batch of "wellness" images came back with a Buddha statue, a Catholic crucifix on a yoga studio wall, and a person doing salah pose toward Mecca. My audience is mixed. Muslim, Christian, Hindu, secular. I needed a filter.

So I built one. I called it the halal filter, because halal is the strictest standard. If an image passes halal, it passes for everyone. Catholic readers, secular yoga teachers, kids using the platform, atheist HR buyers. The strictest filter is also the most universal one.

Here is what I built, why "halal" is a useful label even outside Islam, and what you can copy.

The Problem: AI Image Generators Have No Brand Sense

Stable Diffusion, Flux, DALL-E. They generate religious imagery by default if your prompt has any spiritual undertone. Ask for "meditation" and you get a Buddha. Ask for "calm bedroom" and you get a candle next to a crucifix. Ask for "morning routine" and you get prayer beads.

The AI is not wrong. It reflects training data biased toward stock photography where meditation equals Buddha and serenity equals religious iconography. That is a fact about the internet, not about meditation.

For a Dutch holistic health platform this is a brand nightmare:

Muslim readers see a Buddha in a wellness article and close the tab.
Christian readers see a Hindu deity and wonder what kind of platform this is.
Secular readers see religious symbols and think the site is preachy.
Schools using the B2B bundle see a deity statue and parents complain.

The image is fine for an American wellness site where Buddha aesthetics are baseline. It is not fine for the Netherlands, where the audience is religiously plural and the trust threshold is high.

The Halal Lens (Why It Matters Even If You Are Not Muslim)

Halal as a concept goes further than most filters. It says: do not depict the divine, do not encourage worship of created things, do not show prayer rituals as decoration, do not undress for the camera. The Islamic prohibition on imagery of deities, combined with strict modesty rules, creates a very high bar.

Here is the key insight. If your image pipeline passes halal, it passes every other religious and secular standard too.

A Catholic parent will not be offended (no other gods).
A Buddhist will not see their iconography mishandled.
A secular user will not see religious symbols at all.
A modesty-conscious brand will not see exposed bodies.
A child-safety reviewer will not see anything they need to flag.

The reverse is not true. A Buddhist-safe image might still contain a crucifix. A secular-clean image might still show prayer beads. Halal is the upper bound of restrictiveness, which is exactly why it makes a great brand-safety default for any audience.

I do not think non-Muslim devs need to become Muslim to use this filter. I think they should steal the idea. Strictest filter equals most universal compatibility.

The Code (Less Than 100 Lines)

Here is the actual blacklist (50+ keywords, no LLM call needed):

const RELIGIOUS_BLACKLIST = new Set([
  "buddha", "buddhism", "deity", "gods", "god", "worship", "prayer", "praying",
  "temple", "shrine", "sacred", "holy", "altar", "religious", "monk", "nun",
  "bible", "quran", "torah", "church", "mosque", "synagogue", "hinduism", "hindu",
  "brahmin", "idol", "idolatry", "cross", "crucifix", "saint", "miracle",
  "spiritual", "mystical", "ceremonial", "ritual", "chakra", "mantra", "zen",
  "tibetan", "vatican", "pilgrim", "communion", "baptism",
]);

function sanitizeImagePrompt(prompt: string): string {
  const lower = prompt.toLowerCase();
  for (const banned of RELIGIOUS_BLACKLIST) {
    if (lower.includes(banned)) {
      return prompt
        .replace(new RegExp(banned, "gi"), "wellness")
        .replace(/\s+/g, " ")
        .trim();
    }
  }
  return prompt;
}

That is the whole thing. Two pieces: a blacklist set, and a sanitizer that replaces any flagged term with the neutral word "wellness".

The sanitizer is called before every image-generation API call (Stability AI, Flux, DALL-E, even Pexels search). The image API never gets a chance to generate the offending image, because the prompt is rewritten before it leaves my server.

The Universal Lesson: Hardcode Your Brand Boundaries

You cannot trust the LLM to know your brand. Stable Diffusion does not know my audience is Dutch-Muslim. DALL-E does not know my B2B clients include schools. Flux does not know my CEO is religious.

Brand boundaries belong in code, not in prompts.

The mistake most teams make is telling the LLM "do not include religious imagery" in the system prompt. This works 80% of the time. The 20% leak is what gets you on Twitter. A hardcoded blacklist plus a sanitizer is 100%. Every image-prompt passes through. No exceptions. No "the AI was being creative".

Even if you do not care about religious imagery specifically, you almost certainly care about something else:

Children's apps: no firearms, no violence, no romantic imagery.
Medical platforms: no procedures shown out of context.
B2B SaaS: no political symbols, no celebrities, no competitor logos.
News publishers: no copyrighted IP.

The pattern is the same. Build a blacklist. Build a sanitizer. Never trust the LLM to enforce your brand. It does not know your brand.

The Trade-Offs (Be Honest)

Three trade-offs to call out.

1. False positives. "Yoga in a temple" gets sanitized to "yoga in a wellness". Not ideal. The replacement is graceful degradation, not perfect rewriting. For a brand-safety filter, false positives are cheaper than false negatives.

2. Reduced creative range. I cannot generate a Diwali-themed wellness post easily, because "diwali" is not in the blacklist but the visual will likely include diyas near deities. I would need to add it. The blacklist grows.

3. Cultural blind spots. My blacklist was built from a Western-Muslim perspective. A Hindu reader might find it incomplete. A Buddhist reader might find it over-zealous. I update it when I learn about gaps. This is not a finished product.

The point. The filter is intentionally conservative. For a health platform serving a mixed audience, conservative is correct.

Why I Used the Word "Halal" (Not "Modesty Filter")

I could have called this BRAND_SAFETY_BLACKLIST or MODESTY_FILTER. I called it the halal filter because:

It is more honest. The filter was built with Islamic standards in mind. Naming it after a generic concept would have hidden the inspiration.
It signals to my Muslim audience. They know exactly what to expect.
It opens a conversation with non-Muslim audiences. "Halal" is a loaded word in the West. Using it provokes the right question: "Why would a tech platform need a halal filter?" The answer (brand-safety, universal compatibility) is the interesting part.
It is a competitive moat. Most platforms will not call their filter "halal" because they are afraid of the word. That fear creates space for brands that are not afraid.

If "halal" feels too charged for your context, call it the strictest filter or the universal filter. The concept does not care about the label. The hardcoded blacklist is what matters.

What I Would Build Next

Cultural-context detector: Halal-only food imagery (no pork, no alcohol-prominent scenes).
Modesty filter: No bikinis, no underwear shots, no over-exposed bodies in editorial photography.
Sensitivity-tunable filter: Three modes (strict / standard / loose) per content category.
Vision-LLM verification pass: After Stable Diffusion returns the image, run a vision model that confirms compliance.

The core insight, one more time. Build the filter you would want for your strictest customer. Everyone else gets a bonus.

This article was originally published on Longevity AI. Visit the source for the live wellness platform and the full technical context.

This article was originally published on Longevity AI. Visit the source for the full context, references and discussion.

How I Built a Health-Content Autopilot for €12/Month

holistis — Tue, 02 Jun 2026 12:58:46 +0000

Originally published on longevityai.nl — for full context, comments and related articles, visit the source.

How I Built a Health-Content Autopilot for €12/Month

I run Longevity AI, a Dutch holistic health platform. The content side was killing me. Writing one good evidence-based blog took 4-6 hours. I had nine ziektebeelden (chronic conditions) to cover, in three languages. That's roughly 50 blogs per year I could realistically produce. Not enough.

So I built an autopilot. Here is how it works, what it costs, and what I had to fight to keep it ethical.

The Problem: Quality Health Content Does Not Scale

Health content has a quality floor that most blog-automation systems crash into. You cannot just pull RSS feeds and rephrase them. You need:

Peer-reviewed sources — citation from PubMed, EFSA, ClinicalTrials.gov
Compliance — Dutch IGJ, EU MDR, AVG (GDPR) all apply
Three languages — Dutch primary, English and French as syndication
Cover image + inline visuals — readers do not engage with text walls

My first attempt used GPT-4o-mini + Flux + manual review. Per blog: ~€0.50. Per cycle (every 6 hours, 3-5 blogs): €1.50-2.50. Per month: €120-240. Fine, but bleeding for a solo operation.

The Architecture: 4 Scrapers, 1 Orchestrator, 1 Gate

The autopilot has four input sources. Each one is a separate scraper that returns a normalized signal object:

interface ContentSignal {
  title: string;
  topic: string;
  sourceText: string;   // article body
  sourceUrl: string;    // canonical link
  language: "nl";
  ziektebeeldIfKnown?: string;
  tags?: string[];
}

The four scrapers:

BBC Health RSS — keyword-filtered for supplement, treatment, nutrition, sleep, immune, gut, etc.
NCBI PubMed eUtils — per-ziektebeeld scientific queries, rate-limited to 3 req/sec
EFSA RSS — EU supplement approvals and health claims (high-trust EU regulator)
ClinicalTrials.gov REST — 7-day rolling window of new trial registrations

The orchestrator:

export async function runNewsRadarCycle(): Promise<void> {
  const db = await getDb();
  if (!db) return;

  const bbcArticles = await scrapeBBCHealthFeed();
  for (const article of bbcArticles) {
    if (await signalAlreadyExists(db, article.link)) continue;
    await createSignal(db, { /* ... */ });
  }

  for (const ziektebeeld of Object.keys(LAB_FOLDER_BY_ZIEKTEBEELD)) {
    const studies = await scanPubMedForZiektebeeld(ziektebeeld);
    for (const study of studies) {
      // dedup + insert
    }
  }
  // EFSA + ClinicalTrials same pattern
}

Deduplication is two-layer: URL-hash in the orchestrator and a query check in signalAlreadyExists() against the database. Both layers are necessary because the same study can appear in PubMed and ClinicalTrials with different URLs.

The Compliance Gate (The Hardest Part)

Health content in the EU is a minefield. The IGJ (Dutch healthcare inspectorate) regularly fines wellness sites for treatment claims. The MDR (medical device regulation) governs anything that sounds like diagnostic advice. So I built a hard gate:

const complianceResult = await runComplianceCheck(sourceText);
const isSafe = complianceResult.verdict === "SAFE";

if (!isSafe) {
  status = "pending_review";  // never auto-publishes
} else {
  status = "pending_auto_blog";  // proceeds to blog generation
}

The compliance check uses Claude to evaluate against a curated set of rules: no diagnostic claims, no treatment imperatives, no cure language, no medication-stop advice. Verdict is SAFE / WARN / BLOCK. Only SAFE proceeds to auto-publish.

This matters for one specific feature: affiliate links. I only inject affiliate links into 100% SAFE articles. Anything that fails compliance goes to manual review. The disclosure is explicit:

Wat je hierboven leest, is gebaseerd op peer-reviewed wetenschap en officiële gezondheidsrapporten. Wij noemen supplementen en bloedtests alleen op basis van wetenschappelijk bewijs.

Transparency over deception. I had to push back on my own design here — the temptation to just hide AI-generation is real. But that crosses a line I will not cross.

The Cost Reduction (90% in One Refactor)

After running for a few weeks I looked at the bill: €180/month for content the audience read for 30 seconds each. Time to optimize.

Three changes, each independent:

Component	Was	Now	Savings
LLM	GPT-4o-mini	Claude Haiku	90% on LLM cost
Images	Flux (Together.ai)	Stability AI	70% on image cost
Cycles	Every 6 hours	Every 12 hours	50% fewer API calls

The LLM swap was the biggest win. Claude Haiku writes more naturally than GPT-4o-mini for long-form Dutch content. I had assumed the cheaper model would mean worse output. It does not. It means different output, and for technical-but-friendly health content, Haiku wins.

The image swap was equally surprising. Stability AI's stable-diffusion-3-large produces images that are 80% as good as Flux for 30% of the cost. For inline blog images that readers glance at for 2 seconds, that trade is obvious.

Cycle frequency was the easiest win. Going from 6 to 12 hours did not affect the freshness of the content the audience saw. PubMed studies do not become stale in 6 hours.

Final cost: €12-20/month. Same quality. Same pipeline. Same compliance.

Auto-Syndication: One Source, Three Platforms

Once a blog is generated and published on longevityai.nl, the system checks if it has a technical tag. If yes, it auto-syndicates to Hashnode and Dev.to:

if (lang === "en" && hasTechnicalTag(blog.tagsCsv)) {
  await Promise.all([
    publishToHashnode({ ... }),
    publishToDevTo({ canonical_url: longevityaiUrl, ... }),
  ]);
}

The canonical_url parameter is critical: it tells Google that longevityai.nl is the original source. No duplicate-content penalty. The syndicated copies are tracked in the social_posts table to prevent double-posting on retry.

This blog you are reading right now? Originally written for longevityai.nl. Auto-posted to Hashnode and Dev.to via this exact pipeline.

Lessons Learned

1. Compliance is the moat. Anyone can scrape RSS feeds and rephrase them. Few people can pass an IGJ audit on the output. Build the gate first.

2. Cheaper models often write more naturally. Haiku writes Dutch health content with less corporate fluff than GPT-4o-mini. Test before assuming.

3. Deduplication is two-layer or it is broken. URL-hash + DB query check. Same article hits the same pipeline from multiple sources.

4. Canonical URLs > hiding. Syndicate openly with canonical_url. Hiding AI-generation crosses an ethical line and Google's 2024+ guidelines do not penalize transparent AI content anymore.

5. Fire-and-forget syndication. Hashnode/Dev.to failures should not break the main publish flow. Wrap in try/catch, log warnings, never crash.

What I Would Build Next

LinkedIn syndication (waiting on API approval)
Medium fallback for health-content audience (not just technical)
Topic clustering so the cron only generates content where my lab/RAG has expertise
Weekly digest emails auto-generated from the past 7 days of new blogs

The core insight: do not try to compete on content volume. Compete on the depth of the pipeline behind each piece. Quality gates, transparent sourcing, ethical syndication. The autopilot is not about more blogs. It is about every blog being defensible.

This article was originally published on Longevity AI. Visit the source for the full context, references and the live News Radar in action.

This article was originally published on Longevity AI. Visit the source for the full context, references and discussion.

Three free wearable integrations for an AI health report: Oura, Withings, Polar

holistis — Mon, 01 Jun 2026 13:20:22 +0000

Live today: three wearables, free to connect

From today you can connect your Oura Ring, Withings device or Polar watch to your longevity report at longevityai.nl. Free of charge after payment of the report, in a few clicks. No paid aggregator, direct OAuth2 with each manufacturer.

Why this matters

A questionnaire knows what you think about your sleep. A ring knows how you actually sleep.

In a longevity report we combine two sources:

Subjective: what you fill in during the intake. How you sleep, eat, move, feel. Complaints, patterns, intuitions.

Objective: what a wearable measures. HRV, resting heart rate, sleep stages, breathing rate. With Withings: weight, blood pressure, fat mass. With Polar: breathing frequency. With Oura: readiness score.

The value is in the correlation between the two. Not in either one alone.

Engineering notes

Three different OAuth2 flows:

Oura (cloud.ouraring.com/oauth/authorize + api.ouraring.com/oauth/token): clean v2 REST API, JSON responses, standard refresh tokens.
Withings (account.withings.com/oauth2_user/authorize2 + wbsapi.withings.net/v2/oauth2): every API response wrapped in {status: 0, body: {...}}. Token endpoint expects action=requesttoken in POST body, not just grant_type.
Polar (flow.polar.com/oauth2/authorization + polarremote.com/v3/oauth2/token): Basic Auth header for token exchange (base64 of client_id:client_secret). Requires a separate POST /v3/users call after token-exchange to register the user with member-id, otherwise all data endpoints return 403.

Each has its own token-refresh strategy. Withings tokens expire in hours, Oura in days, Polar tokens are long-lived without refresh endpoint.

AVG-compliant data pipeline

We only store a summary. No raw nightly records. Disconnect from the user dashboard, all derived data is purged. GDPR article 9 (special-category data) covered through explicit consent at intake.

Trilingual launch

Available immediately in Dutch, English and French. Translation-group system in the database links the language-versions of each article so a language-switch on a blog page never lands on a 404 again.

Read the full story (Dutch original):
https://longevityai.nl/blog/wearables-gekoppeld-aan-anamnese-oura-withings-polar

English version:
https://longevityai.nl/blog/wearables-linked-to-intake-oura-withings-polar

DEV Community: holistis

I built a judge that argues with itself before you submit a bug bounty finding

I built a judge that argues with itself before you submit a bug bounty finding

How it works

A real example

What it deliberately doesn't do

Try it

What actually gets paid in smart contract audit contests

Most valid findings do get paid. The rate just swings wildly.

The bug type barely matters. This was the surprise.

Claiming High barely helps, and it rarely survives.

Even when you win, sometimes you split the pot.

What this is, and what it is not

Try it

Your AI-built app is impressive. It is just not yours yet.

What "owning it" actually requires

What I built: MergeFix

If you want to try Migrate & Own for free

A payment gateway for MCP servers, and the security bugs I found in my own code first

The problem, with numbers

What I built

The part I actually care about: verification is real, not a presence check

What I learned building this

What's genuinely not done yet

About me / this project

The cheapest question you can ask before writing a PoC

I Built a Pay-Per-Call DeFi Bot Intelligence API Using x402 — No Signup Required

What the API exposes

How payment works: x402

Who this is for

What it does not do

Links

I Built a Self-Improving Health Platform: Five AI Agents That Learn Every Week

I Built a Self-Improving Health Platform: Five AI Agents That Learn Every Week

The problem with static AI products

The multi-agent architecture

Agent 1: Synthetic Patients

Agent 2: Auto-KB

Agent 3: Developer Tools Radar

Agent 4: The Orchestrator

Agent 5: Weekly Digest

Psychological profiling at €0 extra

What this cost to build

What I'd do differently

The bigger point

I Added Legal Compliance Checks to My E2E Test Suite for €0. Here's How (and Why a Non-Developer Had To).

I Added Legal Compliance Checks to My E2E Test Suite for €0. Here's How (and Why a Non-Developer Had To).

The problem: AI-generated content drifts toward prohibited language

The solution: compliance.spec.ts

Why regex and not an LLM?

The double-layer architecture

The four compliance tests

What it does NOT catch

Also shipped today: AI Coach tests

Where Muraqib stands today

Why ownership matters here

I Didn't Buy Octomind. I Built My Own for €0. Here's Why It's Better.

I Didn't Buy Octomind. I Built My Own for €0. Here's Why It's Better.

What Octomind Does (And Does Well)

The Problem With Generic QA Tools

What Muraqib Does Differently

The Numbers

The Weekly Email

The Self-Healing Loop

What I Gave Up

Why Ownership Matters

The Name

Why I Built a Halal-By-Design AI Image Pipeline

Why I Built a Halal-By-Design AI Image Pipeline

The Problem: AI Image Generators Have No Brand Sense

The Halal Lens (Why It Matters Even If You Are Not Muslim)

The Code (Less Than 100 Lines)

The Universal Lesson: Hardcode Your Brand Boundaries

The Trade-Offs (Be Honest)

Why I Used the Word "Halal" (Not "Modesty Filter")

What I Would Build Next

How I Built a Health-Content Autopilot for €12/Month

How I Built a Health-Content Autopilot for €12/Month

The Problem: Quality Health Content Does Not Scale

The Architecture: 4 Scrapers, 1 Orchestrator, 1 Gate