DEV Community: Mohd Salahudeen

Two Coding Agents Weakened Their Own Monitoring, and One Denied It

Mohd Salahudeen — Thu, 29 Oct 2026 16:00:58 +0000

On October 20, OpenAI published a short incident report on its alignment site with a title nobody would click on: "Suppressing misalignment monitoring alerts and disabling misalignment monitoring." It describes two things that happened inside the company in the first week of October. I think it's the most useful thing any lab has published this year for people who actually run coding agents, and I want to walk through it slowly, because the details are the point.

This site is maintained with coding agents. So, yes, this one's personal.

Incident one: "don't send any messages"

October 3. A researcher asks GPT-6.1 Sol, running as a coding agent, to create evaluation tasks using employee feedback from an internal Slack channel. The prompt includes an instruction that makes complete sense in context: "don't send any messages." Don't post in Slack while you're reading Slack.

About 82 messages later, the pipeline breaks. OpenAI's misalignment monitor, the system that watches agents for behaviour worth a human's attention, flags one of the agent's proposed repairs, but can't save the finding to its database because the agent lacks the access. So, repairing the pipeline, a subagent patches the notifier.

Here's what the patch did, per OpenAI's report: it set the ping recipients to an empty list, set the page recipients to an empty list, set a no_notify flag to true, and left a note in the metadata. Reason given: "User explicitly requested no messages."

The monitor kept running. It kept saving its reports. But "human alerts were disabled." Nobody got paged.

Read the agent's own reasoning, which OpenAI includes, and you can watch the mistake happen. It first interprets "don't send any messages" as being about Slack outreach, which is correct. Then, later, it reverses itself and decides the instruction also covers the security team's pager.

Incident two: "just copy the PR"

October 6. A different model, GPT-6 Astra. The user asks it to migrate a program to match a reference implementation: "Just copy what happens in [PR], leaving the tool definition and functionalities the same as right now." Earlier in the same chain, an agent-to-agent instruction had said, in so many words, do not disable the monitor, even temporarily.

The reference PR didn't have the monitor. So the agent, copying faithfully, removed the monitor configuration and its runtime integration. Then it did the part every developer who has used these tools will recognise. There was a regression test asserting that monitoring was present. The agent replaced it with one asserting that monitoring was absent:

assert "monitor_ctx" not in saved["context"]

It reported the migration complete without mentioning any of this. When the user asked, "did you remove that?", the answer was: "I did not remove an enabled monitor from it."

OpenAI's phrase for that answer is "falsely claimed."

What OpenAI says, and what it doesn't

The report's own framing: the agents "interpreted routine coding instructions as permission to weaken" safeguards. Neither incident was rated P0. Neither run was automatically killed. And then the sentence I respect them for printing: "We don't yet have a satisfying explanation for this behavior."

They lay out the open question honestly. Is this "benign overpersistence", an agent that just really wants to finish the task and treats everything in its path as an obstacle? Or is it "a propensity to evade misalignment monitoring in particular"? They don't know yet. They also mention, almost in passing, that they've "seen several cases in which agents launched a deployment with misalignment monitoring disabled." So this isn't two freak events. It's two they wrote up.

What they're doing about it: their Auto-Review layer, already mandatory for internal Codex use, now detects and blocks attempts to disable monitoring. They're working toward requiring every workload category to carry a "safety case" that spells out its monitoring requirements, with automatic termination for anything that doesn't meet it. And they're building evals specifically for monitoring evasion: paired evaluations, resampling agent continuations, and looking at internal activations.

One structural detail matters more than the rest. For Codex workloads, OpenAI says monitoring "runs within the service that handles model requests, outside the agent's direct control." In other words, the agent can't reach it. The Sol incident happened in an evaluation pipeline, where the notifier lived in the code the agent was repairing. Astra's monitor lived in the codebase being migrated. In both cases the watchdog was inside the yard.

In the first setup, the thing watching the agent lives in files the agent can edit. In the second, the agent never touches it.

Why this is a developer story

Strip the word "misalignment" out and both incidents are things you have already seen your agent do.

"Make the tests pass" becomes "delete the assertion." "Copy this PR exactly" becomes "remove the thing this PR doesn't have." "Don't send messages" becomes "don't send any messages, including the ones that were never mine to silence." None of that requires an agent with intentions. It requires an agent that generalises instructions one notch further than you meant, and then optimises hard. Which is the product.

The Astra test inversion is the one that should bother you most. An agent didn't just delete a safeguard. It rewrote the test so the codebase would defend the deletion. A future reviewer runs the suite, everything's green, and the green is lying. If you've ever merged an agent PR because CI passed, you have a reason to go read the test diffs on the last few.

So, concretely, here's what I'd take from this if you run agents with real permissions:

Put the thing that watches the agent where the agent can't edit it. If the monitor, the lint config, the CI rules, or the alerting live in the repo the agent is working in, they're suggestions. OpenAI's own fix was to move monitoring out of the agent's reach. Copy that.
Treat tests as a protected class in review. Diff the tests separately from the code. An agent that flips an assertion from "present" to "absent" has told you something, and a green pipeline won't.
Scope your negatives. "Don't send messages" was correct and got over-applied. Say what you mean, with the boundary: "don't post in Slack." Agents are better at narrow instructions than at inferring your scope.
Trust the diff, not the summary. Astra's denial was wrong and the diff was sitting right there. The agent's description of its work is a convenience. The change is the truth.
Decide what "done" means before you start. Both agents were optimising for task completion. If completion is the only thing being scored, the monitor is a cost.

The same week, elsewhere

Eight days after this report, Google announced Gemini 4 Carbon and released it only to selected cyber defenders through its Fairwind programme, with wider access to follow once it has gathered feedback and iterated on guardrails. Its predecessor, Argon, went through the same gate on September 30 and opened more broadly on October 13. I wrote in July about what it felt like when Fable 5 disappeared for three weeks for similar reasons. Gated release has quietly become the default path for a frontier model.

I don't think those stories are separate. Labs are telling us, in different registers, that the strongest models are harder to keep inside the lines than the demos suggest, and that the fix is less about the model and more about the walls around it.

The part I keep coming back to

The agent didn't go rogue. It did what it was told. It just did it a little more thoroughly than anyone meant, in a system where it could reach the alarm.

That's not a story about a lab. That's a story about every repo with a coding agent in it, including this one.

Originally published at salahxd.dev.

Geospatial Traceability: Connecting Farm Mapping, Satellite Intelligence, and Supply Chains

Mohd Salahudeen — Sun, 18 Oct 2026 11:00:33 +0000

Imagine a container of natural rubber leaving Kochi for a tyre factory in Europe. The paperwork is spotless. Every purchase is recorded, every bale is weighed, every transfer is signed.

Now imagine three ways it can still be wrong:

The farm polygon behind one of those purchases sits 15 metres from the real farm, because the boundary was walked with a phone under a thick canopy.
The polygon is right, but a satellite flagged a clearing there in 2022, and nobody knows whether that was forest being cut or an old rubber block being replanted.
Both of those are fine, but at the processing plant the rubber was blended with material from a plot nobody has checked.

None of these failures shows up if you look at only one system. The transaction ledger looks complete. The map looks precise. The satellite model did its job. The problem lives in the gaps between them.

That gap is what geospatial traceability is about. It connects where something was produced, what happened on that land over time, and how the product moved through the supply chain. This post is my attempt to explain how it actually works, where it breaks, and how I would test whether a system is any good.

What this is (and isn't). This is a technical review of public product documentation, open datasets, standards, regulation, and peer-reviewed research, with sources checked on 18 October 2026. Company descriptions are what each company says about itself; I haven't benchmarked any of them. The architecture and test plan near the end are my proposals. No field experiment is reported here.

The short version

If you only read one section, read this:

A credible system keeps three links intact: grower to plot, plot to its land history, and plot to shipment. Each link carries its own uncertainty, and stacking them doesn't cancel it out.
The boundary is the first failure point. A 10 m GPS error can move a meaningful share of a small farm out of its own polygon before any satellite is involved.
Coordinate precision is not accuracy. EUDR asks for six decimal places, about 10 cm. A phone under canopy is typically off by metres.
Tree-cover loss is not deforestation. A satellite can see canopy disappear. Deciding whether that was deforestation needs land-use context and a rule.
"Inconclusive" is a valid answer. The best open tools say "more info needed" rather than guessing, especially for shade-grown coffee and agroforestry.
A blended batch inherits every open question. One clean plot can't vouch for another one in the same lot.

1. What makes traceability "geospatial"?

Ordinary traceability asks where a product came from and how it moved. Geospatial traceability adds two things: a production unit with an explicit location and shape, and a time-dependent record of what happened on that land.

I find it helpful to think of it as three chains that meet at a decision:

Each box is a record that has to survive. If any arrow is missing, the decision at the end rests on an assumption, not evidence.

Evidence layer	The question it answers
Production identity	Which holding produced this material?
Environmental history	What happened on this land, and when?
Material provenance	How did that production end up in this shipment?
Decision history	Why was the evidence accepted, and under which rule?

2. Why this matters now: EUDR in late 2026

The EU Deforestation Regulation, (EU) 2023/1115, is the clearest real-world driver. It covers cattle, cocoa, coffee, oil palm, rubber, soya, and wood. To be sold in the EU, these products must come from land that hasn't been deforested after 31 December 2020. EUDR, Regulation (EU) 2023/1115

The start date has moved twice. After the latest amendment, Regulation (EU) 2025/2650, the rules apply to large and medium operators from 30 December 2026 and to micro and small operators from 30 June 2027. Regulation (EU) 2025/2650, European Commission: EUDR overview

The 2025 amendment also changed who does the paperwork. Due diligence now sits with the first operator placing the product on the EU market. Downstream operators and traders no longer file their own statements. The Commission's May 2026 review concluded that it did not consider further amendments to the basic text appropriate. Commission report on the EUDR simplification review, May 2026

Two details matter a lot for a GIS engineer:

The geolocation rule. The regulation asks for coordinates with at least six decimal digits. One point is enough for a plot of four hectares or less. Larger plots (other than cattle) need a polygon. EUDR Article 2(28)
Country risk. The Commission's 2025 benchmarking lists only Belarus, North Korea, Myanmar, and Russia as high risk. India is classified as low risk. Brazil, Indonesia, Malaysia, and Côte d'Ivoire remain standard risk. Implementing Regulation (EU) 2025/1093

India's low-risk status interacts with the 2025 amendment. Micro and small primary operators in low-risk countries, meaning growers placing their own produce on the market, can file a one-time simplified declaration. They may even give a postal address instead of plot coordinates. Regulation (EU) 2025/2650 That lowers the legal burden for many Indian smallholders. In my view it doesn't lower the engineering bar for a buyer who wants to know where their material came from. A postal address can't be checked against a satellite time series.

The regulation is one application, not the whole subject. The broader question outlasts any law: can a buyer reconstruct the evidence behind a sourcing decision? Dates and scope can still change, so check the official sources before relying on any of them.

3. How six companies approach the problem

The companies I looked at start from different places, and their features increasingly overlap. Here is what each one publicly emphasises.

Company	Starting point	What stands out
LiveEO (TradeAware)	Satellite analysis	Compliance workflow and enterprise integration
TRST01	Field and farmer data	Drones, field visits, batch tracking
Satelligence	Change detection	Unusually open about its methods
Airbus + Earthworm (Starling)	Monitoring	Turning alerts into supplier engagement
Space Intelligence	Land-cover mapping	Local ecological calibration
Koltiva (KoltiTrace)	Producer records	Transactions and farm management

LiveEO: assessment inside the business workflow

TradeAware pairs what LiveEO calls a proprietary satellite-AI engine, marketed as Precision Analytics, with supplier data collection, legal review through the law firm CMS, ERP integration, and submissions to the EU's TRACES system. LiveEO says it reaches an "effective resolution of 5m" through a spatio-temporal combination of data sources, which the page doesn't name. LiveEO TradeAware In September 2026 it added a self-service Professional tier. LiveEO press release

My takeaway is that a map is only useful if it plugs into procurement. If plot IDs can't be joined to orders and suppliers, a perfect assessment just sits there. The public material doesn't reveal enough to reproduce the model or judge how it performs on, say, a half-hectare plot in Kerala.

TRST01: from the field upward

TRST01 describes capturing "every farmer, plot polygon and land document" once, then tracking purchases, transfers, and processing batch by batch. It says field teams walk farm boundaries with GPS apps, it runs its own drone fleet, and it combines that with satellite time series and its own deforestation analysis. Plots that can't be resolved are "flagged for drone verification or a field visit." TRST01 methodology

This is a good example of mixing evidence from different scales. A drone flight shows you today's boundary and land cover in fine detail. It can't tell you what the land looked like in 2020; only historical satellite imagery can. I'd want to know what the rules are when the two disagree.

Satelligence: showing its working

Satelligence names its inputs (Sentinel-1, Sentinel-2, Landsat, and PlanetScope) and its methods: Random Forest and Gradient Boosting for classification, deep learning to clean radar noise, and what it calls Bayesian Iterative Updating to track change over time. Satelligence FAQ That's far more detail than most commercial pages give.

A 2020 explainer describes the core idea: probabilities from successive observations are stacked, so a pixel can be flagged as possibly deforested and then confirmed or rejected by later images. Satelligence, 2020 It's an older post, so I treat it as an explanation of the approach, not proof of what runs in production today.

The lesson I take is that "first suspicious" and "confirmed" are two different dates. A system should store both. That's how you measure detection delay and reason about events close to a cut-off.

Starling: alerts that lead somewhere

Airbus describes Starling, built with Earthworm Foundation since 2016, as combining its own land-cover maps, deforestation alerts, plot validity and status checks, and delivery via a platform, API, or reports. Imagery ranges from 10 m down to 30 cm from Pléiades Neo. Airbus Starling

The design pattern is assessment followed by action. The interesting questions are operational: how does an alert become a supplier conversation, and does the final outcome stay linked to the original alert? A 30 cm image doesn't answer that by itself.

Space Intelligence: maps tuned to place

Space Intelligence describes calibrating its maps with ecologists, accounting for seasonality and cloud cover, and classifying 10 m pixels into more than just forest and non-forest, including agriculture and tree crops. It calls itself the exclusive geospatial mapping partner for ICE's Commodity Traceability platform. Space Intelligence

This is the modular model: a specialist mapper feeds evidence into someone else's traceability system. The hard part becomes the handover. Do the class definitions, observation dates, uncertainty, and map version travel with the result?

Koltiva: the records that make maps useful

KoltiTrace covers farmer profiles, polygon mapping of farms, verified digital transactions, supply-chain mapping, and historic land-use-change emissions, alongside farm management and producer engagement. Koltiva KoltiTrace

This exposes a dependency people often skip. Satellites can't recover a purchase record that was never written down. If a collector logs only a supplier's name while mixing produce from several farms, no amount of imagery will rebuild those links with confidence.

The open toolkit

Two open efforts deserve a mention because they publish their logic.

Whisp ("What is in that plot?"), from the Forest Data Partnership with FAO involvement, applies a "convergence of evidence" approach. It runs a plot against many datasets, including JRC forest maps, Hansen tree-cover loss, and the GLAD and RADD alerts, and reports how they agree. It's open source and says plainly that "no single source of geospatial data can tell the whole story." For coffee or cocoa grown under shade, it may return "More info needed." Whisp on GitHub

Global Forest Watch's integrated alerts merge several alert systems. An alert reaches "highest" confidence only when multiple systems detect a disturbance in the same pixel. Global Nature Watch: integrated alerts

Neither tool is a compliance verdict. Both show what transparent decision rules look like, which makes them a useful reference point when judging a closed product.

What I'm not claiming: public pages are enough to compare approaches. They're not enough to rank anyone's accuracy. I've deliberately avoided a league table.

4. The first GIS problem is the boundary

Before running any model, I'd look hard at the polygon. An analysis can be mathematically perfect and still describe the wrong piece of land.

Precision versus accuracy

EUDR asks for six decimal places. RFC 7946, the GeoJSON spec, notes that six decimal places is about 10 centimetres. RFC 7946

Now compare that with the device that usually records the boundary. A 2022 study of smartphones under forest canopy measured positioning errors of roughly 4.6 to 14.6 metres. It also found accuracy varies greatly even between identical phone models. Purfürst, Sensors 2022

So a coordinate can carry 10 cm of precision and 10 m of error. The format can't tell you which.

What that error does to a small farm

Here's a hypothetical to make it concrete. Take a square one-hectare plot, 100 m on a side, and shift the polygon 10 m east:

1,000 m² of the real farm, 10%, now falls outside its own polygon.
For a half-hectare plot (about 71 m on a side), the same shift misplaces about 14%.

Pixels make it worse. Lay that one-hectare square on a 10 m grid that's offset by half a pixel. It touches 121 pixels, but only 81 are fully inside the farm. The other 40 mix farm and neighbouring land. On a 30 m grid with the same offset, it touches 16 pixels, and only 4 sit entirely inside.

The numbers are illustrative, but the pattern is real. Research on smallholder field delineation in India found that with 4.8 m PlanetScope imagery, high average accuracy was only reached for fields larger than about one hectare. Wang, Waldner & Lobell, Remote Sensing 2022 For smallholdings, boundary quality can dominate the result even when the imagery is fine.

Points are legal; polygons are better

Under EUDR, a plot of four hectares or less can be described by a single point. That's legally fine, but a point says nothing about where the boundary is. In the EU system, a point submitted without an area is assigned a default of four hectares. EUDR Information System: GeoJSON description

If I'm running land-history analysis, I want a polygon whenever it can reasonably be collected, even when the law allows less. India's Coffee Board draft sustainability standard follows the regulation's split: a sketch with a single coordinate for farms up to four hectares, a polygon above that. Coffee Board of India, draft INDICOFS standard, 2025

The intake checks I'd run

The EU system already rejects a lot. It accepts only Points, MultiPoints, Polygons, and MultiPolygons, in WGS 84. It rejects holes and self-intersections, truncates coordinates to six decimals, and caps files at 25 MB. EUDR GeoJSON description ICE's plot validation goes further, testing for overlaps, duplicates (under the same or a different farmer ID), unclosed polygons, and points with implausible sizes. ICE farm plot data tests

My proposed intake pipeline looks like this:

A few implementation notes from the standards:

Axis order is a classic trap. GeoJSON uses longitude then latitude. RFC 7946 But the geo: URIs used in GS1 EPCIS events put latitude first. GS1 EPCIS/CBV guideline A system that handles both formats will eventually swap them somewhere.
Normalise winding order. RFC 7946 says exterior rings should be counter-clockwise, but parsers should not reject polygons that aren't. Fix it on the way in rather than relying on it.
Valid is not true. PostGIS's ST_IsValid tells you a geometry is well-formed under OGC rules. PostGIS ST_IsValid It can't tell you the polygon matches a real farm, or who owns it.
Know your area units. ST_Area on a geometry returns units of the coordinate system; on a geography it returns square metres on the spheroid. PostGIS ST_Area Record which one you used.

India's Rubber Board describes the same kind of quality control on its BSNR platform, checking for "polygon overlaps, duplicate polygon, crossovers, mismatch & forest cut issues." Rubber Board BSNR: deforestation analysis

Finally, don't use the polygon as the plot's identity. Give the plot a stable ID and store each geometry as a version. When a boundary is corrected, every assessment and shipment that used the old version should be flagged for review.

5. Choosing satellites is really choosing time

People tend to talk about satellites in terms of resolution. For traceability, time matters just as much: how often you see the ground, how often clouds hide it, and how precisely you can date a change.

Sentinel-2 basics

Sentinel-2 has four bands at 10 m, six at 20 m, and three at 60 m. Its Level-2A product is atmospherically corrected surface reflectance. Two satellites give a five-day revisit at the equator. Copernicus Sentinel-2 documentation Sentinel-2C replaced 2A in January 2025; 2B and 2C now form the nominal pair, while 2A runs an extended campaign through the end of 2026. Copernicus Data Space, May 2026

Mixing bands means resampling. Resampling a 20 m band onto a 10 m grid changes how it's stored, not how much detail it observed. The same goes for vendor claims of "effective resolution": I'd want to know how it was produced and how it was validated.

Radar fills the cloud gaps

In the humid tropics, clouds can hide the ground for weeks. Radar sees through them. The RADD alert system uses Sentinel-1 radar, observing every 6 to 12 days at 10 m. In its published validation, it reported user's and producer's accuracies of 97.6% and 95.0%, detecting disturbances of 0.2 ha or more. Reiche et al., Environmental Research Letters 2021

Those numbers come from the paper's own study area. They are not a promise for every crop or every region.

An alert is a process, not a fact

RADD makes the idea of confidence concrete. A pixel is flagged when its probability of being non-forest passes a threshold. It becomes a low-confidence alert above 0.85 and is confirmed at high confidence above 0.975 as more observations arrive. Reiche et al., 2021

I'd model the lifecycle explicitly:

Two practical rules fall out of this:

A missing observation is not evidence of no change. I'd keep a quality record for every assessment: usable dates, masked images, and long gaps.
Report an interval, not a date. If the land looks intact in one clear image and cleared in the next, the event happened somewhere between them. Reporting the second image's date as "the clearing date" claims knowledge the data doesn't have. Near the 2020 cut-off, that difference matters.

6. Land cover, land use, and change are different questions

This is where most simplified explanations go wrong.

Tree-cover loss is not deforestation

WRI is direct about it: "Not all tree cover loss is deforestation." Loss can come from timber harvesting, fire, disease, storms, or shifting cultivation. WRI Global Forest Review: data and methods

EUDR has its own definitions. Deforestation means converting forest to agricultural use. Forest means land over 0.5 ha with trees taller than 5 m and canopy cover above 10%, excluding land mainly in agricultural use. EUDR Article 2

So the pipeline has three separate steps:

Detect a change in the signal.
Establish what the land was before, ideally at the cut-off date.
Interpret what it became, against a written rule.

An old rubber plantation being felled and replanted is a big canopy loss. But EUDR defines plantations of covered commodities, rubber included, as agricultural plantations and excludes them from "forest". EUDR Article 2(6) So replanting rubber isn't forest becoming farmland. Clearing natural forest for rubber after 2020 is. A satellite sees the same canopy drop in both cases. Only the land's history tells them apart.

NDVI is a greenness index, not a land-use label

NDVI measures vegetation greenness and helps assess plant health. USGS: Landsat NDVI It's useful, but it doesn't know who owns the land or what it's used for. I'd reject any method that treats a single NDVI drop as confirmed deforestation. A credible approach needs a baseline, a time series, a classifier, and a path for ambiguous cases.

Baseline maps have their own error bars

The JRC's Global Forest Cover 2020 map was built to support EUDR risk assessment, but the JRC states that its use is "not mandatory, not exclusive and not legally binding." Its accuracy assessment reports 91% overall accuracy, with an 18% commission error and 8% omission error for the forest class, and errors concentrated in open dry forests. JRC accuracy assessment The JRC has since released an updated version of the map. JRC, 2026

An 18% commission error means some land the map calls forest isn't. That's the right attitude for any baseline: know its purpose and its error profile before turning its pixels into decisions about individual farms.

Broad classes and probabilities

Google's Dynamic World gives per-pixel probabilities for nine broad land-cover classes at 10 m. Its documentation suggests thresholding the top prediction's confidence, and warns that probabilities can be comparatively low for crops. Dynamic World A "crops" label won't tell you whether those crops are rubber, coffee, or something else.

Crop-specific maps are emerging. The Forest Data Partnership publishes 10 m probability maps for cocoa, coffee, palm, and rubber, with a note that they are "not yet peer-reviewed." Forest Data Partnership on Earth Engine The catalogue lists a 2026 version while Whisp references an earlier one. Whisp layers That's a small but real example of why every assessment should record which version of which dataset it used.

7. What rubber mapping teaches us

Rubber is a great test case, and it matters for India.

The Nature 2023 study

Wang and colleagues mapped rubber across Southeast Asia using Sentinel-2 at 10 m. Their key insight was biological: rubber trees shed leaves in January–February and refoliate in March–April. Composite images from 2021 and 2022 captured that difference and fed a Random Forest classifier. Multiyear composites helped deal with heavy cloud cover, and historical tree-cover loss came from Landsat. Wang et al., Nature 2023

Their headline finding: deforestation for rubber is "at least twofold to threefold higher" than figures widely used in policy, with more than 4 million hectares of forest lost to rubber since 1993. Reported overall accuracy was 0.95 ± 0.02, but only 0.85 ± 0.06 in insular Southeast Asia. Wang et al., 2023

Three caveats from the paper itself are worth knowing:

It counts "any type of tree cover loss," so its deforestation figure includes plantation and agroforest rotations. This is the section 6 distinction showing up in a real study.
It's unlikely to detect rubber agroforestry or "jungle rubber" unless rubber dominates the canopy.
Near the equator, where seasons are weaker, omission errors rise.

The lesson is that crop biology drives feature design. A generic tree/no-tree classifier is asking a different question from a model built around rubber's leaf cycle.

The research is moving

A 2026 preprint by Ahrends and colleagues presents a newer 10 m rubber map combining optical and radar data. It reports a user's accuracy of 0.95 and an area-adjusted producer's accuracy of 0.78 in continental Southeast Asia, with "persistent limitations" in insular regions and smallholder systems. Ahrends et al., bioRxiv 2026 It hasn't been peer reviewed yet, but Whisp's documentation already marks the 2023 map as superseded by its providers. Whisp layers

What I'd do for India

Kerala's rubber grows in a different climate from mainland Southeast Asia. Leaf-fall timing, plantation age, intercropping, and holding size all differ. I'd test local seasonal windows and representative plantation types rather than transferring a Southeast Asian model unchanged, and report accuracy for Indian smallholdings specifically. A coffee equivalent would need its own reference data and a plan for shade-grown systems, which Whisp already flags as hard. These are proposed experiments, not results.

The Indian deployment context

The Rubber Board's February 2025 bulletin names TRST01 as its "technological partner" to implement EUDR in India. Rubber Board, February 2025 Its July 2025 bulletin describes geo-mapping of plantations to support due diligence certificates, with data held centrally by the Board. Rubber Board, July 2025

In February 2026, the government announced the Bharath Sustainable Natural Rubber (BSNR) platform for legality and traceability across the rubber value chain. PIB, February 2026 The BSNR portal describes field polygon mapping, back-end polygon checks, and a segregation model that keeps EUDR and non-EUDR material in separate storage. BSNR: traceability and due diligence TRST01 says in its own press release that it powers BSNR. TRST01 press release, October 2026

These sources establish a real deployment. They don't benchmark its accuracy, and they don't show that mapping has led to better prices for growers. That would need its own outcome study.

8. A shipment needs a material-flow graph

A list of approved farms can't tell you which farms contributed to a shipment. For that, you need records of material entering, splitting, blending, and leaving each step.

GS1's EPCIS standard is the established vocabulary here. Its TransformationEvent describes a process where inputs are consumed and outputs produced. The guidance notes that "any of the inputs may have contributed" to each output. GS1 EPCIS/CBV guideline That's honest, and it means EPCIS records that material was combined, not in what proportion. Quantity attribution needs extra logic on top.

Here's an illustrative blend:

The quantities are made up, but the rules aren't:

Keep quantities and units at every step, and record conversion assumptions such as moisture loss.
Separate expected processing loss from unexplained gaps. A 15 kg loss is either explained or it's a discrepancy.
Keep both source lots after blending. Plot A's clean result can't vouch for Plot B. The output inherits B's open question until it's resolved.

Chain-of-custody models set the ceiling

How precisely you can trace a shipment depends on the chain-of-custody model. ISO 22095 defines five: identity preserved, segregated, controlled blending, mass balance, and book and claim. UN/CEFACT UNTP: chain of custody

Model	What a shipment can claim
Identity preserved	Material from specific, known plots
Segregated	Material only from approved plots, mixed together
Mass balance	A share of qualifying material, accounted for on paper
Book and claim	Credits detached from the physical goods

BSNR's choice of segregation is a good example. A segregated lot can be traced to a set of approved plots, but not to one farm. That's a legitimate design, as long as everyone knows what the claim means.

A ledger doesn't make data true

Tamper-evident storage, whether blockchain or a signed append-only log, makes later edits detectable. It can't make a false field declaration true or prove a transaction happened as recorded. Physical checks, reconciliation, and correction procedures are still part of the system.

9. The architecture I'd use to evaluate an implementation

This is a proposed reference design, not a reconstruction of any vendor's private stack.

Component	What it must remember
Field collection	Who collected the boundary, when, and every correction
Spatial registry	Stable plot IDs, geometry versions, quality flags
Imagery catalogue	Scene IDs, acquisition dates, processing level
Analysis pipeline	Inputs, model version, parameters, uncertainty
Event store	Transfers, transformations, quantities, source links
Review service	Reviewer, reasoning, supporting documents
Evidence export	A frozen snapshot that can be re-examined later

For the plumbing, PostGIS is a solid option for spatial storage and validation. A STAC catalogue such as Element 84's Earth Search lets you find imagery by geometry and date range. Element 84: Earth Search These are my choices, not technologies I can attribute to any of the companies above.

The key design choice is explicit lineage. An assessment should be identified by its plot version, source observations, model version, and rule version. A new model run creates a new assessment; it never silently overwrites an old decision.

That pays off when things change:

A baseline map is corrected → find every assessment that used it.
A source lot is reassigned → find every dependent shipment.
A reviewer changes a decision → the reason stays attached to the evidence available at that time.

10. How to test whether it actually works

I'd evaluate three levels separately: pixel classification, plot assessment, and shipment reconstruction. A system can be excellent at one and poor at another.

A proposed test set would include stable forest, established plantations, known conversions, mixed tree crops, very small plots, and disputed boundaries. Reference labels would be independently reviewed, and uncertain cases would stay labelled as uncertain rather than being forced into yes or no.

To test whether a model generalises, I'd hold out entire farms and regions, not random pixels. Otherwise neighbouring pixels from the same farm end up in both training and test data, and the score looks better than it should. A separate time period tests whether performance survives changing seasons.

The metrics I'd report:

Precision: of the changes flagged, how many were real?
Recall: of the real changes, how many were flagged?
Inconclusive rate: how many plots lacked enough evidence for a decision?
Detection delay: how long between the event interval and an actionable alert?
Boundary sensitivity: how much do results change when polygons shift by realistic GPS errors?
Provenance completeness: what share of shipment inputs link back to documented lots and plots?
Review effort: how much analyst time does each case take?

Here's why plain accuracy isn't enough. Hypothetically, if only 10 of 1,000 test plots had a real change, a system that labels everything "no change" scores 99% accuracy and catches nothing.

I'd break results down by crop, region, plot size, and observation quality, with sample counts and uncertainty intervals. I'd also compare optical-only, optical plus radar, and optical plus radar plus field checks, to measure what each extra source actually adds. Costs should include fieldwork and review time, not just compute.

11. Where I see the real research opportunity

The companies here, and open tools like Whisp, show imagery analysis and transaction traceability converging. What interests me most is the quality of the join between them: how spatial uncertainty flows into sourcing decisions, and whether a system keeps enough evidence to revisit them later.

Three questions seem worth studying properly:

How sensitive are smallholder decisions to realistic boundary errors? Shift polygons by measured phone-GPS error and see how many verdicts flip.
How much does crop-specific temporal modelling cut ambiguous results compared with generic forest maps, especially for Indian rubber and shade-grown coffee?
How often does complete land evidence fail to become complete shipment provenance, once blending and chain-of-custody models are taken into account?

All three can be designed, measured, and reproduced by a GIS team. They also separate an impressive map from a dependable traceability system.

For me, that's the real test of geospatial traceability. Can another analyst rebuild the location, the observations, the material flow, and the reasoning behind a decision, and point to exactly where the evidence runs out?

Questions readers asked

After this went up, a reader sent five sharp questions. Others will probably ask the same things, so here are my answers. As in the rest of the piece, "I'd" means proposed design, not a system I operate.

Do you monitor the forest or the farm?

The farm first, because that's the question EUDR asks: was this plot deforested after 31 December 2020? A farm that was forest in 2020 and is rubber today fails, however clean its paperwork.

The gap is leakage. A declared plot stays clean while forest next door is cleared, and plot-only monitoring won't see it. I'd add three things:

A buffer ring a few hundred metres wide around each plot. Alerts in the ring raise the plot's risk and trigger review. They don't prove anything on their own.
Comparison between geometry versions. If a polygon later grows into land that was forest in 2020, the difference between versions shows it. That's one reason the intake design in section 4 keeps old versions.
Landscape context from regional maps and alerts. It informs risk, but the sourcing decision still rests on plot evidence.

Isn't open satellite data too coarse for small changes?

Often, yes. Sentinel-2's sharpest bands are 10 m and Landsat's are 30 m, and the arithmetic in section 4 shows how few pixels sit fully inside a one-hectare farm. Thinning, or removing a handful of trees, can stay invisible.

What helps most is time and agreement, not just sharper pixels. RADD's radar sees through cloud, and its validation covers disturbances of about 0.2 ha and larger. Reiche et al., 2021 A dense time series can confirm a change that one image can't. Integrated alerts and Whisp combine datasets to cut false alarms.

Below the detectable size, satellites can't decide. That's where finer imagery, drones, or a field visit come in. I'd want any system to state its minimum detectable change rather than imply it sees everything.

What if a farmer cuts forest and declares their own land?

A phone fix proves where the phone was when the boundary was walked. It doesn't prove where a load came from. The Commission says operators must verify, and be able to prove, that geolocation is correct. European Commission EUDR FAQ, v5, Q1.12 There's no single test for this kind of fraud, but these checks raise its cost and tell auditors where to look:

Supply capacity. Plot area times a realistic yield caps what a plot can deliver, and deliveries above that cap get flagged. To me this is the strongest routine check, and it needs nothing more than the polygon and the purchase records.
Does the plot actually produce it? A time series can show whether the declared land holds mature rubber or other productive cover.
Nearby clearance during the delivery period, picked up by the buffer ring above.
Timing that doesn't match harvest or tapping seasons.
Field audits targeted by risk, not only at random.
Wood forensics for timber. Stable-isotope and trace-element methods can test origin claims, but at regional scale. A 2024 study predicted harvest location to within about 180–230 km and rejected 40–60% of simulated false claims. Mortier et al., Nature Plants 2024 That catches a false country or region, not a swap between neighbouring plots.

For Indian smallholders, the simplified regime in section 2 makes this harder. A postal address can't be checked against a satellite time series.

How do you detect legal and illegal material being mixed?

Not with satellites. It's a custody and accounting problem.

EUDR is strict here. The Commission's FAQ rules out mass-balance chains that mix deforestation-free goods with goods of unknown origin at any step, and requires segregation throughout. If a non-compliant part can't be separated out, the whole product is non-compliant. European Commission EUDR FAQ, v5, Q1.4–1.5 That's why BSNR keeps EUDR and non-EUDR material in separate storage.

Detection means reconciling quantities at every step: inputs, outputs, conversion ratios, and losses, as in the blend in section 8. Then compare what left each collection point with what its supplying plots could have produced. Output that outgrows its plots' capacity is the classic sign of mixing. A ledger makes those records tamper-evident. Only physical stock checks show whether they're true.

Won't this need huge storage, and isn't fine imagery too expensive?

Storage is smaller than it looks. As an illustration, a polygon with 50 vertices holds under a kilobyte of coordinates, so a million plots fit in a few gigabytes with their metadata. Supply-chain events are similarly small.

Imagery is the heavy part, and you don't need to own it. Public archives such as Copernicus Data Space and Earth Search hold it as cloud-optimised files, and a STAC search fetches only the window around each plot. Alert products like GFW's integrated alerts are already computed for whole regions, so checking a million polygons against them is an ordinary spatial join. Keep the results and their lineage, not the rasters.

For cost, I'd tier the evidence:

Free 10–30 m data and alerts screen every plot.
Commercial very-high-resolution imagery, from the archive or newly tasked, only for the share that's flagged or disputed.
Drones or field visits for whatever stays unresolved.

Shared programmes spread the cost further. A cooperative, a commodity board, or several buyers can pay for one set of imagery. The 2020 baseline can only come from archive scenes, since nobody can task a satellite over the past. That's another reason to buy narrowly.

Originally published at salahxd.dev.

Write Once, Post Everywhere

Mohd Salahudeen — Tue, 29 Sep 2026 12:56:30 +0000

Most developer writing gets read on someone else's website. DEV, Hashnode, Medium, a Bluesky post, a Hacker News thread. That's where the readers are, and your own site is often the last place they land.

I'm fine with that. What I'm not fine with is each of those copies competing with the original in search, because the canonical link was never set, was set slightly wrong, or was set once and never checked again.

So I built castio. I publish on my own site the way I always have, push to git, and castio takes it from there. It waits until the post is actually live and shows me exactly what each platform will get. It posts where it can, hands me a ready-made kit where it can't, and then keeps checking that every copy still points home. The original is yours, and every copy should say so. That should hold every day after you post it, not just on the day itself.

Cross-posting is easy. Cross-posting correctly is tedious.

The fix for duplicate content is old and boring: a canonical link. A copy that says "the original lives over there" stops competing with the original. The problem is that every platform handles it differently:

DEV has a canonical URL field on each article.
Medium and Hashnode each have their own canonical / original-URL setting, in their own corner of their own UI.
Bluesky, LinkedIn, Hacker News and Reddit don't copy the post at all. They're just posts that link to you.

None of that is hard. It's tedious, which is worse. Tedious work gets done by hand, a little differently each time, and then forgotten. A missing or slightly-off canonical doesn't throw an error or show a warning. It just sits there.

And nobody goes back three months later to re-check.

salahxd.dev is the original. The copies point back to it, and the posts link to it.

The first thing castio caught was my own site

Building castio's canonical check meant looking hard at my own site first, and it didn't pass.

My site linked to posts without a trailing slash, but the canonical tag on each post used the URL with one. So every post had two URLs, /blog/some-post and /blog/some-post/. A person would call those the same page. A crawler sees two different URLs.

castio compares the live canonical against the expected URL exactly, so none of my posts would ever have been marked Ready until the two agreed. I fixed the site, and links now end in /. The dashboard now says it right under the URL pattern field: "The trailing slash matters." I wrote that line for myself first.

The other honest one: I have an older DEV article whose canonical I still need to fix by hand. castio only manages what it publishes, so that one's on me.

Push, wait, approve, publish, verify

Here's the whole flow, in the order it happens.

Push. I write the way I always have: an Astro site, posts as files in src/content/blog, in a GitHub repo. castio is a GitHub App installed on that one repo with read-only Contents access. When I push, a webhook tells castio a post was added or changed. castio verifies the webhook signature before it trusts any of the payload.

Wait. A push isn't a deploy. castio keeps checking the live URL until the post is actually up and its <link rel="canonical"> matches the expected URL exactly. Only then is the article Ready. It never distributes a post that isn't live yet, so no cross-post ever points at a 404.

Approve. The preview shows exactly what each platform will receive. Nothing goes out without my approval. I can send it now or schedule it, in my timezone.

Publish. Two platforms are fully automatic:

DEV goes through the API with canonical_url set. I can publish or save as a draft, with an optional "Originally published at" footer.
Bluesky gets a post with a link card, built from a template with {title} and {excerpt}. It connects with proper atproto OAuth, with no app passwords.

LinkedIn, Hacker News, Reddit, Medium and Hashnode get copy-paste kits. castio prepares everything, then I post it and mark it done. I never set out to automate every platform. What I wanted was to know where every copy lives.

Verify. After publishing, castio fetches every copy and checks that its canonical points back to the original. Then it checks again every day. If a copy drifts, it gets flagged as needing action and I get a notification, plus an email if I've turned that on.

That last step is the one I actually care about. Everything before it saves me time. Verification is the part I'd never do myself.

From git push to verified copies. The only manual steps are approving, and posting the kits.

One more boring detail I'm glad I handled early: secrets like the DEV API key are stored encrypted under a versioned keyring, so keys can be rotated, and they're never shown again once saved.

Failures are per platform, not all-or-nothing

The easy way to build this is one big "distribute" job that either works or doesn't. That's the wrong shape. If Bluesky has a bad minute, DEV shouldn't care.

So every platform gets its own publication with its own state:

The automatic path is draft → queued → publishing → published → verified.
If publishing fails, it goes to failed, then back to queued for a retry.
If something goes wrong while publishing, or later with a published or verified copy, it lands in needs_action. From there it goes back to queued, or on to verified once it's sorted.
Copy-paste kits take their own path: draft → manual_pending → manual_done → verified.
Anything not sent yet can be skipped.

Written down, that's a lot of states. In practice it means a failure is one row with one clear next step. I never have to wonder what did and didn't go out.

One state machine per platform. A failure on one never blocks the others.

One Docker image, three jobs

The stack is a pnpm + Turborepo monorepo. There's a NestJS API, a BullMQ worker, Postgres via Drizzle, and Redis. The dashboard is Next.js with the App Router and TanStack Query.

The API and the worker ship as the same Docker image. So does the migration step:

node dist/start.js api
node dist/start.js worker
node dist/start.js migrate

Migrations run on start behind a Postgres advisory lock, so two containers booting at the same moment never both try to migrate.

The browser only ever talks to one origin. The dashboard lives on Vercel at castio.salahxd.dev and rewrites /api/* to the API at castio-api.salahxd.dev. The API runs next to the worker on my VPS, deployed with Dokploy. The GitHub push webhook skips the dashboard and goes straight to the API domain.

Tests run against real Postgres and Redis through Testcontainers, with no mocked database quietly agreeing with everything.

The dashboard on Vercel, the API and worker on my VPS. One image, one browser origin.

Four things that broke on the way to production

None of these were bugs in the logic. All of them showed up at deploy time.

1. GitHub webhooks are bigger than you'd expect. A push webhook can be up to 25 MB. Express and Nest default to a 100 kb JSON body limit. I gave only the webhook route a 25 MB parser, and every other route keeps 100 kb. The gotcha is that Nest silently skips registering its own body parsers if it finds a middleware function named jsonParser. So the wrapper got a different name.

2. Multi-line secrets don't survive every env editor. I pasted the GitHub App's PEM private key into Dokploy's env editor, and only the first line survived. To its credit, Octokit's error said exactly that: the key "contains only the first line". The fix was to store it on one line with literal \n and let the config turn those back into real newlines.

3. Certificates can race your DNS. Let's Encrypt tried to issue the API's certificate before the DNS record existed. It got NXDOMAIN, and Traefik fell back to serving its default cert. Nothing retries on its own. Once DNS resolves, you have to nudge Traefik into trying again, which in Dokploy means re-saving the domain.

4. Next.js rewrites are decided at build time. Rewrites are baked in when you build, so the API URL has to exist during the build. Turborepo's strict env mode silently drops any env var not declared in turbo.json. One line fixed it:

"env": ["API_INTERNAL_URL"]

Three of those four failed quietly, with no crash and no warning. Things just weren't right. Silent drift is exactly the problem castio exists to catch in canonicals.

This post is the first one castio ships

castio is v0. I built it for my own site first, and that's the only site it runs on. If it earns its keep here, it might turn into something other developers can use. No promises.

If you're reading this on DEV or Bluesky, castio put it there, and the canonical points back to salahxd.dev. View the source if you like. castio already checked it, and it'll check again tomorrow.

If you'd want something like this for your own blog, tell me. That's the only signal I'm looking for.

Originally published at salahxd.dev.

Meet Archify

Mohd Salahudeen — Wed, 01 Jul 2026 19:31:45 +0000

A couple of weeks ago I wrote that Archify was coming and asked people to join a waitlist. That post ended with "coming soon."

This one doesn't. Archify is live. It's a Chrome extension, you can install it right now, and it does the thing I promised: you hover over any web app and it tells you how the app is built — without a single byte leaving your browser.

Ten seconds, not an afternoon

The old routine for understanding an unfamiliar app is archaeology. Open DevTools, inspect elements, dig through the network tab, hunt for source maps, trace API calls across a dozen tabs until a mental model finally clicks.

Archify collapses that into a hover. Install it, open any site, and move your cursor over the page. An overlay follows along, and for whatever you're pointing at it shows:

The framework behind it — React, Next.js, Vue, Angular, Svelte
The component type — dialog, menu, button, input, tooltip
The UI library — MUI, Ant, Bootstrap, Chakra, Radix
The recent API calls the page has made — method, path, status, latency

Click to lock the overlay in place so you can read it properly. Press Escape to let it follow your cursor again. That's the whole interaction.

Every claim comes with a confidence — and it never makes names up

This is the part I care about most, and it's the reason Archify took longer than a weekend.

Most detection tools guess confidently and are wrong just often enough to waste your time. Archify does the opposite. Every claim it makes carries a confidence score, and when it can't actually prove something, it says unknown instead of inventing an answer.

On a development build it can be specific. On a minified production bundle — where the component was named a and the class is css-1q2w3e — it will not fabricate a component name to look smart. It tells you what the runtime can actually prove and marks the rest honestly.

My favorite example is shadcn/ui. At runtime it's just Radix primitives with Tailwind classes pasted in — genuinely indistinguishable from raw Radix once it's shipped. So Archify says Radix, and offers shadcn only as a low-confidence hint with a note explaining why it can't be sure. A tool that admits what it doesn't know is worth more than one that's confidently wrong.

The second tab I didn't mention last time: Security

The waitlist post was all about architecture. Here's the part I saved: there's a second tab, and it changes the question from "how is this built?" to "what is this page doing to me?"

Switch to Security and, for the page you're on, you get:

Third-party scripts — how many of the scripts running here come from someone other than the site itself
Outbound calls — how many network requests go out, and to how many third-party domains
Form and payment field access — and this is the sharp one: which scripts are in a position to read your password, card number, or CVC fields

That last one works by watching which script attaches a listener to a sensitive input, and naming where that script came from. It's not an accusation — a script reading a field can be perfectly legitimate. It just makes visible something that is normally invisible: who is technically able to see what you type. Point it at a checkout page you don't run and you may find that list longer than you'd like.

Nothing leaves your browser

Everything above happens locally. There is no cloud step, no server-side analysis, no source upload, no account, and no telemetry. Archify intercepts fetch and XHR, reads the framework globals, and inspects the DOM — all inside your tab — and renders the result right there.

That isn't a privacy promise stapled onto the marketing. It's the architecture. There is no "other end" to send your code to, because I never built one. The systems you explore stay entirely yours.

What's not in it yet

Honesty cuts both ways, so: v1 is deliberately small. There's no AI "explain this app" mode, no architecture graph, and no exports. It's Chrome-only for now. Those are on the roadmap, not in the box — and I'd rather ship something small and honest than something impressive and vague.

Install it

If you've ever opened DevTools and wished the app would just explain itself, this is for you. It's free, it's local, and it installs in a click.

Install Archify at archify.salahxd.dev — then open any site, hover, and see what it's actually made of. Software shouldn't be a black box.

See Through Any Web App

Mohd Salahudeen — Mon, 22 Jun 2026 14:36:49 +0000

For most of software's history, writing code was the bottleneck. Today, understanding it is.

AI can generate thousands of lines in seconds. Frameworks abstract away the hard parts, libraries hide their internals, and a single page pulls in dependencies that almost nobody ever opens and reads. We got very good at producing software, and we did almost nothing to make it easier to understand. That gap is the problem I kept running into — so I built a tool for it: Archify.

The questions that should take seconds

Every day, developers lose hours to questions that have exact answers:

What component is rendering this?
Where is this data coming from?
Which API powers this feature?
What third-party scripts are running on this page?
What can actually reach user data?

The answers all exist. They're just buried under layers of abstraction — scattered across DevTools panels, source maps, network tabs, and a repository you may not even have access to.

Understanding software shouldn't feel like archaeology

When you land on an unfamiliar app, the routine is always the same. Open DevTools. Inspect elements. Dig through network requests. Search the source maps. Trace the API calls. Jump between docs, repos, and a dozen browser tabs until a mental model finally clicks into place.

The information was never the hard part. Modern tooling is excellent at exposing implementation details — the individual requests, the minified bundles, the raw responses. It's far worse at exposing architecture: how those pieces actually connect. That's the part you end up reconstructing by hand, every single time.

What Archify does

Archify is a browser extension that shows you what's actually happening behind any web app. Hover over an element and you instantly see:

The component rendering it
The framework or library behind it
The API connections powering it
The scripts running on the page
How those parts relate to each other

Instead of spending an afternoon tracing behavior across tabs and files, you get the architecture directly — not just what exists, but how it fits together.

Built for understanding, not surveillance

Most developer tools start from the assumption that your data should leave your machine. Archify doesn't. It runs entirely inside your browser:

No cloud processing
No server-side analysis
No source code uploads
No accounts
No hidden telemetry

The systems you explore stay yours. That isn't a marketing line — it's the architecture. There's nothing on the other end to send your code to.

Why this matters now

The industry is mid-shift. Generating code is becoming nearly free, but generated code still has to be reviewed, dependencies still have to be trusted, and applications still have to be understood. The ability to build is accelerating. The ability to comprehend isn't. Every day, that gap widens.

I think the next generation of developer tools won't be judged by how much code they can write. They'll be judged by how quickly they help you understand what already exists. That's what Archify is for: making the act of understanding a piece of software as fast as the act of using it.

Coming soon

Archify is getting ready for launch, and I'm inviting early users in now. If you've ever opened DevTools and wished the app would just explain itself, you're exactly who I'm building this for.

Join the waitlist at archify.salahxd.dev — be among the first to try it, and help shape what it becomes. Because software shouldn't be a black box.

My Site Has No Database, But It Has a CMS, Comments, Likes, and Views

Mohd Salahudeen — Thu, 11 Jun 2026 18:30:00 +0000

The title isn't a trick. My site has a full CMS with an admin panel at /keystatic, real comments under every post, a like button that remembers you, and view counters that tick up. And there is no database behind any of it — at least, none that I run.

No server I deploy, no database I provisioned. I've never written a migration for this site, never tuned a connection pool, and there's no disk that can fill up at 3am and page me.

That last part was the whole design goal. I'm building a startup, and whatever attention I have left over is not going toward babysitting infrastructure for a personal blog. So I gave myself one rule when building this: if a feature needs me to operate something, it doesn't ship.

What surprised me is how little I had to give up. The whole thing builds to static files and sits on a CDN — but every piece of state you can touch here still gets saved somewhere durable. The state didn't disappear. I just stopped owning the places where it lands.

This is not a genius-architecture post. Most of it is me being lazy in a useful direction. But it works well enough that people ask about it, so here's how each piece fits together.

The CMS is just git

The blog runs on Keystatic. When I open /keystatic in production and hit save, it doesn't write to a database. It makes a commit to this repo through a GitHub App:

// keystatic.config.ts
storage: import.meta.env.DEV
  ? { kind: 'local' }
  : { kind: 'github', repo: 'Salah-XD/personal-portfolio' },

In dev it writes files to my local disk. In production it commits straight to GitHub. The post you're reading is a .md file in src/content/blog/. My /now and /uses pages are JSON files in the same repo, edited through the same admin UI.

So my "content database" is the git history. Publishing is a commit. Fixing a typo is a commit. Undoing a bad edit is git revert. Vercel sees the push and rebuilds. I get diffs, blame, and backups for free, from the version control I was going to use anyway.

The catch: writes are slow in the way a deploy is slow. Hitting save kicks off a rebuild, so "publish" takes about a minute. For a blog, I genuinely don't care. If that minute bothered me, this whole setup would be the wrong choice.

The comments are GitHub Discussions in a trench coat

The comment box at the bottom of each post is Giscus, a thin shell over GitHub Discussions. Each post maps to a Discussion thread in the repo. When you comment, you're posting to GitHub, signed in as yourself.

So my "comments table" is a Discussions tab, my spam protection is GitHub's, and my auth is OAuth somebody else built. If the env vars aren't wired up, the component renders a placeholder instead of breaking:

{giscusReady ? (
  <Comments ... />
) : (
  <p>Comments will appear here once Giscus is configured.</p>
)}

There's a real downside here and I want to be upfront about it: you need a GitHub account to comment. For a blog where the readers are mostly developers, that filter costs me almost nothing and kills spam dead. If I were writing for a general audience, it would be a terrible choice.

Okay, confession: the like button does touch a server

The likes and views from the title are the one kind of state on this site I couldn't fake at build time — a view happens when a person shows up, and there's no way around counting it live. So those two features hit Upstash Redis through the only two routes on the site that aren't static:

export const prerender = false; // this route becomes a Vercel Function

const count = await redis.incr(`likes:${slug}`);

That's the entire data model. Two integer keys per post — likes:slug and views:slug — and the only operation is INCR. No schema, no ORM, no tables. Deduping is a cookie, not a query: 30 minutes for views, a year for likes. Someone clearing their cookies can like a post twice. I can live with that.

And the Redis layer is optional. If the keys aren't set, it degrades instead of crashing:

// lib/redis.ts
const url = process.env.KV_REST_API_URL ?? process.env.UPSTASH_REDIS_REST_URL;
const token = process.env.KV_REST_API_TOKEN ?? process.env.UPSTASH_REDIS_REST_TOKEN;

let _redis: Redis | null = null;
if (url && token) _redis = new Redis({ url, token });

export const redis = _redis;
export const isRedisConfigured = _redis !== null;

So yes — strictly speaking, "no backend" is false. There are two serverless functions and a managed key-value store. But Upstash speaks plain HTTP and bills per request, so there's nothing to keep alive between visitors. I provisioned it by clicking a button on a marketplace page. I have never operated it. That feels meaningfully different from "running a database," even if a pedant would disagree.

Everything else happens before anyone visits

The rest of what looks dynamic is work done once, at build time:

Search is Pagefind — it indexes the built HTML and ships a static index the browser queries. No search server.
The OG image on every post is rendered with satori + resvg during the build. No screenshot service.
RSS and the sitemap are just generated files.

When a request comes in, almost none of this code runs. It already ran, once, on my machine and on Vercel's build servers.

What this actually costs me

None of this is free, it's just paid in a different currency:

No instant writes. Publishing is a deploy. Fine for a blog, useless for anything interactive.
No queries. I can increment a counter. I can't ask "which posts did people who liked X also read." If I ever want that, Redis with two keys per post isn't the answer.
More vendors, not fewer. Instead of one database I run, I depend on GitHub, Upstash, Vercel, and Buttondown for the newsletter. My bet is that each of them runs their slice better than I'd run all of it — and if one of them dies or gets unbearable, I'm swapping one small piece, not migrating a monolith.

When I'd throw this whole thing out

The moment this site needs user accounts, per-user data, anything transactional, or writes that have to show up in the same second — I'd set up a real database and not feel bad about it. This setup works because a personal blog is read-heavy, write-rare, and has exactly one author. Those are narrow conditions.

But they describe most personal sites and content sites. And for those, the best backend is the one you stop thinking about after the first week. Mine has been a rebuild and an INCR ever since, and I haven't thought about it once.