DEV Community: Spicanet

Dry-run first, rollback always: the brakes on SpicaSEO's autopilot

Spicanet — Thu, 12 Nov 2026 14:29:57 +0000

Most SEO work is a queue of small, boring fixes. The damage happens when software works through that queue at 3 a.m. and you find out from the traffic graph. SpicaSEO is an SEO operations tool still in development, and the part I care about most is not the autopilot. It is the brakes: every proposed change starts as a dry-run diff, every change can be rolled back, and high-impact edits wait for a human.

The idea is straightforward. You connect Search Console or your CMS — it is built to work with SpicaCMS, WordPress and connector-compatible sites — and it builds a baseline of rankings, traffic and crawl health. From there it looks for the usual work: pages sitting just outside better rankings, broken links, wrong or missing canonicals, structured data that needs repair, content that may need a refresh grounded in what currently ranks.

Autonomous is a loaded word, so the loop is designed around inspection. Spot an issue, draft the change as a diff you can actually read, apply only the low-risk technical fixes automatically, and hold the rest. Fixing a broken link is one kind of action. Rewriting a page that brings in most of your traffic is another. That second kind belongs in an approval inbox, with a preview of what will change, why, and what the risk is. Outreach emails, if they are ever in that inbox, should be read in full before anyone sends them.

Rollback is not a nice-to-have. A tool you cannot undo is a tool you will not trust. Search also has a long memory. A bad canonical or a botched refresh can take weeks to show up in results and longer to undo there, even when the rollback on your own site is instant. The gates are cheap. The mistakes they prevent are not.

The easy lie in SEO is: I changed something and traffic went up, so the change worked. Traffic goes up for all sorts of reasons. Lift is meant to be measured per action with difference-in-differences: changed pages compared with similar unchanged ones over the same period. It is not magic. It is more honest than a before-and-after screenshot.

SpicaSEO can also run SpicaCMS sites on any VPS, which is useful if you want the CMS and the SEO loop on your own server. What is not ready is a finished product pitch. The public site has sign-in and a way to enable the autopilot, but I am not going to tell you it is done. Pricing is not published yet — there are planned tiers, from free up to agency, and the amounts will appear when they are real. The boundary between auto-applied and approval-required will keep moving as I learn where it belongs.

If I were rolling this out on a real site, I would build a baseline first, read the first batch of diffs without applying any of them, allow only low-risk technical fixes to run on their own, and keep content refreshes behind approval until the lift numbers earn some trust. Widen the autopilot only where the measurements say it is helping.

SpicaSEO: https://spicaseo.com

Read the full article on spicanet.dev: https://spicanet.dev/blog/spicaseo-an-seo-autopilot-that-asks-first

If the date isn't confirmed, Trip2Fest leaves the field blank

Spicanet — Thu, 12 Nov 2026 13:16:30 +0000

A festival page with a confident date is easy to trust and expensive to get wrong. Sometimes the date is a leftover, a rumour, or a number an assistant filled in because a blank cell looked unfinished. Trip2Fest is a live site for finding festivals worth travelling for, and it treats an unconfirmed date as missing information, not as a gap to decorate.

The ticket price is what most festival sites lead with. Fine, as far as it goes. If the festival is in another country, the ticket is often the cheap part. Flights, a place to sleep, the transfer from the city to the site, food for the whole event: that is the trip. Trip2Fest tries to show that wider context, but only for figures that have been through editorial review. If a cost is unknown, it is left out rather than estimated. An empty field is information too. It tells you to check before you book.

The AI planner sits behind the same boundary, not in front of it. It can help shape a trip around a festival, but it builds on reviewed data rather than generating facts of its own. It is not allowed to invent dates or prices. When it does not know, it is supposed to say so. An assistant that guesses a festival date is not a planner. It is a very confident way to miss a festival.

You can browse festivals by location, month and genre, from electronic and psytrance to rock and hip hop. Travel guides pair festivals with city stays, because most people do not fly in, watch one set and fly out. You can save the festivals and plans you are considering, and sign in with Google or email to keep them. Tickets and travel can be booked through partner links, and those links are disclosed. Using the site is free.

A reasonable way to use it looks like this:

Filter festivals by month and genre.
Shortlist a few by location.
Compare full-trip cost context instead of ticket prices alone.
Open the travel guide that pairs the festival with a city stay.
Ask the planner to sketch the trip around the dates you already have.
Save the plan, then confirm the dates on the official festival site before you book.

The catalogue covers festivals across a lot of countries. It is real and browsable, and it is also nowhere near every festival out there. If a favourite is missing, that is not a judgement on it; it has not been through review yet. Because unknown figures are left out, some festival pages will look thinner than a competitor's. That is the trade-off of not guessing, and it is intentional.

Before you book any festival trip, price the whole thing and not just the ticket, check how you get from the city to the site, and treat any missing number as unknown. Then go and confirm the dates where they are actually decided: on the official site.

Trip2Fest: https://trip2fest.com

Read the full article on spicanet.dev: https://spicanet.dev/blog/trip2fest-festival-trips-without-made-up-numbers

One snapshot, every page: how Brokeli keeps broker numbers from contradicting themselves

Spicanet — Tue, 10 Nov 2026 05:45:16 +0000

Here's a bug you've probably seen on finance sites without noticing it as a bug. The review says a broker's fee is one thing. The comparison table, a few clicks away, says another. The toplist has yet another number from some earlier year. Nobody lied; the pages just drifted apart. Brokeli is my forex and CFD broker research site, it's live, and the most important design decision in it is boring: every page reads the same published research snapshot, so the numbers agree everywhere.

What I was trying to fix

Choosing a forex or CFD broker is a high-stakes decision made with low-quality information. The first question isn't even which broker is best. It's which brokers are available to you at all, because that depends on your country, and a lot of comparison content quietly ignores it.

The other problem is evidence. Regulator status, licences and pricing are facts with dates attached. A licence that was valid when someone wrote a review isn't necessarily valid today, and a page that doesn't tell you when a fact was captured is asking for blind trust.

The research snapshot

How a fact travels from a source to the page you're reading.

Evidence is collected from sources such as regulator data, licences and published pricing.
Each fact is captured with the date it was checked.
Facts are assembled into a published research snapshot.
Reviews, comparisons, toplists and the fee calculator all read that same snapshot.
When the snapshot updates, every page updates with it.

illustrative.txt

# Illustration only: the idea, not the real code
snapshot = latest_published_snapshot()
review_page.fee     = snapshot.fee(broker)
compare_table.fee   = snapshot.fee(broker)
calculator.fee      = snapshot.fee(broker)
# one source of truth -> no competing versions of the same number

Country first

Brokeli starts by filtering brokers by country availability. It sounds like a small UX detail. In practice it removes the most common way people waste an evening: reading glowing reviews of a broker that won't take them as a client.

Once you have a list that actually applies to you, you can compare a small set of brokers side by side. It's capped on purpose, because a comparison with endless columns isn't a comparison; it's a spreadsheet you'll close.

What lives on Brokeli

Piece	What it does
Country filter	Shows brokers available where you are
Side-by-side compare	A small set of brokers on the same facts
Reviews	One broker in depth with dated evidence
Toplists	Ranked lists built from the same snapshot
Forex fee calculator	Estimates trading costs from published pricing
Learning section	Forex basics and risk management and MetaTrader

Not financial advice. Brokeli is research, not advice. It can tell you what a broker publishes and what regulators say. It can't tell you whether trading CFDs is a good idea for you, and I'm not going to pretend it can.

About the affiliate links

Brokeli is free to use and affiliate-funded. Affiliate links never change scores. I know every site says that, so here's how I think about keeping it true: scores come from the research evidence, and a commercial deal isn't evidence of anything except a commercial deal.

What I won't claim

Brokeli is live, and it works. What I won't tell you is that it covers every broker in every country, because I'm not going to claim coverage I haven't counted for this post. Coverage is whatever is in the snapshot, nothing more.

Dated evidence also cuts both ways. A captured date tells you how fresh a fact is, which means it will sometimes tell you a fact is getting old. I'd rather show you that than hide it.

And the learning section is a starting point. If you've never traded, read it, then read more, then think about risk for longer than feels necessary.

If the review and the table disagree, at least one of them is lying to you. Usually by accident.

— why everything reads one snapshot

What a broker page should always show you

Whether the broker accepts clients from your country
Which regulators and licences apply
When each fact was last checked
Fees you can plug into a calculator
A clear line between research and advertising

How I'd use it if I were choosing a broker

Set your country and see who's actually available.
Shortlist a few brokers and compare them side by side.
Open each review and check the dates on the evidence.
Run your expected trading through the fee calculator.
Read the risk management pages before depositing anything.

Where to find it

Brokeli lives at brokeli.com. If you spot a number that looks wrong, I'd genuinely like to know. The rest of my projects are on spicanet.net/products.

Brokeli: brokeli.com. Originally published on spicanet.dev.

A website for the café down the street, prepared before they ask

Spicanet — Mon, 09 Nov 2026 09:14:33 +0000

Walk down any street with small shops and cafés and count how many of them have a website that's current. The answer is usually: the ones with a nephew who does computers. Everyone else has a social page, a menu photo from a few seasons ago and a phone number that may or may not be answered. SpicaSite is my attempt to fix that for small local businesses. It prepares a first version of your website from what's already public about your business, a person checks it, and you see a free preview before deciding anything. It's in beta.

Why small businesses don't have good sites

It isn't that small business owners don't want a website. It's that every path to one asks for something they don't have: time to learn a site builder, money for an agency, or patience for a back-and-forth about fonts.

And the person running a restaurant is busy running a restaurant. Asking them to write an About page from scratch is asking them to do a second job.

How a SpicaSite preview comes together

From a name to a preview you can look at.

You give your business name and city, or your current website.
A first version of the site is prepared from what's already public about your business.
A person checks it before you ever see it.
You get a free preview with no account and no obligation.
You decide whether to go ahead.

Nobody should have to write an About page before they've seen whether they like the site.

— why the preview comes first

Checked by a person, every time

The step I'm most stubborn about is the human check. What's public about a business online is often out of date or just wrong: old opening hours, a menu from before the chef changed, a photo of the shop next door. Software can collect it. A person has to look at it and ask whether it's actually right before a business owner sees it.

That's what makes it a personally prepared site rather than a template with your name pasted in.

What you get

Piece	How it works
Free preview	No account and no obligation
Your own domain	The site runs on your address
Changes by message	You ask and they're made and checked and published
QR menu	Your menu as a fast web page with a QR code

Menus that don't need reprinting

Restaurants get one extra thing I'm quite fond of. The menu becomes a fast web page with a QR code you print once. When prices or dishes change, the page changes. The sticker on the table stays the same.

It's a tiny thing that saves a surprising amount of hassle, and it's the kind of detail that only matters if you've watched someone reprint menus because one dish sold out for good.

Changes by message. After you go ahead, you don't learn an editor. You send a message saying what you want changed. It gets made, checked and published.

What's honestly still beta

SpicaSite is in beta. The free preview is real and available. Paid plans aren't published yet, so I'm not going to quote prices in this article or anywhere else until they are.

There's also no public gallery of finished sites yet. The examples page is empty for now, so the sample preview on the restaurant page is the closest thing to a look at the result today.

The other honest limit is the starting material. A business with almost nothing public about it gives the first version very little to work with. The preview will still be checked by a person, but it will need more input from the owner before it's ready.

Status: beta
Preview: free with no account
Paid plans: not published yet
Public examples: not there yet
Thin public info: needs owner input

Is it a fit for your business?

You're a small local business
You don't have a current website or you've outgrown the old one
You'd rather send a message than learn a site builder
You want to see a preview before paying anything
You run a restaurant or café and want a QR menu

Note: How it's built. In general terms: public information about a business goes into a structured draft, a person reviews it, and the approved site is served on the owner's domain. Change requests follow the same path: a message, a change, a check, a publish.

See what yours would look like

If you run a small business, or you know someone who does, a free preview starts at spicasite.com. My other projects are at spicanet.net/products.

SpicaSite: spicasite.com. Originally published on spicanet.dev.

Every field has a date: building a Bali guide that admits when it last checked

Spicanet — Sat, 07 Nov 2026 03:36:21 +0000

Travel guides have a shelf life problem. A restaurant closes, a beach club changes hands, a market moves to another day, and the guide keeps cheerfully recommending all of it. Bali makes this worse because it changes fast. Bagus Bali is a local guide built on one idea: places, events and deals should be checked by people actually on the island, and every field should say when it was last checked. It's live and available in many languages. The checking itself hasn't caught up yet: right now every listing says it hasn't been verified, and I'll get to why that's the honest state.

Why most Bali guides go stale

Most guides treat a listing as one thing with one date, if they show a date at all. But a listing isn't one fact. The address rarely changes. The opening hours change sometimes. The happy-hour deal changes all the time. Putting one date on the whole thing hides which part you should double-check.

So Bagus Bali is built so that every field carries its own check date. Once a listing is verified, you'll be able to see that the location was confirmed long ago but the hours were checked recently, and decide how much to trust each part.

Right now, though, the listings show 'Not checked yet'. The verification hasn't happened, and the site says so plainly instead of inventing a date. I'd rather ship the empty field than a fake one.

A guide without dates is a guess with nice photos.

— the reason for per-field dates

Organised by where you are in the trip

The guide is organised around where you are: coming to Bali, being in Bali and living in Bali. Someone planning a week and someone sorting out a long stay need different things, and pretending they don't makes a guide worse for both.

Eat and drink
Stays
Things to do
Wellness
Nightlife
Services
Long-term living

What's in the guide

Piece	What it does
Per-field check dates	Built in but listings are not verified yet
Area guides	Canggu and Ubud and Uluwatu and Seminyak and Sanur
Sponsored labels	Keeps paid placements apart
Event re-confirmation	Meant to confirm details with organisers
Map and trip planner	Find places and plan days
Ask Bagus	Questions answered from the guide
Languages	Many languages for visitors and residents

Why area guides matter in Bali

In Bali, where you stay shapes the whole trip. Canggu, Ubud, Uluwatu, Seminyak and Sanur feel like different places, and traffic makes the distance between them feel longer than any map suggests. Picking the right base first saves more time than any list of restaurants. That's why the area guides sit next to the categories instead of being buried under them.

Keeping sponsored things separate

Local guides make money somehow, and the usual way is to let businesses pay to look better. Bagus Bali has sponsored placements, but they're labelled and kept apart from the regular listings. A sponsored spot doesn't quietly become a recommendation.

Events get the same suspicion. Event details are meant to be re-confirmed with organisers, because an event page is the most likely thing in any guide to be wrong by the time you read it.

Sponsored is labelled. Sponsored placements are always labelled and kept apart from regular listings. If something is paid for, you'll know.

How a listing is meant to stay honest

The process as designed. Listings haven't been through it yet.

Someone on the island checks the place or event.
Each field is saved with its own check date.
Events are re-confirmed with organisers.
Sponsored placements are labelled and kept separate.
Readers see exactly how fresh each detail is.

The tools around the guide

There's a map, a trip planner and Ask Bagus for questions you'd otherwise send to a friend who lives there. They're useful, but they're built on top of the checked data, which is the actual product. A planner working from stale listings is just a faster way to arrive at a closed restaurant.

What's honestly hard

The biggest gap is the obvious one: listings haven't been verified yet. The structure for dated checks is there, but the checks themselves are still ahead, so for now treat every detail as something to confirm yourself.

Checking things on the ground doesn't scale like copying listings from somewhere else. Some areas and categories will always be fresher than others, and the per-field dates will show you exactly where. That's the point, but it does mean you'll sometimes see an old date and have to check for yourself.

Many languages also means many places for a translation to lag behind an update. The dates are there to keep that honest too.

How to use any travel guide well

Look for when a detail was last checked
Double-check hours and events before you go
Know which listings are sponsored
Use area guides to pick a base before picking places
Trust recent local checks over old reviews

Where to find it

Bagus Bali is at bagusbali.com. The rest of my projects are at spicanet.net/products.

Bagus Bali: bagusbali.com. Originally published on spicanet.dev.

Consent first, exits later: building Proxymist in the open

Spicanet — Fri, 06 Nov 2026 15:32:13 +0000

There's a version of the proxy business that nobody likes to talk about: exits that come from devices whose owners have no idea they're exits. I didn't want to build that. Proxymist is a consent-based web access network for testing websites from different locations and for web data work. Every exit is consented, every request is authenticated and every action can be traced back to who made it. It's in development. Today you get an account, a dashboard, documentation and a sandbox API. The actual exits are still being built.

Why consent is the starting point

If you've ever needed to see how your site behaves from another country, you know the options aren't great. You either trust a network whose sourcing you can't see, or you don't test at all.

I decided the sourcing question had to be answered before anything else. An exit that hasn't agreed to be an exit isn't an asset; it's a liability that just hasn't been noticed yet. So consent isn't a feature in Proxymist. It's the foundation the rest has to sit on.

The rules the network is built around

Rule	What it means in practice
Every request is authenticated	No anonymous traffic through the network
Every exit is consented	The people providing exits agreed to it
Every action is attributable	Requests can be traced to an account

Limits in front of the network

Authentication and consent cover who's on each end. The middle needs rules too. In front of the network sit destination policy, rate limits and spend limits. Destination policy decides where traffic is allowed to go. Rate limits stop one account from hammering a target. Spend limits stop a runaway script from turning into a runaway bill.

None of these are glamorous. All of them are things I'd want in place before any real exit carries any real request.

What a request goes through

The path as designed. Today it ends in the sandbox.

Your client authenticates with the API.
Destination policy checks where the request is going.
Rate and spend limits are applied to your account.
The request is routed to a consented exit.
The action is recorded against your account.

Sandbox only today. Right now the API is a sandbox. It's there so you can test authentication and integrations. It does not route through live residential or mobile exits yet.

What you can actually use today

The account, the dashboard, the documentation and the sandbox API are available, and the sandbox is free. If you're building something that will eventually need geo testing or web data access, you can wire up authentication and integration now and find out whether the API shape suits you.

That's deliberately modest. I'd rather you build against a sandbox that's honest about being a sandbox than sign up for a network that's quietly only partly there.

What's still being built

Live residential and mobile exits aren't available yet. Neither are shared nodes. Usage-based pricing isn't published, because there's nothing to price until the exits exist. All of that will be announced when it's verified, and not before.

I'm not putting dates on any of it. Consent-based sourcing is slower to build than the alternative, and that's the trade I chose.

Residential exits: in development
Mobile exits: in development
Shared nodes: in development
Pricing: usage-based and not published yet

An exit that never agreed to be an exit isn't coverage. It's a problem with a delay on it.

— why Proxymist is slow on purpose

Who it's for

The obvious users are developers and QA people who need to see a site the way someone in another country sees it: localised prices, redirects, consent banners, content that changes by region. The other group is people doing web data work who want a network where the rules are written down and enforced, not implied.

If what you need is the cheapest possible pile of IPs with no questions asked, Proxymist is the wrong tool, and that's fine.

Questions to ask any web access network

Did the people providing exits agree to it
Is every request tied to an authenticated account
Are there destination rules and not just bandwidth
Can you cap spend before a script runs away
Will it tell you plainly what isn't live yet

Note: How it's built. In general terms: an authenticated API with policy and limits enforced before routing, a dashboard for accounts and usage, and documentation written for the sandbox you can use today rather than for features that don't exist yet.

If you want to kick the tyres

The sandbox and docs are at proxymist.com. My other projects are on spicanet.net/products.

Proxymist: proxymist.com. Originally published on spicanet.dev.

Scoring VPNs without pretending the affiliate money isn't there

Spicanet — Tue, 03 Nov 2026 03:34:22 +0000

Let's start with the awkward part, because every VPN review site has it and most of them whisper it in the footer: VPNScoreLab is affiliate-funded. If you click through and buy, the site may get paid. I'm saying it in the first paragraph because the whole project is built around one idea: if you can't hide the money, at least show the method. VPNScoreLab is a live, independent VPN testing site that publishes structured scores from a transparent methodology, and this is how I think about it.

The problem with VPN reviews

Search for the best VPN and you'll get a wall of best-of lists that look suspiciously alike. Same winners, same adjectives, same breathless lines about military-grade encryption. Nobody tells you why one service is ranked above another, which means the ranking is a vibe with a buy button attached.

I didn't want to build another vibe. I wanted a site where the score is the output of a method you can read, and where disagreeing with a ranking means disagreeing with a specific criterion rather than with somebody's mood.

What gets scored

Area	What it covers
Privacy and logging	What a service keeps about you and what it says it keeps
Real-world speed	How it behaves in actual use instead of on a spec sheet
Security features	The protections a service actually offers
Protocols	Which connection protocols are supported
Streaming unblocking	Whether it works for streaming services

Method before ranking

Every review is broken down into those areas, and the scores come from a methodology that's published on the site. The point isn't that my method is perfect. The point is that it's visible, so you can decide which parts you care about.

Someone who torrents and someone who travels with a laptop in a hotel lobby want different things from a VPN. That's why there are picks by need, not just one leaderboard:

Streaming
Privacy
Travel
Torrenting
Gaming

How a reader is meant to use the site

Start with the need, not the brand: streaming, privacy, travel, torrenting or gaming.
Look at the shortlist for that need.
Compare services side by side on the criteria that matter to you.
Read the methodology if a score surprises you.
Check the disclosure before you click anything with money attached.

A score is a model. A headline score squashes a lot of nuance. VPNs with close scores can be very different products. Use the score to narrow the list and the breakdown to make the decision.

Rankings move, and that's the point

Rankings are updated weekly. That's a feature, but it does mean the order you saw last month may not be the order today. VPN services change their apps, their policies and their infrastructure, and a review that never moves is a review that's slowly becoming fiction.

Alongside the reviews there are guides for the questions people actually ask before buying, like whether you need a VPN or antivirus, and how Tor and a VPN fit together.

What isn't solved

I'll be straight about the limits. Affiliate funding is a structural conflict of interest, and disclosure manages it rather than removes it. The best I can do is keep the method public and keep the money out of the scoring.

A testing site also can't promise that every result holds for your connection, your country and your device. Real-world speed in one place is not real-world speed everywhere. I'd rather you read a score as useful evidence than as a guarantee.

And no methodology survives contact with every edge case. When readers point out a criterion that's weighted badly or missing, that's a methodology change, and it should be visible as one.

What I'd want from any VPN review site, including mine

A published methodology you can actually find
Scores broken down by criterion and not just one number
Picks by use case and not only an overall winner
Affiliate relationships disclosed where you'll see them
Regular updates so old rankings don't linger

If you can't hide the money, show the method.

— the rule the whole site is built on

Note: Building approach. It's a content site with a structured review model underneath: every review fills the same criteria, so comparisons and picks by need come from the same data instead of separate hand-written lists.

Have a look

If you want to poke holes in the method, it's all on vpnscorelab.com. The rest of my projects are at spicanet.net/products.

VPNScoreLab: vpnscorelab.com. Originally published on spicanet.dev.

Governance research as an API: reading Polity Atlas as data

Spicanet — Mon, 02 Nov 2026 03:39:36 +0000

A lot of political and institutional knowledge lives in prose: encyclopedia articles, papers and long reports. That is fine for reading, but hard to query. You can't easily ask "which experiments use sortition, and which of the claims about them are disputed?" unless someone has already structured it. Polity Atlas is built the other way round. The pages are views over a graph, and the graph is published through an open API.

This post is a short tour for developers and researchers who would rather start from JSON than from a web page.

The basics

Base URL: https://polityatlas.org/api/v1
Schema: an OpenAPI 3.1 document at /api/v1/openapi.json, plus interactive docs.
Authentication: none for reading. Writing (for signed-in contributors) uses the Django session cookie and a CSRF token.
Pagination: list endpoints take page and page_size and return {"items", "count", "page", "page_size"}.
Errors: always {"detail": "…"} with a meaningful status code (400, 401, 403, 404, 409, 422, 429).
Localisation: add ?lang=ru (or send Accept-Language) for Russian fields. Missing translations fall back to English.
Licence: the developers page lists content under CC BY-SA 4.0 and data under ODbL.

One request

The canonical example on the developers page fetches a single entity:

curl "https://polityatlas.org/api/v1/entities/polycentric-law?lang=en"

import httpx

r = httpx.get("https://polityatlas.org/api/v1/entities/polycentric-law?lang=en")
entity = r.json()

The response is not just a title and a summary. It returns the entity with its relations grouped by type (for example, which mechanisms implement it), its claims with evidence and sources, and its assessments. Each claim carries two separate fields:

epistemic_status: established, theory, disputed, hypothesis or forecast
verification_status: unverified, AI-drafted, in review, verified or rejected

Keeping those apart is the useful bit. "Disputed but verified" is a perfectly normal state: the dispute is real and documented, and the record of it has been checked.

What you can query

The endpoint reference on the developers page is grouped by the site's sections:

Knowledge

GET /entities with filters for kind, theme, tag and free text
GET /entities/{slug}/graph for an ego network, one or two hops deep
GET /graph for the whole published graph
GET /claims/{id} for a claim, its evidence, sources and open disputes
GET /sources, GET /glossary, and GET /search with keyword or semantic mode
POST /ask for an answer built only from published claims

Living Atlas

GET /experiments with filters including a bounding box, autonomy and whether AI is used
GET /experiments/geojson returns a GeoJSON FeatureCollection, ready for a map
GET /experiments/network for network polities and shared mechanisms
GET /experiments/facets for counts per facet value

Explorer and Observatory

GET /criteria and POST /explorer/compare for weighted comparisons over known criteria
GET /observatory (signals, news, research, briefings) and GET /scenarios

Polity Lab

GET /lab/options for configuration dimensions and stress scenarios
GET /repository/components for versioned institution components

And for bulk work there is GET /export/entities.jsonl, the full graph as JSON Lines, refreshed nightly.

The vocabulary

Everything uses one ontology, which is documented on the same page. Entity kinds include concept, mechanism, theory, thinker, experiment, institution type, ideology and organisation. Relations are typed: implements, tested_in, proposed_by, influenced, criticises, alternative_to, part_of, uses_mechanism and related_to.

Typed relations are what make the graph worth querying. "Quadratic voting is tested in these experiments" and "this thinker criticises that concept" are different statements, and the API keeps them apart instead of flattening everything into "see also".

A few things you could build

None of these exist yet as far as we know. They are just the obvious uses:

A map layer of operating and closed experiments for a teaching site, straight from the GeoJSON endpoint.
A reading list generator that walks proposed_by and influenced edges from a concept to its thinkers.
A notebook that pulls the JSONL export and checks how many claims about a mechanism are disputed versus established.
A citation helper that resolves an entity slug to its sources.

If you do build something, the licences ask for attribution (CC BY-SA for content, ODbL for data).

Notes and limits

Reading is anonymous with "generous rate limits", and the OpenAPI description documents X-RateLimit-* headers. Be polite with bulk jobs and use the JSONL export rather than paging through everything. Russian is the documented second language for API fields. Governance Explorer scores are described on the methodology page as editorial judgements against stated criteria, so treat them as illustrative rather than as measurements.

Polity Atlas is built by Spicanet. The full reference is on the developers page.

Polity Atlas: polityatlas.org. Originally published on Polity Atlas. Studio write-up on spicanet.dev: Design an institution. Then try to break it.

A Koh Samui guide for a week or a whole season

Spicanet — Sun, 01 Nov 2026 03:39:36 +0000

I know the problem every visitor to Koh Samui has. The island is small enough that you feel you should know it in a day, and big enough that you won't. The good beach is the one nobody mentioned. The best southern Thai food is in a place with no website. And the information online is a mix of old blog posts, ads pretending to be advice and maps with pins in the sea. Samui Love is a warm, multilingual guide to Koh Samui for a week on the island or a whole season. It's live.

The problem with island information

Small places get badly served by big travel sites. The listings that rise to the top are the ones that pay or the ones that have been there longest, not necessarily the ones worth your afternoon.

And visitors come for very different lengths of time. Someone here for a week needs a shortlist. Someone here for a season needs to know where to get things done, where locals eat and what's on this weekend.

What's in the guide

Section	What you'll find
Beaches	Where to swim and where to just look
Restaurants	Places to eat including real southern Thai food
Places to explore	Top places and hidden gems on a map
Tours	Tours from local operators
Events	What's on around the island
Local businesses	Services and shops in one directory

Local guides, not listicles

Alongside the directory, there are local guides for the things people actually ask about. Ang Thong Marine Park. The best beaches. A short itinerary for people who want a plan. Where to find real southern Thai food, which is a question that deserves better answers than it usually gets.

The guide uses real photos. That sounds like a low bar. Go look at how many island guides use the same stock image of a palm tree.

If the photo could be any island, the advice probably could be too.

— why the guide uses real photos

How I'd use it for a first week

Read the best beaches guide and pick a base.
Open the map and save a few top places and hidden gems.
Book a tour from a local operator for a day out.
Check events for the weekend.
Use the southern Thai food guide more than once.

Why multilingual from the start

Koh Samui's visitors and long-stay residents come from all over, and a lot of them would rather not read island tips in a language they barely use. A multilingual guide is far easier to build in than to bolt on later, and it means a family planning a holiday and a remote worker planning a season can both read it comfortably.

What an account adds

You don't need an account to read the guide. If you create one, you can save places, use them offline and receive local deals. Offline matters more than it sounds: island signal has opinions, and a saved list you can't open on a boat is not much of a list.

There's also an AI trip assistant to help plan. It's a helper on top of the guide, not a replacement for it.

Save before you go. Save the places you care about while you have a good connection. Your saved list works offline, which is exactly when you'll need it.

What's honestly still in progress

Samui Love is live on the web. The portfolio describes it as web and mobile in active development, and I'm not going to promise mobile apps in this article. Treat the website as the product today.

Active development also means sections fill in unevenly. Some areas and categories are richer than others, and a guide to a living island is never really finished. Places open, close and change, and keeping up is ongoing work.

Web: live
Mobile: in active development
Coverage: uneven and growing

Getting more out of a Koh Samui trip

Pick your base by beach and not by hotel photos
Plan a day on the water
Eat where the menu isn't written for tourists
Check what's on before the weekend
Save places for offline use

Note: How it's built. In general terms: a multilingual content site with a structured directory of places, tours, events and businesses, a map on top, and accounts for saved places, offline use and deals. The AI assistant sits on top of the guide's own content.

Have a look

Samui Love is at samuilove.com. My other projects are on spicanet.net/products.

Samui Love: samuilove.com. Originally published on spicanet.dev.

One player profile for every game: building SpicaPlay

Spicanet — Sat, 31 Oct 2026 03:38:56 +0000

Most casual browser games treat you like a stranger every time you show up. You play, you get a score, the tab closes and the score evaporates. SpicaPlay is my answer to that small, petty injustice: a web-first casual gaming platform where one player identity follows you from game to game, carrying XP, achievements, streaks and leaderboard spots. It's live, there's a growing set of games you can play right now, and there's nothing to install.

Why I bothered

I didn't set out to compete with the giant game portals. They have huge catalogs and teams to match. I have a smaller ambition: make a set of quick games feel connected, so that a quick round of Reaction Tap counts toward something instead of disappearing.

The interesting design problem isn't any individual game. It's the layer between them. What does a profile mean when the games are this different? How do you reward someone for trying a puzzle game when they mostly play arcade? That's where most of my time went.

How one profile ties the games together

The loop a player goes through, whether they're signed in or not.

Open spicaplay.com and start any game as a guest. No sign-up wall.
Play. The game reports the result to the platform rather than keeping it to itself.
XP and achievements land on your player profile.
Time-windowed leaderboards and your daily streak update.
The daily challenge and weekly missions nudge you toward a game you haven't tried.
If you want to keep your progress, link a Google or email account.

What's actually in there

The catalog covers arcade, puzzle, adventure, strategy and sports. A few names, so you know I'm not describing vapour: Cosmic Dodge, Reaction Tap, Bubble Burst, Castle Siege, Cipher Vault and Circuit Link.

Before I call a game published, I check that it actually runs and can be played end to end, not just that its page loads. I do that with automated headless runs as well as by hand. It sounds obvious. It's also exactly the check that gets skipped, right before a game goes out with a lovely title screen and nothing behind it.

The meta layer in one table

Feature	What it's for
One player identity	Progress isn't trapped inside one game
XP and achievements	Something to show for a quick session
Time-windowed leaderboards	New players can still place this week
Daily streaks	A reason to come back that isn't a notification
Daily challenge	One shared goal for everyone today
Weekly missions	Rewards for variety across genres
Guest play	Try first and decide later

Guest first, on purpose. Account linking is optional. Forcing sign-up before the first game is the fastest way to lose someone who just wanted to kill a few minutes. Guest progress is the default; linking an account is how you keep it.

A small note on leaderboards

All-time leaderboards are a museum. Whoever got there first stays there forever, and everyone else learns not to look. Time-windowed boards reset the competition regularly, so a new player has a real shot at being on the board this week. It's a tiny decision that changes how the whole thing feels.

What's not there yet, honestly

The catalog is real and playable, but let's be adults about it: it's small next to the big portals, and I'm not going to pretend otherwise. The plan is to grow it slowly with games that actually work, not to pad it with unfinished ones.

Some games are deeper than others. A reflex game and a strategy game will never have the same replay value, and the mission system is my attempt to balance that rather than a claim that I've solved it.

I also don't have a grand story about multiplayer, tournaments or anything of the kind. If that ever happens, I'll write about it when it exists.

Catalog: small and growing carefully
Depth: uneven between genres
Social features beyond leaderboards: not there

If you're building something similar

Decide what a profile means before building the next game
Let games report results to a shared layer instead of storing them locally
Prefer time-windowed boards over all-time ones
Make guest play the default
Test that a game is playable end to end before you list it

A game that loads but can't be finished isn't a game. It's a screenshot with a loading bar.

— note to self, pinned above the catalog

Go waste a few minutes

If you've got a coffee break, try some games at spicaplay.com and tell me which one deserves a sequel. Everything else I'm working on lives at spicanet.net/products.

SpicaPlay: spicaplay.com. Originally published on spicanet.dev.

Modelling a music scene as entities, not as a blog dump

Spicanet — Fri, 30 Oct 2026 13:32:23 +0000

If you only glance at DROP THE BASS, it can look like a music site with a lot of sections. The more accurate description is a portal, running since 2002, whose public catalogue is built around entity types — artist, label, release, rave — with a subgenre vocabulary and a separate editorial layer. The catalogue is compiled from public music and event sources and editorially curated. This is about that model. It is not a pipeline disclosure, and it is not a claim to have ingested any particular commercial platform.

The about page states the shape in plain terms: artist profiles (DJs, MCs, producers), labels and promoters; releases, mixes and videos; raves; news and other editorial. An MC, here, is the host of a night, not automatically “the rapper.” A selector is the person choosing the music. Most pages are readable without an account. A login exists for a junglist profile — “junglist” meaning someone in jungle and drum & bass culture, not a tropical-travel tag — plus follows and saved items.

Jungle and drum & bass are related on the site and are not treated as one word. Jungle is a style and a culture, not a rainforest aesthetic and not a synonym for every track in the 170 zone (the informal name for the usual tempo, around 170 BPM). Subgenre pages further split the field — liquid funk, neurofunk, jump-up, halftime and others — as a browsing taxonomy whose borders remain disputed. The site should be used that way, not as a canon.

The artists index is one concrete slice of the entity model: people pages that can connect to releases, labels and, where listed, nights. This article does not invent a headcount or a size claim for the roster. The useful fact is the type: an artist is a first-class object, not only a string on a track title.

Dubplates are another type, and the FAQ keeps them distinct from demos. On this site a dubplate (sometimes just “a plate” or “a dub”) is a public-catalogue item: a standalone tune, a VIP or unreleased pressure, synced from SoundCloud. A demo is private, sent to a label that has claimed its page. Raves, similarly, are published through promoter, venue or festival profiles, not asserted here as a silent scrape of every event site. Once live, a rave can also appear on the relevant city page. Anything more specific about ingestion is not on the about or FAQ pages, so it is not stated in this article.

Mixes and videos follow the same attachment pattern: their own sections, still linked to artists and labels rather than living as an unrelated media dump. Editorial pages — news, and a smaller set of long reads and guides — sit beside the entity graph, not in place of it.

The same model is what you meet on a city page or a festival listing: those are views onto rave entities, not a second unofficial website. Coverage is uneven because a night only appears once it has been published through a profile. A gap is usually a publishing gap, not proof that a city has no scene. The public FAQ is the source for that publishing path; this article does not add unofficial workarounds. If you are used to thinking in records and relations, that is the whole point: curated entities, a contested vocabulary, and a public/private split for plates versus demos. No rankings, and no implied completeness.

For the front door, use DROP THE BASS. The about page, the artists index and the dubplates catalogue are the three places to test what this article has just described.

I built a CMS with no plugins, and I'm keeping it that way

Spicanet — Thu, 29 Oct 2026 03:41:38 +0000

Every CMS I've used eventually turns into a negotiation with its plugin list. One plugin does sitemaps, another does schema, another fights them both over canonical tags, and the site you actually wanted is somewhere underneath. SpicaCMS is my attempt to stop negotiating. It's a single-site, SEO-first CMS runtime with no plugins at all, and it's live. It's also still in active development, and I'd rather say that up front than let you find out from a changelog.

The problem I kept hitting

I run a lot of content sites. Reviews, directories, guides, the odd magazine. The setup was always the same: pick a CMS, install a stack of plugins, then spend evenings figuring out why the sitemap forgot a chunk of the pages or why several plugins all decided to print JSON-LD.

The SEO basics weren't the hard part. The hard part was that they lived in someone else's add-on, configured in a settings screen I'd forget about, and broke quietly when something updated. So I built the boring parts into the runtime and threw away the idea of plugins entirely.

If every site needs it, it isn't a plugin. It's the product.

— me, after untangling one canonical tag too many

What SpicaCMS actually is

Each deployment runs exactly one site. The backend is Django, the frontend is Next.js, and editors work in a staff Control Panel that I've tried hard to keep fast and plain. There's no marketplace, no theme store and no mystery code from strangers.

One site per deployment sounds like a limitation, and it is one. It's also the reason I can reason about a site without wondering which tenant broke what. If you want to run lots of sites, you run lots of deployments. Dull, predictable, debuggable.

Template packs are data models, not skins

This is the part I care about most. A template pack in SpicaCMS isn't a coat of paint. It's a full data model for a type of site, with the fields, pages and structured data that type actually needs. A job board needs different fields from a travel guide, and pretending otherwise is how you end up stuffing salary ranges into a custom field called extra_3.

The packs today cover:

Blogs and magazines
Knowledge bases
Affiliate reviews and software alternatives
Directories
Real estate and jobs
Events
Travel guides with itineraries and maps

SEO that ships with the runtime

Concern	How SpicaCMS handles it
Structured data	Validated schema.org JSON-LD per page type
Sitemaps	Multi-index sitemaps generated by the runtime
Languages	Automatic hreflang
Changed slugs	Automatic 301 redirects
Extensions	None. No plugins by design

What happens when an editor renames a page

The editor changes the slug in the Control Panel and saves.
The runtime records the old path and issues a 301 to the new one.
The sitemap picks up the new URL instead of the old one.
Structured data and hreflang follow the page instead of pointing at a ghost.
Nobody has to remember to install a redirect plugin first.

Self-host or not. The Community edition is free and open-source per site if you want to run it yourself. If you'd rather not babysit servers, there's a managed cloud option. Pricing lives on the site and I'm not going to paste it into an essay that will outlive it.

What's honestly not done

SpicaCMS is live, but the portfolio still lists it as active development, and that's accurate. Template packs and the Control Panel are still changing. If you need a frozen API surface that won't move for two years, this isn't that yet.

There's also a companion SEO tool, SpicaSEO, that's meant to work alongside it. SpicaSEO is in development. Please don't pick a CMS on the strength of a tool that isn't finished; I wouldn't.

And the no-plugins rule cuts both ways. If your site depends on some niche integration, the answer today is probably no, or not yet. I'd rather say no than ship an extension system I then have to support forever.

Is SpicaCMS a fit for you?

You run content sites where search traffic matters
Your site matches one of the template pack types
You're fine with one site per deployment
You don't need a plugin ecosystem
You can live with a product that's still evolving

Note: Why Django and Next.js. Django gives me a solid admin-friendly backend and data modelling I trust. Next.js renders the public pages. Splitting them means the editing side and the reading side can each be boring in their own way, which is the highest compliment I give software.

Where to look

If any of this sounds like the CMS you wished you had a few plugin conflicts ago, the details are at spicacms.com. The rest of what I'm building is on spicanet.net/products, and I'm happy to hear what's missing from your side.

SpicaCMS: spicacms.com. Originally published on spicanet.dev.